APublisher ignores OTF features on import

[Joachim_L]

See attached image upper font Kabala, lower Milo. Left side typesetting in Publisher, right side imported PDF of the same page. Unfortunately I cannot look at my work if the fonts have the GSUB table lookups as required from PDFLib.

 

Edited March 25, 2019 by Joachim_L
Misleading title changed

[kenmcd]

How the PDF is created can have an effect on how well it is imported.

I tested your two fonts above using LibreOffice.
First I simply exported to PDF which embeds sub-setted fonts.
The PDF looked fine.
Then I imported that to APub.
Similar results to yours above - superscript/subscript was bad and old style figures.

Then I printed from LibreOffice to a PDF printer which force embeds the entire fonts.
The PDF looked fine again.
Then I imported that to APub.
This time the correct characters appear in APub.
The image below is that PDF imported to APub and then exported to a PNG.

So how the PDF is created has an effect on how well it imports.
I have good results when full fonts are embedded.
Some users have reported they have no character issues when importing from ID.

 

[Joachim_L]

So how to fully embed the font a) Indesign and b) APub?

a) Smaller than 1% or 0% makes no difference. PDF loses the information during import to APub. Preview is correct, but not the placed PDF in the end.

b) Unchecking Subset in APub makes no difference. PDF loses the information during import to APub. Preview is correct ...

So I am stuck here. Anyway, if the OTF feature of the font is used, why is this information not passed on? At least the characters used have to be embedded?

[kenmcd]

The OpenType features are not imported, just the characters or outlines.
So how those characters are identified is part of the problem.

InDesign (and all Adobe apps) will never embed the full font.
It will always do a subset even if the font has no restrictions (allows installation).

It appears that APub also does this; only embed sub-sets.

I have found that when apps sub-set the fonts, that even though they embed the correct glyph outline, the underlying Unicode identifies the original characters.
So that is why when the numbers are imported they are the original default figures,
not the OpenType applied lining figures, because those are the codes on the figures.

When the full font is embedded the underlying Unicode applied to the characters is different.
Apparently there is some sort of translation table included in the PDF because the codes on these characters do not correspond to the code points in the font file.
So I do not know the exact mechanism at work.

If PDFs from InDesign can properly identify a particular character applied via an OpenType feature so they will import to APub properly that means ID is also including some sort of translation table in a sub-setted font (per some info I found in Stack Exchange).
I have not tested this with a PDF from ID; some other users have mentioned it.

This also means the PDF library used in APub can read this translation table.
As evidenced by my example above being imported properly.

To answer your question on how to output a PDF which will import properly, I do not know.
I have not tested to see what happens when the PDF is exported with various standards.
Perhaps PDFs created with PDF/X or PDF/A will have better import results.

So far the only way I have found which import the correct characters from OT features is using fully embedded fonts from PDFs I have created using the PixelPlanet PDF printer.

Keep in mind that the character outlines are imported not the OpenType features.
Once you start editing you will need to redo anything with OT features applied.