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

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.

Could this be due to the interaction between Right indent and Last line indent? Does the indent behave as expected if you set them both to the same value? We have a bug logged where increasing Right indent is supposed to increase the Last line indent automatically, but this wasn't working on Windows so you had to set them both manually. I'm not sure if this got fixed.

Indeed. Rasterise: Everything will turn all the page content into a single bitmap. When that is done, options such as overprint and spot colours won't have any effect because the bitmap is just plain pixel data. It's intended for either when Affinity Photo just wants to wrap its final image in a PDF, or for when some dire bug means the vector export isn't working as intended and there's no other way to get any output. The default option is to only rasterise features PDF doesn't support, and that should be the best. Note Rasterise: Unsupported properties will rasterise transparency for PDF versions that don't support it, namely PDF/X1-a and PDF/X-3. If your printer is requesting Rasterise: Everything because they think it rasterises transparency only, then you may need to use one of those.

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?