avolo

I agree, plugins would be so awesome. Creating a plugin interface isn't a small task though, so if implemented it will have to be robust and last for many versions to come. I think Sketchup has made a pretty good plugin interface with plugins not updated for 5-6 years still working and going strong in the 2023 version of Sketchup Pro. I keep my thumbs crossed for this to be implemented in both Designer and Publisher.

Any news on this bug ever being fixed? I would really like to start using Publisher in production, but it's not an option as long as this bug is present. It's been one and a half year since it was reported and it's still going strong in Publisher (macos) v1.10.4. As I see it: a pdf viewed in Acrobat Reader should look exactly the same after being imported in Publisher provided the exact same font used to produce the pdf is present during import. Also see this: Is it really that hard to track down and fix this? I wish the development team all the best in solving this. It's long overdue...

This bug is still present in the mac rc beta versions of Designer (1.9.0.9) and Publisher (1.9.0.902). The font used in the example was plain old Times New Roman and Acrobat Reader displays it correctly. Will this be fixed for the 1.9 release?

I've also tested this on the mac (10.15.7 Catalina) versions of Affinity Publisher beta v1.9.0.887 and Affinity Designer beta v1.9.0.9. Pdf produced in QuarkXpress v13.0, pdf-version v1.4 and they have the same problem. It appears the tracking on every hyphenated word gets screwed up when imported into either Publisher or Designer, but I guess they're both using the same pdf import code. The document has been auto-hyphenated in QuarkXpress and after importing it in Publisher/Designer, around every hyphen, even the ones that look ok, the character tracking is a negative value varying between -300 down to -500. There is also a mysterious extra space inserted before every hyphen character, like "BE -FORE". It will appear if you select the hyphenated word and set the tracking to zero. Maybe that "space-hyphen" combination is used in Quark to mark that the word has been auto-hyphenated and then negative tracking is used to hide the extra space? Sounds a bit wild, but who knows? Example: in the word "BE -\nFORE" the tracking values are zero except for the space and the paragraph break where they dive to -450. Like this: "0,0,-450,0,-450,0,0,0,0". You can easily produce the same "look" by typing some characters in a text frame in Publisher or Designer, selecting them and set the tracking to -450. They will overlap each other, which is the expected behaviour when setting crazy values. The pdf I used as an example in my previous post displays correctly in Acrobat Reader so I assume either AR caps the tracking values if they're too low or they get screwed up in Publishers/Designers import code?

Hi Sean! Many thanks, it seems to work fine in the beta. Also thank you for a superb product. I'm migrating/recreating all our Illustrator-designs (for a local paper) to Affinity Designer and I really like the GUI and work flow which you all obviously put a lot of thought to.

Text frame tool buggy behaviour Affinity Designer v1.8.6, macos Catalina 10.15.7. Reproduce: Set cell stroke > 0 on a tab " " or a space " ". After doing that you can visualize the bug by moving the cursor around the text frame. The cursor will change into an editing caret even if you're far outside the text frame. Also if you click with the selection tool somewhere above and well outside the text frame; it will still be selected. Select the text frame and export "Selection without background". Expected result: a pdf showing only the text in the selected text frame. Actual result: the pdf displays white areas to the top and left of the text frame extending all the way to the top and left edge of the page as it was appearing in Designer. See below for a better explanation:

I have exactly the same problem in Affinity Publisher v1.8.6. The pdf I'm importing was produced in QuarkXpress v13.0, pdf-version v1.4. I have attached two pics showing the problem.