Dave Harris

As it happens, we do currently support simple kern pairs in the 'kern' table, but only the cross-platform version 0 variant. Optima uses version 1, which is Apple-specific. We'll add support for that in a future release.

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

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

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

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

Rob, if you have both Publisher and Designer, you can use the Designer persona from within Publisher, so you won't need to switch between apps as often as you may think. You can also use the Photo persona in Publisher if you have the Photo app installed. We didn't want to talk about this in public before Publisher was released, but now we can. We think it is brilliant.

Fitzj, I believe you can do that in Publisher already. Have you tried? If you make the graphic pinned inline, it should behave like a character in virtually every way, including for drop caps.

That's because the Normal style has its Next style set to [No Style]. I'm not getting the hidden control characters.

I'm not seeing that behaviour with the file attached. Are you sure you didn't set the frame to be Justify Vertically?

There's a bug in how the Column end zone interacts with the flow options, in this case the widow and orphan control. That's what causes an extra line to be moved - and then the short paragraphs mean that more lines get moved to avoid widows and orphans. This will be fixed in 1.8 (but the fix may not make the next beta). The Column end zone doesn't extend past the last line (or paragraph boundary), so it should be safe to set to a large value. The reason it is a value rather than a checkbox is that if the text engine is not allowed to hyphenate a very long word, you may end up with a last line that is either very loose or very ragged. Sometimes a hyphen may be the lesser of evils.

OK, there is a bug in the interaction between Column end zone and Prevent orphaned first lines and Prevent widowed last lines that can cause it to move an extra line. Because there are several paragraphs of two and three lines, that bug ends up causing the large gap. If all three options are off, the word "hangon" is hyphenated at the end of a column. If Column end zone is then set to 80mm, that word is moved to the next column, which is correct. However, that leaves the last line of the paragraph as a widow at the top of the next column. If Prevent widowed last lines is switched on for that paragraph, it should move one line from the previous paragraph. It actually moves two. That makes a new widow, so if Prevent widowed last lines is switched on for the paragraph that moved, two lines are brought forward. That makes an orphaned first line, so switching on the option to control those moves a third line forward. The bug should be fixed in 1.8 (although it may not make the next beta). Thanks for reporting it.

Thanks. I'll need some time to look at this.

Indent to here should be in the next 1.8 beta. As should Right indent tabs, and hopefully Last line outdents.