Dave Harris

Have you looked at Languages section in the Character panel? The Typography script and Typography language fields? Do they not work for you?

The reason for converting to capitals at draw time is so it can be switched on or off by text styles. For example, you might want a header style to be in ALL CAPS. Text styles shouldn't change the underlying text. It shouldn't cause any problems because OpenType features are applied to the ALL CAPS representation, and not to the underlying characters. As others have said, if you do want to change the underlying characters you can use the menu options that do that. It makes no difference to the result, because both methods use the same capitals conversion. (Which in this case maps U+00DF to U+0053 U+0053 and not to U+1E9E.)

Actually, Affinity will apply the stylistic set after converting to capitals. The issue is that the capital conversion does not produce U+1E9E. It produces a pair of S (U+0053) instead. The stylistic set does not affect these. It's unfortunate that this result is not what you want, but I'm not convinced that Affinity is doing anything wrong. The FAQ you cite confirms that the pair-of-S conversion is still the Unicode default, and other apps also use it. That's probably because so many fonts don't define U+1E9E, and capitalisation is not font-specific. If you know your font has a good definition of U+1E9E, you need to put it in manually.

Affinity apps do support Device N colour spaces for vector gradients. I've attached an example file that has a gradient between two spots, and between a spot and a process colour. I've also attached the exported PDF/X-1a that has the Device N shadings. I made this with 1.9.1, but the support has been there for a while. It does have to be a vector gradient with the fill tool, and not a gradient overlay filter effect or other raster gradient. 2.afpub 2.pdf

Hi, I'm responsible for the back-end OpenType font support. The issue with the Typography panel that we fixed recently was to do with Reverse Chaining Contextual Single Substitutions in the GSUB table. We just hadn't implemented them before, partly because we didn't have a font that used them to test with. That's also why we haven't implemented sampletext, tooltip and named parameters. If you could send a font that uses them to the link in Sean's post, that would be very useful.

Thanks for reporting this. The slow-down is indeed due to wrapping the text around the complex vector graphics. We used to calculate the default wrap outline a different way, which was fast but sometimes wrong where shapes overlapped. It is now correct, but much slower. To make matters worse, because the graphics are pinned, editing the text moves them and causes the wrap to be recalculated. I've logged this, and hopefully we'll have a fix for the next version.

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.