U&lc bug: PDF export from Publisher 2.3.1 -> import Photo 2.3.1

[Mark Favreau]

I have text set in ALL CAPS in an aPublisher document. This file is then exported as a PDF. When the PDF is imported into aPhoto document, every instance where there is a double-same-letter (e.g. the two t's in LETTER, the two P's in SUPPORT), aPhoto does something where the first of those two letters becomes a lower case letter ( LEtTER; SUpPORT).

The file displays as expected in PDF readers and renders properly when imported into other image software (Pixelmator Pro, Photoshop Elements).

service.pdf

[walt.farrell]

A bit curious why you're opening the PDF in Photo rather than the original .afpub file. 

In any case, to trouble-shoot this it would help to have the .afpub, too.

[Oufti]

1 hour ago, Mark Favrau said:

This file is then exported as a PDF. When the PDF is imported into aPhoto document, every instance where there is a double-same-letter (e.g. the two t's in LETTER, the two P's in SUPPORT), aPhoto does something where the first of those two letters becomes a lower case letter ( LEtTER; SUpPORT).

I see the same with your PDF file — here, in AP as well as in APub — but I can't reproduce it with a new file. 

I suspect it could be related to the fact the fonts you used are Type 1/Postscript fonts (a deprecated font format, now replaced by OpenType fonts) — but yet I can't reproduce this bug using another Type 1 font I have on hand… 🤔 

Can you share the .afpub you used?

[Mark Favreau]

The font is Comicraft's WildWords Lower, it is an OTF font, a legitimately paid-for version, not one of the "free" versions.

Pretty sure PostScript fonts aren't recognized on the newer MacOSes.

I don't get all the interest in having my aPub file. This is a bug report having to do with importing a PDF into aPhoto. aPhoto is clearly reinterpreting the font; PDF readers and other apps don't have a problem with it. If Serif decides they want the file, then, sure I'll provide it, but…that ends up being photos and fonts and all sorts of things other than just an aPub file. I'm not keen on putting licensed font files on the net where … you know … supposed to be illegal to do that.

I'll try some different fonts for the hell of it a little later.

[Mark Favreau]

Seems to be that font; I tried a few others and they display as expected.

Also, if the WildWords font is disabled and the PDF is imported, the substitute font is affected similar to the WildWords.

Let's see if Serif can add anything to the conversation.

[Mark Favreau]

I'm kind of surprised that aPhoto won't allow me to flatten and rasterize the PDF on import.

[loukash]

9 hours ago, Mark Favreau said:

if the WildWords font is disabled and the PDF is imported, the substitute font is affected similar to the WildWords.

If you look closer at your original double "L"s, double "N"s and double "P"s, you'll notice that those are never the same two characters. (Which is – from a designer point of view – a Good Thing™ because the text thus looks more natural like a genuine handwriting.) So there are apparently some advanced typography features of this particular font involved which are subsequently being "lost in translation" on export and re-import.

9 hours ago, Mark Favreau said:

I'm kind of surprised that aPhoto won't allow me to flatten and rasterize the PDF on import.

Just place it in a blank Affinity document – regardless whether APh, ADe or APu – and rasterize in place. Like this you'll have way more control to get the exact result you want. (Unlike e.g. the pathetic rasterizing options that I remember from Photoshop CS5 which were usually hit or miss, over and over again…)

[Pauls]

Is the PDF being generated using font sub-setting ?, disabling that may make a difference

[loukash]

10 hours ago, Mark Favreau said:

Pretty sure PostScript fonts aren't recognized on the newer MacOSes.

They still are on Ventura, albeit only under certain conditions:

• they must live in your Home folder hierarchy
• you may better want to use a 3rd party font manager to handle them
• not all apps can deal with them, and often only in a limited way, including Affinity

I'm still using some of them which are now over 30 years old, e.g. for converting some of my very old layouts from the early 1990s to PDF.
Also, they are of course still usable in an emulation like SheepShaver where I run Mac OS 9 with Adobe Type Manager and various "antique" design apps like Freehand 9.

[Oufti]

3 minutes ago, Pauls said:

Is the PDF being generated using font sub-setting ?

Yes it is. 

(From Adobe Reader > cmd-D)

[Hangman]

Interestingly I'm not seeing the same issue when font-subsetting is enabled...

I just opened the original PDF, replaced the lower-case characters with upper-case and re-exported the file using the default PDF (press-ready) preset and it opens without issue in Affinity Photo...

service_v2.pdf

 

[walt.farrell]

1 hour ago, Hangman said:

Interestingly I'm not seeing the same issue when font-subsetting is enabled...

But if it's font-dependent, and specifically related to alternate glyphs based on OTF features, you probably wouldn't see an issue unless you started with the original .afpub file.

[Hangman]

1 hour ago, walt.farrell said:

But if it's font-dependent, and specifically related to alternate glyphs based on OTF features, you probably wouldn't see an issue unless you started with the original .afpub file.

Quite possibly, though I'm equally using an OTF Type 1 version of the same font which is recognised when opening the PDF. Looking at the technical specs for the font which you can view here by hovering over the 'Features' icons I can't see anything to indicate alternate glyphs are an OTF feature of this particular font...

https://www.linotype.com/6044291/wildwords-lower-regular-product.html

Opening the PDF in every PDF Reader I've tried displays the font correctly though copying the text directly from the PDF and pasting it into any other application shows the same issue, i.e., alternate lower and uppercase characters where the same character is used consecutively...

Opening the PDF in Curve which maintains font editability exhibits the same issue though with Pixelmator the text is converted to Curves which is why it doesn't exhibit the same problem so there is something odd going on with this particular font...

I'm sure @kenmcd will have some helpful insight into the cause of the issue...

[kenmcd]

The error is in the creation of the PDF from APub.

CC WildWords Lower has ligatures for uppercase characters when there are two of the same character next to each other.
Like: CONNECTING
The NN is replaced by a ligature in which the two Ns look slightly different.
The name of that ligature is n_N.
All of the ligatures are named like that. a_A, b_B, c_C, etc.
This appears to be confusing APub.

Note: these are Standard Ligatures (liga) so they are On by default.

APub should embed in the PDF two uppercase characters.
But the code behind the first character is instead for the lowercase character.
It is embedding the Unicode for: COnNECTING
When opened in APhoto for editing it displays that lowercase character.

So the fix has to be in how APub creates the PDF.

Work-arounds...
Actually convert it to uppercase - but you will lose the pseudo-random characters.
Turn-Off Standard Ligatures - but you will lose the pseudo-random characters.
Place the PDF as pass-through.
Convert the PDF to curves.

 

[walt.farrell]

1 hour ago, kenmcd said:

APub should embed in the PDF two uppercase characters.
But the code behind the first character is instead for the lowercase character.

So this isn't the usual Affinity issue that occurs with ligatures when the Export uses font subsetting?

[kenmcd]

42 minutes ago, walt.farrell said:

So this isn't the usual Affinity issue that occurs with ligatures when the Export uses font subsetting?

No, does not appear to be.
In those cases it is completely off (like the character mapping is off).

In this case it appears to be some weird interaction between the All Caps function and the OpenType replacements - and those ligature names.
My WAG is some code does not play well with those glyph names.

[kenmcd]

@Mark Favreau
You could use the CC WildNames font (not CC WildNames Lowercase).
It is all caps and the ligatures/alternates are handled differently.
The lowercase is all caps also, but the shapes are different from the uppercase.
And the OpenType code for the alternates works differently.
The substitutions are between the uppercase and lowercase versions,
not with any oddly named ligatures.

That font may work-around these issues.

[Hangman]

@kenmcd,

Out of pure interest, why do all (at least the several I’ve tried) PDF Readers display the respective CC Wildnames Lowercase ligatures ‘correctly’?

[walt.farrell]

3 minutes ago, Hangman said:

Out of pure interest, why do all (at least the several I’ve tried) PDF Readers display the respective CC Wildnames Lowercase ligatures ‘correctly’?

Because they're displaying the curves, perhaps?

Try (from the original PDF in this thread) opening it in Acrobat Reader, selecting the text, copying, and pasting into a text editor. You'll get nN, for example, not NN even though that's the way Acrobat Reader displayed it.

[Hangman]

7 minutes ago, walt.farrell said:

Because they're displaying the curves, perhaps?

Try (from the original PDF in this thread) opening it in Acrobat Reader, selecting the text, copying, and pasting into a text editor. You'll get nN, for example, not NN even though that's the way Acrobat Reader displayed it.

As mentioned in my previous post but should Acrobat Reader (and all other PDF Readers) not display the actual font as indicated in the display properties tab? I’m just curious as to why PDF readers would all display the ligatures correctly or effectively incorrectly if they’re actually designed as a_A, b_B, c_C, etc?

[walt.farrell]

54 minutes ago, Hangman said:

As mentioned in my previous post but should Acrobat Reader (and all other PDF Readers) not display the actual font as indicated in the display properties tab? I’m just curious as to why PDF readers would all display the ligatures correctly or effectively incorrectly if they’re actually designed as a_A, b_B, c_C, etc?

Remember that the PDF contains both font information and shape/curve information. I think that PDF viewers generally display based on the curve/shape info, which is always present. Affinity does not use that info when Opening a PDF, though it will use it when Placing in Passthrough mode.

[kenmcd]

4 hours ago, Hangman said:

@kenmcd,

Out of pure interest, why do all (at least the several I’ve tried) PDF Readers display the respective CC Wildnames Lowercase ligatures ‘correctly’?

PDF Readers just display the shape that is there for that text object.
Which is exactly what they are supposed to do.
Show me the shapes.

The shape that is placed in the PDF (and connected to the Unicode code point) can vary based on the OpenType features applied.
For example you could apply the swash feature to the T in The and OpenType will substitute an alternate big swashy T glyph (shape) for the original plain T glyph (if the font has this OpenType feature).
That swashy T shape is what gets embedded in the PDF.
The underlying Unicode code point remains the same.
So if you copy and paste that swashy text you will still get "The".

When Affinity opens a PDF it is opened for editing, so for text objects it reads the underlying Unicode code point, and then goes to the font to get the character (and the normal shape associated with that character).
Since there is no OpenType feature applied to that text, you see the normal shape.

Same thing happens with small caps.
The underlying character code point remains the lowercase character.
If you copy-and-paste small caps from a PDF, you will get lowercase text.

So what shape gets embedded/displayed in the PDF can be multiple different alternate shapes - for one same Unicode code point.

In this case the characters should have all been converted to uppercase code points - but for one character it displays/embeds the "correct" uppercase glyph (shape), but applies/embeds the lowercase code point.
Something is not working correctly.
My guess is that there is some odd interaction between the All Caps feature and the OpenType ligatures.

Make sense?

[Hangman]

Hi @kenmcd,

Many thanks for the detailed explanation, yes that makes sense and is certainly helpful to know...

[AdamW]

Typically we output text as unicode code points, but here because there is no unicode representation of the double letter ligatures included in the font we output them as glyph indexes.

Subsequently we build a 'ToUnicode' map for the font that is embedded in the PDF and which can be used to map glyph indexes to (sequences, if necessary, of) unicode code points for PDF reader applications. This is the part of the export that is causing the issue. One heuristic we employ is to look at the glyph names in the font. Typically / conventionally e.g. an 'fi' ligature will have the glyph name 'f_i'. In the case of CCWildWords it rather unhelpfully names its double uppercase letter ligatures with names such as 'a_A', 'b_B'. This isn't incorrect, but does lead our ToUnicode mapping to represent each ligature as a lowercase / uppercase pair. Currently I see this very much as an edge case as it will only occur with a font with such 'unhelpfully' named ligature glyphs.

[kenmcd]

@Mark Favreau

I tested WildWords and it does work.
Re-opening the PDF in Affinity looks correct.
But only because the font has uppercase glyphs in both the uppercase and lowercase code points.

I tested text that is:
- All Uppercase
- Uppercase and Lowercase
- Upper and Lowercase - with All Caps applied.

The actual text codes for the text in the re-opened PDF are:

WildWords (not WildWords Lower)

All Uppercase
CONnECtED

Uppercase and Lowercase
ConNecTed

Upper and Lowercase - with All Caps applied
CONnECtED

But it still looks the same because of the font:

 

@AdamW
The substitutions are done differently in the WildWords font,
but there are still quite a few errors in the embedded text (or ToUnicode table).