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)?