Dave Harris

It looks like updating a Table of Contents can modify or delete the anchors used by hyperlinks and cross-references so that links to them break. TOC also puts its anchors at the end of the paragraph, and cross-references only looks for anchors to reuse at the beginning. I think this explains at least some of what you saw.

That's what happens for me. When I insert a cross-reference to a paragraph, it creates an anchor at the start of that paragraph. If I insert a second cross-reference to the same paragraph, it reuses that existing anchor. This is in 1903. Are all your anchors at the start of the paragraph, or are they spread through the paragraph? Was more text inserted in the paragraph after the first cross-reference was added?

We've tweaked this again for the next beta. To explain a bit further... the problem with 1.x arose most with iPad. There's a touch-based UI where you can drag either end of the selection highlight. In 1.x it is fairly easy to drag the end of the selection highlight into blank text outside of the text box, and then you couldn't drag it back again. On desktop you can use the cursor keys, but on iPad screen real estate is so limited that the on-screen keyboard doesn't make the cursor keys available. While the problem is less on desktop, it would be good to find a common solution which didn't force the use of the keyboard on any platform. I had thought that if you were creating the blank lines by accident, then you would just delete them the first time they caused a problem. In the next beta the behaviour will depend on whether the text is already selected. If it's not selected, you'll have to click in the visible box to select it. Once it is selected, you can click on the blank lines too. Hopefully this will fix the iPad issue when you are working with the text, without making it harder to select other objects when you aren't.

That's now by design. The text caret and text highlight can be in the blank lines, so you need to be able to use the mouse in those lines too. It could a problem in 1.x that you couldn't. Why do you need to create blank lines that don't draw?

You can take the number from a numbered list by using the <List Number> field. The idea is that you select multiple cross-references in the Cross-References panel, and that updates them all at once. You can sort the panel in different ways to make it easier to select the subset you want.

Just to be clear, the panel currently shows the evaluated cross-reference text. That could be the page number, or it could be the content of the paragraph or "above/below". For the name we show the name of the target anchor. InDesign seems to show a partially-evaluated text, with page numbers showing as # but with the content of the target paragraph.

Thanks for the comments and suggestions. We plan to implement some of these, but it may take a little while. We didn't provide Show as > Chapter Name because we figured the name of the chapter would normally be a heading somewhere in the chapter, so can be got by using the text paragraph body. The Settings panel does include some document-specific settings. For example, the custom Filler text content which is also specific to the text language. While you are waiting for translations you can add your own strings. It is the spelling language from the Character panel that it uses. If that language is "English (US)" and that doesn't have a string, it will look for another variant of English instead, and similarly for other languages with regional variations.

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

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.

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.)