Dave Harris

In practice many/most PDFs don't include a thumbnail preview. Then the only way we can get an image to draw is to interpret the PDF ourselves, which will never be guaranteed perfect because the PDF specification will always have features we won't support. (Although supporting embedded fonts will help a lot.)

There is a global option to scale strokes with object. See my post above on June 27 2018.

To give the better quality by default. We had some complaints that the images from Publisher were looked worse than from InDesign. If the 85% quality looks OK to you, feel free to make your own preset with the changed setting. We would still like to have a 1.7 document that gives larger sizes than 1.8 when exported with the same settings. We will need this soon if it is to be fixed before 1.8.x. I've not been able to reproduce the problem using documents I've created myself.

You can use Edit > Defaults > Save to make the current defaults apply to new documents.

This should be better in 1.8 (released today). In 1.7.x, it tries to be clever about only showing OpenType options that are relevant to the selected text, but then it only looks at the first few characters and not the whole selection. In 1.8 it defaults to always showing the option (and lets you use it), and the cleverness is in trying to show good samples.

It's stored with the rest of the image data in the Affinity document. Our file format isn't documented and shouldn't be a concern of other apps. It should just mean that importing a PDF and then exporting it repeatedly won't degrade the image.

Affinity will store the compressed data from the PDF in that case, and will only recompress if something is done to the image.

The default autocorrect includes dash dash => en-dash. This is less likely to trigger by accident than dash => en-dash. It looks like it is trying to do en-dash dash => em-dash, but it doesn't work well partly because the autocorrect doesn't kick in until you type a space, and then the space breaks up the pattern. It should have dash dash dash => em-dash instead.

Can you upload a document where they are set wrong, so we can see what is happening and fix it?

You can set the text background colour from the Character panel. It's next to the Font style and colour.

Could you expand on this? What were you expecting that doesn't happen?

PDFLib used to support it, but decided to stop doing so in recent versions. I've not been able to convince them that it is needed.

Thanks. I had actually been testing on an older version, 1.8.0.499, where it works. It does crash as you describe on 1.8.0.518. So it is a relatively new regression. I've logged it to be fixed.

1.7.3 has a lot of problems in that area. 1.8.0.518 should be a lot better. I just tried with a new blank document and it seemed OK. Do you have a more detailed recipe?

In InDesign is it both an inline graphic and a drop cap. I just tried in in Publisher, and it didn't work as well as I expected. The image gets sized and positioned correctly, but the next character gets drop-capped as well. You can avoid this in the 1.8 beta by setting the character count to 1. I'll tweak it so that using the auto character count only affects the image. Either way, I think the feature is better than in InDesign because the image scales automatically. This means you can change the number of lines dropped in a text style, and it will update the images in all the paragraphs that use the style. You can achieve a similar result by using a floating graphic that wraps to largest side, but that's not as texty. I've attached a document that shows both techniques. PinDropCap.afpub