mqudsi

Thanks for the confirmation, @Dan C. I look forward to hearing good news!

Thanks - seems doable, if unnecessarily long for a one-liner. Can you specifically ask if we can at least change the behavior if a specifically non-breaking space (U+00A0) is used? I'm sure that would preserve whatever reasons they have for trimming trailing whitespace, while allowing this quicker workaround.

Thanks, I stand corrected. In all cases, is it possible to change this?

I've already attached it to the first post I'm assuming it does do just that.

I'm fine with most keyboard shortcuts the way they are, but for the life of me I can't get used to the discrepancy when it comes to zooming: the Affinity suite zooms with ctrl+scroll and uses alt+scroll to rotate an object about its axis, while Illustrator zooms with alt+scroll and just scrolls left/right with ctrl+scroll. (Also, is rotating the selected object used so commonly that it merits the very coveted ctrl+scroll shortcut? I wish Serif just used both alt+scroll and crtl+scroll to zoom instead). Anyway, I can't seem to find a way to change this in the keyboard shortcuts section. Is it possible?

With a textbox set to right-aligned, I can enter trailing whitespace in Illustrator to manually offset the text in a multiline textbox by some pixels: In Affinity Designer, any trailing whitespace is ignored when the text is rendered, regardless of whether I use regular spaces (U+0020) or even non-breaking spaces (U+00A0): (Notice how the text insertion caret is blinking outside the bounds of the multiline text box because the whitespace is completely ignored for font setting purposes.

Both the source text and the correct rendered result are preserved w/ full editing capabilities in Illustrator. The textbox contains lowercase, the smallcaps option is on, the text is rendered with uppercase glyphs. Changing the text (upper to lower or lower to upper) has the correct and expected result. Copying-and-pasting from Illustrator to a text editor presents the correct MixED cASe as expected. Yes, though to be honest, I said as much when describing how the metadata was used to store the editability information. AD imports plenty of "non-standard" things from Illustrator-created PDFs to get them to render OK. We're in agreement on this, so long as you are saying the underlying code points for what is rendered in the PDF are uppercase. That's pretty much what I said above about PostScript, the AD bug regarding with which glyphs are subset, and what the editor source contains vs what the generated PDF has.

The first, (square aka not affinity). The pixel mask is the bug I am describing - I'm not finding any other PDF viewer/editor that doesn't render that file as fully vectorized; only AD rasterizes the mask (which exists to provide a color overlay for editability purposes). I'm guessing there's something about it that AD doesn't understand or yet support.

Thanks for the reply and no worries about the earlier confusion. I just needed to make it clear that this wasn't a case of user error so we could get to the juicy stuff I played around with import/export in Affinity Designer and I see what you mean about the subsetting. I think that the behavior in question is an AD bug though - an incorrect subset of the characters used in the document is subset in the PDF, because the mapping between lower- and upper-case underlying text vs rendered text is not taken into account. The lowercase glyphs from the font are subset instead of the uppercase glyphs that are actually rendered, so when I open the AD document in another editor (Illustrator), only the initial (capitalized) letter of the small caps text is rendered correctly, while the rest are rendered with the missing glyph symbol. This is not the behavior when going the other way around and exporting the document from Illustrator with font subsetting enabled. I'm aware that the raw PostScript layer doesn't understand the concept of "small caps" but to go a step further, it doesn't understand any font-to-glyph (or glyph-to-font) mappings in the first place. Neither Illustrator nor AD are really working at the core PDF layer (intended for rendering, not editing), but rather using the additional metadata specifically emitted in the PDF to allow for editability. For what it's worth, there is nothing preventing AD from doing whatever it is that Illustrator does when given the same blackbox PDF input. Illustrator is able to understand (via the metadata) that the text is in lowercase rendered in uppercase glyphs, and for AD to be truly compatible as a drop-in Illustrator replacement, imho it should too. [quote]Does Illustrator also have an option to subset the fonts? Did you choose it? If so, could you tell Illustrator to include the full font, and if you do that does it resolve the problem?[/quote] Illustrator has a font subsetting option enabled by default, but it does not matter if it is on or not with regards to how AD interprets the input (because Illustrator is correctly subsetting the glyphs in use). BTW, this isn't just a matter of AD not being compatible with how Illustrator stores its text characteristics metadata (or else a lot more text metadata would be lost probably making it impossible to actually open any Illustrator-generated PDF in Affinity Designer for editing). From what I can see, the subtleties of how smallcaps text is exported, imported, and treated throughout the pipeline hasn't really been taken into account at all, even with Illustrator completely out of the picture. Aside from the matter of incorrect subsetting, AD can't understand its own smallcaps output if the exported PDF is imported right back into AD (the text is imported as lowercase). That's just how smallcaps was interpreted for the PDF preview. The source file it was generated from had MiXeD caSE text w/ smallcaps on, the resulting text does copy as all-caps in a viewer but if the PDF file is opened in Illustrator instead, the correct MiXeD caSE text is preserved (w/ smallcaps effect).

An "AD-native" drop shadow added via as an AD fx to a layer, when offset sufficiently so as to appear above or behind any (non-curves) vector text, causes the resulting PDF export to export "anemic" strokes for the text (and I don't know how to word it except like this). This was actually pretty hard to track down since the drop shadow is exported correctly but seemingly random text in the document with identical properties (font family, font face, kerning, etc) would end up looking wrong in the resulting PDF export, while other similar text in the document would be fine. Here's what the text looks like in AD (note the drop shadow behind the circle and how it extends to make contact with the adjacent text): vs here's what the resulting text from the exported PDF looks like when viewed in any PDF viewer: As you can see, the kerning and the weight of the strokes is very much off. If you export to a raster format like tiff, the text is exported correctly. There are two sets of identically formatted text in this document, one overlaps the dropshadow and the other doesn't. Here's the difference between the generated PDF and the generated TIFF where the drop shadow is found (red denotes found in the tiff but not in the pdf, you can see how it's the stroke width that's affected, giving the "amemic" result): And here's the tiff vs pdf comparison of the other text from the opposite side of the document where the drop shadow falls to the other side, meaning it doesn't overlap the text: As you can see, the heading text is a fairly close match with only a slight deviation in the stroke width between the two. Something else in the document is overlapping with the subheading causing more anemic text to be generated here - my guess is that it's the same underlying issue, just not caused by the drop shadow (hence the more generic "overlapping translucency" in the title). For what it's worth, Adobe Illustrator 2022 can export the text correctly (not just when converted to curves) with the overlaps. The affected document is attached. Fundraising Dinner 2021 - 9x4 with Keynote.afdesign

Walt, Please read my post carefully: this is not an issue with an unsupported font or else I wouldn't have been able to make the corrections in AD that I did to get fix it. I've identified the actual problem and it has to do with the associated text properties being lost on import. (Aside from that, this is all on the same PC.)

The attached PDF is rasterized when opened in Affinity Designer but displays fine in all other viewers/editors that I've tried. I imagine there is an unsupported vector property that AD is choking on. I was able to manually correct this and generate an equivalent PDF fully in AD from the same source file, so I'm not sure why the automated import fails. CPSA Book (Square).pdf CPSA Book affinity.pdf

I have a PDF created in Adobe Illustrator that displays fine via multiple different SDKs and toolkits across different platforms. The PDF contains text (set in Iowan Old Style) that was configured via the "Character" panel in Illustrator 2022 to use small caps, as shown below: The resulting PDF is not correctly imported; here is an example: What it should look like: What is displayed in Affinity Designer 1.10.4 when the PDF is opened (without selecting "favor editable text over fidelity"): As you can see, the kerning is all wrong (all characters are rendered much closer together), the characters are all caps (the actually capitalized input is not rendered at a larger size than the remainder of the text), and the numbers no longer match the height of the neighboring letters. Manually selecting the text input and turning on "Small Caps" in Affinity Designer corrects the height of the numeric characters at the end, but the text kerning remains incorrect - it seems that the underlying text is imported as all-uppercase even though it isn't: This is verified by manually selecting the last three letters of "LIVE" and re-typing them (in lowercase). This, with the previous step of enabling small caps for the text box gives the corrected result: I've attached the actual PDF exhibiting this incorrect behavior as exported by Adobe Illustrator (i.e. without any corrections from Affinity Designer). Fundraising Dinner 2021 - Web.pdf

I suppose that means timer events should be classified into "fires in background" and "doesn't fire in background" with the default being the latter? Presumably that would address/workaround (without fixing)

AD/AP should block all processing/rendering/etc threads when it is not the active window or when it is minimized. Active tasks (the type that would present a progress dialog like export/save/etc) should of course not be suspended, but there's no reason for AD to be rendering the canvas when it's in the background. Additionally, all tabs except the current tab should always be suspended. The CPU (not memory) profile of AD when open with a single tab active (and not "multiple documents mode" enabled) should be identical whether that tab is the only tab loaded in AD or one of a hundred.