Jon W

We did change the default - several years ago. I'm guessing you've uninstalled this time (which would delete your previously saved install location and product key) where before you always did an upgrade?

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!

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.

Hi monzo, This will be fixed in Publisher 1.7.2.

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.

Hello, It should be fixed in the next beta. We'll post in the beta forum when we release it.

This is known to happen in 1.6.2 when dragging images into the app. Opening via File > Open should load the Exif data properly. This will be fixed in 1.6.3.

Hi sleepy0827, We have found a bug which might explain your problem. The bug is that Exif information is not loaded when a file with a non_English path is dragged into Photo from another app (e.g. Windows Explorer). Is this how you are opening your file? If it is, please try opening it from File > Open. Does that work? Thanks, Jon

What about %TMP%? You would need to change that too (in 1.6.0) ExifTool in 1.6.1 should work regardless of any non-ANSI characters in your user name or TEMP/TMP path. However, it may still fail if you have installed Photo to a non-ANSI path.

It's OK, I've found the problem - on Windows 7 (and maybe also Windows 8), you'll need to copy some more files: api-ms-win-*.dll ucrtbase.dll Alternatively you could just install the Visual C++ Redistributable for Visual Studio 2015: https://www.microsoft.com/en-gb/download/details.aspx?id=48145 Thanks, Jon

OK, we've found the problem - there are some DLLs missing from the Common folder. We'll fix this in the next release, but for now you can fix it yourself by copying these files from the application folder to the Common folder (e.g. from "C:\Program Files\Affinity\Affinity Designer" to "C:\Program Files\Affinity\Common"): vcruntime140.dll msvcp140.dll Thanks, Jon

Itanium-based CPUs were not being detected, due to an oversight. This will be fixed in the next release. Thanks, Jon

It sounds like you didn't add the "/log" option. We would really like to see the resulting Setup.log file - could you try again please? In Step 3 of Sean's instructions, the "Run" dialog should look something like this:

Jonopen, It doesn't matter whether Designer is running or not; the thumbnail handler is completely separate. Thanks for helping us look into this problem. There are a few more things we can try, which I'll post tomorrow. Jon

Hi Jeff, This sounds like there might be some blank thumbnails in your thumbnail cache. If you use the Windows "Disk Clean-up" utility to delete your cached thumbnails or the relevant drive, they should all appear. Assuming this fixes the problem, please let us know if it ever happens again. Thanks, Jon

Can anyone experiencing this problem please try the following (Jonopen, this is similar to what you already tried, but this is a new DLL so please try again). 1. Download and extract the attached file 2. Back up the existing file: C:\Program Files\Affinity\Common\Thumbnail.dll 3. Replace it with the one from the zip 4. Open a folder containing .afdesign or .afphoto files in Explorer. 5. Copy and paste one of those files to create a new file. A "Logging started" message should pop up. If it does... 5. Press <Windows>+R and type "%temp%\AffinityThumbnailHandler". This should open a folder in Explorer. 6. There should be some log files in there. If there are, please post them here. 7. Restore the old version of C:\Program Files\Affinity\Common\Thumbnail.dll Thanks, Jon Thumbnail.zip

The Windows "Disk Clean-up" utility can also delete cached thumbnails.

Hi Jonopen, sorry for not getting back to you. I'm afraid I have no idea why you're having this problem. Everything relevant in your registry seems to be OK. It could be worth having a look in Windows Event Viewer for any thumbnail-related errors.

OK, thanks for trying that. It sounds Explorer just isn't calling our thumbnail handler. Please could you try the following? 1. Run RegEdit 2. Press the Home key to go to the root "Computer" node. 3. Edit > Find 4. Paste this into the "Find what" box: 233d80c6-b8aa-4b99-88da-ee96551d4ca1 5. Tick "Keys", untick "Values" and "Data" 6. Click Find Next It should find HKEY_CLASSES_ROOT\CLSID\{233d80c6-b8aa-4b99-88da-ee96551d4ca1} (Affinity Thumbnail Handler). Then Press F3. Does it find anything else?

OK, please could you try the following: 1. Download and extract the attached file: Thumbnail.zip 2. Back up the existing file: C:\Program Files\Affinity\Common\Thumbnail.dll 3. Replace it with the one from the zip 4. Open a folder containing .afdesign files in Explorer (you might have to create a new file or copy & paste an existing one) 5. Open %temp%\AffinityThumbnailHandler in Explorer. There should be some log files in there. 6. If there are, please post the contents of one here. 7. Restore the old version of C:\Program Files\Affinity\Common\Thumbnail.dll Thanks, Jon

Hi Jonopen, I'm currently adding some diagnostic code to our thumbnail handler, so we can figure out what's going wrong. Watch this space...

Hi Jonopen, There should be a thumbnail handler at this location: C:\Program Files\Affinity\Common\Thumbnail.dll And that path should be stored in this registry key: HKEY_CLASSES_ROOT\CLSID\{233d80c6-b8aa-4b99-88da-ee96551d4ca1}\InProcServer32 Please could you check that these are both present? (PM me if you need instructions) Also, if you open an .afdesign file from Explorer, does it start Affinity and load the file?

While technically correct, this strict definition of DPI is only relevant to the internal mechanics of the printer; it's not a term you'd generally find in software. I think it's safe to assume that whenever software does mention DPI, it means PPI.

Hi BobsDaubs, You are correct that DPI/PPI isn't relevant to vector images. Even when exporting to a bitmap, PPI doesn't affect the content; it is only used to calculate the export resolution (i.e. the number of pixels in the image). To use Mark's example: you've created a vector image, and you want to print it on a 300 DPI printer, and you want it to fill a 6"x4" page. So you need to export image at 1800x1200. We save the DPI in the image's metadata as a hint to other programs that you wanted it 6"x4", but they're free to ignore this and print at a different DPI - e.g. printing at 600 DPI would will result in a 3"x2" printed image.