Font encoding logic in Scribus - Custom vs Identity-H?

Previous topic - Next topic

datro

Scribus 1.5.6.1
I created a simple 1-page document which uses a single font:  Lato (TrueType).  The document has only standard alphanumeric characters in it, nothing that does not exist on a standard U.S. English keyboard.

When I save this document to PDF and fully embed the font, my PDF Viewers (including Acrobat Reader) report the encoding as "Custom".  One of the viewers does not properly handle the font encoding and displays gibberish.   Acrobat Reader handles it fine.

When I save this document to PDF and only subset embed, all the PDF Viewers report encoding as "CID/Identity-H" and they all display and print it just fine.

Why does Scribus use different encoding in these two scenarios?

My understanding is that both Identity-H and Custom are valid PDF font encoding methods (at least in terms of the PDF specification), but clearly there are some readers out there that do not seem to handle Custom encoding.

If I'm not concerned about the viewer that can't properly display documents with Custom encoding, should I fully embed, i.e. is fully embedding generally better overall?

What am I giving up if I always use subset embedding (and therefore always getting Identity-H encoding in Scribus)?





Nermander

Quote from: datro on April 16, 2021, 04:54:36 PM
One of the viewers does not properly handle the font encoding and displays gibberish.   Acrobat Reader handles it fine.

Then why do you not submit a bug report for that viewer?

If Adobe Reader displays the the PDF correctly, the PDF is likely correct.

I have no idea why Scribus uses different font encodings when embedding fonts, I do remember that I have read that there are limitations on what types of fonts can be embedded in a PDF, so very often Scribus have to re-encode before embedding.