Jump to content

Jon W

Moderators
  • Content Count

    108
  • Joined

  • Last visited

3 Followers

About Jon W

  • Rank
    Dev

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,352 profile views
  1. Hi @GoldenDesigns, thanks for confirming. This should be fixed in the next update.
  2. Hi @GoldenDesigns, It's possible that this problem is caused by changes to tablet input in 1.8.4. Please could you try following the instructions in this post:
  3. Windows lnk spatial precision is also pretty bad - technically it's sub-pixel, but in practise you only get about 2 points per pixel.
  4. Hi @AlainP, Both these problems have been fixed in 1.8.4.674. The reason we have changed tablet input in 1.8.4 is to improve the precision of pen strokes (see @Aongus Collins' example above). Originally we had a Wintab-based "high precision tablet input" option, but this was unreliable so it was never enabled by default. In 1.8.0, we tried replacing that with a Windows Ink-based solution, but that brought its own problems. So in 1.8.4 we have returned to Wintab and fixed the original problems. It is still possible to use Windows Ink, by running Affinity with the --disable-wintab option and turning on Windows Ink in the tablet driver settings. This is worth a try if you're still having problems in 1.8.4. There is currently no way to return to the "low precision" tablet input that existed in 1.8.3 when Windows Ink was turned off in the app. But given the poor quality of the resulting brush strokes, that is perhaps not such a great loss.
  5. Just to add to Chris's recipe: hovering the pen over the document again should restore mouse responsiveness.
  6. To all users who have experienced this problem: please don't delete any fonts or rebuild the font cache. The current beta should fix the problem without doing that. If it doesn't, please let us know! Thanks.
  7. We will be investigating this issue. There are many aspects to consider.
  8. Hi Jeremy, I'm afraid we have decided to keep the current behaviour for 1.8. We currently show all installed fonts regardless of language, in common with other non-Apple software. If we start hiding fonts of certain languages, there will be problems for any documents that already use such fonts. We would like to fix this properly by adding language filtering to the font list, but there is currently no timeline for this.
  9. Not a regression - the previous fix was for iOS only, we now need to do something similar for Mac.
  10. Yes it is. The thumbnail handler is used by Explorer to generate thumbnails for all our file types (.afdesign, .afphoto, afpub). Only one DLL can be registered for each file type. It absolutely has to be a shared component - sorry!
  11. Hi meadow, The thumbnail handler is a shared component, which means that if you install multiple Affinity products there will be only one thumbnail handler, shared between all the products. This is why it's in a folder called "Common", and not the one you chose for the application specific files.
  12. Hi monzo, This will be fixed in Publisher 1.7.2.
  13. Hi karlchen68, Can you confirm that the problem only occurs when you drag an image, not when you open it from the File menu? The dragging bug is not fixed in the current beta (1.6.3.96), but it will be in the next one.
  14. Hello, It should be fixed in the next beta. We'll post in the beta forum when we release it.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.