Placed PDFs in Publisher

[JeremyTankard]

Placed PDFs still appear to have issues.

. . . refering to a previous post

 

1. Text that is styled with OpenType features that modifies the glyphs with no unicode is not recognised. i.e. if default lining figures are styled a Old Style ones. They are fine in the PDF but when this PDF is placed in Publisher those figures show up in the placed page as the default lining ones, albeit in the correct font still.

2. Placing a PDF shows the embedded fonts correctly (except for point 1 above).
However, printing the PDF isn't correct
(i) doesn't print the embedded fonts
(ii) turns the PDF to a rasterised image

In the attached screen grab the postage label PDF has been placed in Publisher = all OK. But printing it (shown alongside as 'Print/Open in Preview) shows that the embedded font is missing and the whole has been pixelated as an image.

[kenmcd]

4 hours ago, JeremyTankard said:

1. Text that is styled with OpenType features that modifies the glyphs with no unicode is not recognised. i.e. if default lining figures are styled a Old Style ones. They are fine in the PDF but when this PDF is placed in Publisher those figures show up in the placed page as the default lining ones, albeit in the correct font still.

This is just the way PDFs and OpenType work. No OpenType info is stored in a PDF.
When alternate glyphs (with no Unicode code point) are substituted, the Unicode code point for the original character is used.
In PDFs the advantage here is that search still works because the original Unicode codes are still there.
And if a new font is applied all the characters are still there.
If the font designer decides to assign Unicode code points to the alternate replacement glyphs up in the Private Use Area (PUA), yes, they will round-trip through a PDF because code points are there, but search no longer works, and if a different font is applied the characters are possibly not there at all.

Options:

1. Oldstyle figures are the default figures.
   Many fonts designed for running text have proportional oldstyle figures as the default figures,
   because it makes more sense when that is the style you use the most.
   Either use a font which already has this, or modify the font so it does have this.
2. Assign Unicode code points to the alternate oldstyle figures.
   Some fonts are designed this way, or the font can be modified to add this.
   The limitations/issues described above will apply. 
   And you can add figures one-by-one only when needed in specific spots using any character map.
3. Duplicate the oldstyle figures (leaving the originals with no code point),
   assign a code point to these duplicates, and assign them into a stylistic set.
   This way you can have it either way.
   Use the Oldstyle Figures feature if you do not want the PUA code point.
   Use the Stylistic Set feature if you do want the PUA code point.

What font are you using?

 

Regarding your #2 above, I think we will need to see the actual PDF.

 

[JeremyTankard]

I get the unicode issue, but this was never a problem with placing PDFs in InDesign.

The PDf is OK but its placing it back in an Affinity app where the problem starts.
Is it that Affinity wants to 'unwrap' the PDF so it can be edited?

[walt.farrell]

On 5/15/2021 at 8:06 AM, JeremyTankard said:

1. Text that is styled with OpenType features that modifies the glyphs with no unicode is not recognised. i.e. if default lining figures are styled a Old Style ones. They are fine in the PDF but when this PDF is placed in Publisher those figures show up in the placed page as the default lining ones, albeit in the correct font still.

You might need to use different Export options. Specifically, click on More... in the Export dialog, scroll down to Embed Fonts, and make sure that:

1. It says All Fonts and
2. Subset Fonts is disabled.

[kenmcd]

42 minutes ago, JeremyTankard said:

I get the unicode issue, but this was never a problem with placing PDFs in InDesign.

I am wondering if (guessing) ID is saving extra/different info in the PDFs it creates which allow it to recreate OpenType features.
But I would have to see the ID generated PDF to see how it is different from the APub generated PDF.

I do know that ID does correctly create the ToUnicode table in the PDF when fonts are sub-setted, while APub does not.
This is why walt is suggesting you disable sub-setting the fonts - to work around that issue.
But I do not think that will help here as the characters have no code points anyway.
If it does help, then I still have not figured-out what is actually going on.

[MikeW]

22 minutes ago, LibreTraining said:

I am wondering if (guessing) ID is saving extra/different info in the PDFs it creates which allow it to recreate OpenType features.
But I would have to see the ID generated PDF to see how it is different from the APub generated PDF.

I do know that ID does correctly create the ToUnicode table in the PDF when fonts are sub-setted, while APub does not.
This is why walt is suggesting you disable sub-setting the fonts - to work around that issue.
But I do not think that will help here as the characters have no code points anyway.
If it does help, then I still have not figured-out what is actually going on.

InDesign, et al, uses a true passthrough. The only time a pdf is "touched" is if a forced color profile is changed. Under that circumstance, only tagged elements are recharacterized for the new color profile. InDesign cannot open a pdf for editing. Period. So this issue is not present in ID, QXP, Viva Designer, etc.

[kenmcd]

3 minutes ago, MikeW said:

InDesign, et al, uses a true passthrough. The only time a pdf is "touched" is if a forced color profile is changed. Under that circumstance, only tagged elements are recharacterized for the new color profile. InDesign cannot open a pdf for editing. Period. So this issue is not present in ID, QXP, Viva Designer, etc.

So they are not actually importing characters, but rather just displaying the glyphs that are there - avoiding the whole OpenType issue.
Obviously this avoids a lot of issues when compiling multiple documents into one.

Somebody tested a bunch of the ID vs. APub PDF stuff awhile back, cannot remember, was that you?
Gotta find that thread again. And do some of my own testing.
Currently completely Adopey-Free, but I really need to install ID in a VM so I can test this stuff. Ugh.

[walt.farrell]

1 hour ago, MikeW said:

InDesign, et al, uses a true passthrough. The only time a pdf is "touched" is if a forced color profile is changed.

How does that differ from Affinity's Passthrough function?

[JeremyTankard]

1 hour ago, MikeW said:

InDesign cannot open a pdf for editing. Period. So this issue is not present in ID, QXP, Viva Designer, etc.

I think this is it.

I would expect that the recently added ability to 'Place a page' in Publisher to behave like this.
I presume this would then let the PDF and its embedded content appear as it does in a PDF Reader application – all intact AND not be rasterised.

[MikeW]

@LibreTraining,

Yes to the first two paragraphs. At least as regards the first paragraph and I did post a screenshot or two comparing how pdfs are encoded. 

[walt.farrell]

3 minutes ago, JeremyTankard said:

I presume this would then let the PDF and its embedded content appear as it does in a PDF Reader application – all intact AND not be rasterised.

And that's what happens, or is supposed to, in an exported PDF file (though not while you're viewing/editing the Affinity file.

[MikeW]

4 minutes ago, walt.farrell said:

How does that differ from Affinity's Passthrough function?

Like in the thread Jeremy linked to in the first post in this thread, Affinity applications are still opening a pdf as if for editing. This is not true, full, pdf passthrough. 

[JeremyTankard]

Here's a quick side by side. The PDF used here is one made on demand from the UK Royal Mail online postal service. You buy the postage and download the label. I'm then placing this PDF in an AfPub template I made to print out on sticky labels. Anyway. This screen grab shows the placed PDF in AfPub and also in InDesign (CS6).

AfPub places the PDF as Passthrough so it 'appears correct' but it is rasterised (almost as a hi-res preview image) whereas the same placed in InD is not rasterised and shows (and prints) sharp. If I change the AfPub from Passthrough to Interpret it drops the embedded font totally and actually displays what it prints. Obviously just printing the PDF from Preview or Reader prints OK.



 

[walt.farrell]

5 minutes ago, JeremyTankard said:

Here's a quick side by side. The PDF used here is one made on demand from the UK Royal Mail online postal service. You buy the postage and download the label. I'm then placing this PDF in an AfPub template I made to print out on sticky labels. Anyway. This screen grab shows the placed PDF in AfPub and also in InDesign (CS6)

I think we would need the PDF and the .afpub file in order to make any good comments.

[Patrick Connor]

1 hour ago, MikeW said:

Affinity applications are still opening a pdf as if for editing. This is not true, full, pdf passthrough.

Only for display purposes. When set to Passthrough, the unedited PDF is passed through untouched when exported. 

[MikeW]

38 minutes ago, Patrick Connor said:

Only for display purposes. When set to Passthrough, the unedited PDF is passed through untouched when exported. 

Without Jeremy's pdf, I couldn't say whether that is true of his pdf or not.

But true pdf passthrough doesn't interpret for any purpose, including for display purposes. And, in the least, it doesn't have issues in exact passing it through. That aside from the other issues he reports both in this thread and the linked to thread.

[JeremyTankard]

I couldn't send the Royal Mail PDF as it contains personal info. So I've made test files.

1. I set an A4 in Apple Pages and Exported as PDF. Then removed the Retail and Corpoarte font used from the Fonts folder so Publisher couldn't reference them. (Just realised that Calibri isn't a system font it's shipped with MS Office)

2. I placed this Test font.pdf into Publisher – as expected it ratserises the PDF

3. Print and Print (save as PDF) drops the embedded font info.

Test files.zip

[MikeW]

8 hours ago, JeremyTankard said:

I couldn't send the Royal Mail PDF as it contains personal info. So I've made test files.

1. I set an A4 in Apple Pages and Exported as PDF. Then removed the Retail and Corpoarte font used from the Fonts folder so Publisher couldn't reference them. (Just realised that Calibri isn't a system font it's shipped with MS Office)

2. I placed this Test font.pdf into Publisher – as expected it ratserises the PDF

3. Print and Print (save as PDF) drops the embedded font info.

Test files.zip 1.33 MB · 0 downloads

I opened your pdf, exported using the pdf (press ready) preset and -x3 preset. The attached is the first preset.

I'm using Windows.

Test font PDF placed in AfPub.pdf

[JeremyTankard]

I get a correct PDF when I export to PDF. – I hadn't tried that!

So the issue only seems to appear

(1) viewing as pixelated in AfPub
(2) when printing from AfPub
(3) when making a PDF saved from the Print dialogue (Mac)

Can you try printing you test Mike and see what you get.

The attached file is what I get when I place the PDF in AfPub and the Print and Save as PDF (Mac), the actual print out is also like this – missing fonts and styling

Interestingly the double tt ligature in Calibri is turned into a '3' as it isn't a unicode glyph and the oldstyle 56 are (). The glyph naming must be screwy in the font file, usually the glyph variants would route back to their core glyph: t_t.liga would break to t t , and five.osf would break to five etc.
 

Test font PDF placed in AfPub (Print & Print as PDF).pdf

[walt.farrell]

23 minutes ago, JeremyTankard said:

So the issue only seems to appear

(1) viewing as pixelated in AfPub
(2) when printing from AfPub
(3) when making a PDF saved from the Print dialogue (Mac)

Those are all areas where Passthrough does not apply in Affinity. It applies specifically to Exporting a PDF. For other contexts you must have all the fonts from the PDF installed.

[Patrick Connor]

27 minutes ago, JeremyTankard said:

So the issue only seems to appear

(1) viewing as pixelated in AfPub
(2) when printing from AfPub
(3) when making a PDF saved from the Print dialogue (Mac)

(1) We have to show something inside the application. Our interpreter is not perfect and so for passthrough we get a preview drawn and use that. The preview is pixelated, and only for display purposes when using the passthrough option. If you HAVE to print your file you are probably best to not place it with passthrough set, as then it will be rendered as best as it can be, rather than just having a pixel preview/approximation.

(2) Printing from AFPub will use the preview, as print drivers do not accept PDFs, they need to have text vectores or images drawn to them, so passthrough has no meaning in respect of the print codepath.

(3) See point 2

Passthrough is specifically for exporting as PDF, and then ONLY when the format of that exported PDF is the same or compatible with the PDF being placed.

[MikeW]

@JeremyTankard,

I never print directly from any layout application, regardless of placed content. I get the same results as you from APub if I do. 

No other applications do this with a placed pdf if, like the content from your APub-generated pdf, contains vector data.

[kenmcd]

1 hour ago, JeremyTankard said:

Interestingly the double tt ligature in Calibri is turned into a '3' as it isn't a unicode glyph and the oldstyle 56 are (). The glyph naming must be screwy in the font file

Calibri has no glyph names.
Most Microsoft/Windows core fonts have no glyph names.
For the OpenType feature code they use the glyph ID (the glyph number).
Only time I have ever seen this is in the Microsoft/Windows fonts.

 

[JeremyTankard]

 

1 hour ago, walt.farrell said:

Those are all areas where Passthrough does not apply in Affinity. It applies specifically to Exporting a PDF. For other contexts you must have all the fonts from the PDF installed.

So a way around is to place the PDF in  the tempalte, then Export as PDF and then Print the Exported PDF (bit laughable, but so be it)

All I know is that this is not an issue with InDesign.
And I think this quite a problem/limitation with the application.

[Ervin Hajdú]

I am struggling with the same problem when I have to print our partner's PDFs. I uploaded an example: in the background (right) is the Publisher with the imported file (Passthrough), in the front (left) is a black and white print with bad fonts (Xerox Color C60 FFPS PS).
I can print the received material well with Indesign, and I can even open it perfectly with Corel DRAW (with Import text as curves option).