On Monday 18 December 2017 13:11:20 Hans Hagen wrote:
Anyway, exactly same problem is for Type 1 fonts. If you have two different shapes for b in Type 1 font, then only one can have glyph name 'b'.
i've never seen a type 1 font with two 'same names' for different shapes ... it would qualify as 'a font to avoid'
Yes, two 'same names' for different shapes is not something which is supported in Type1 (and maybe it is not possible... have not looked at specification in details). But... I mean this: how to handle situation if you create font in which there are two different shapes for character 'b' and you want to store this font in Type1 format? You need to choose something like b.variant1 and b.variant2...
What does one expect with cut and paste?
The expected behavior for ordinary user is simple: Both glyphs which are marked as 'b' should be copied as character 'b'.
It can work only in PDF viewers with correct CMap support. But with current pdftex code it is not possible.
viewers can yuse the names instead
But you are right that this is a real problem. Some calligraphic fonts have more glyphs for one character. And decision which glyph needs to be used is based on previous or next characters.
then there's something a.varianta, a.variantb, a.variantc and a cut and paste will use the 'a' part to identity the name, just like f_f_i is a convention for a ligature
If two names are the same and they refer to the same font program then there is no problem and the first one encountered when embedding should be used.
If remove duplicates is an option in pdftex then at least make sure that it's off by default (better complain loudly on the console that the enc is broken)
Do you want to be this problem a fatal error?
Fatal in the sense that a viewer crashes?
I mean in context of pdftex. What should pdftex do if its gets such enc file on input?
Sure. Then at least I know that the 'b' in a font is probably not a 'b'. Also, in that case it's a signal to avoid that font. (The same can be true for embedding fonts with bad font names that clash.)
FYI: I decided (in context with luatex at least) to *not* use the fontloader but write one on lua that stays close to the original font and avoids the usual heuristics ... it's hard to fight (bad or fuzzy) heuristics as they obscure problems.
so that the user knows that enabling that option is not solving the problem (and in tex distributions the fixed enc should be used). Heuristics and fixes for bugged fonts are nice but not being able to bypass them is bad.
I thought it would be better to produce PDF file as enc file itself does not change how PDF file is rendered. It affects only copy+paste from PDF file.
But why not fix the enc file?
Yes, proper way is to fix enc file. I think we have no doubts about it. But the whole discussion is... what should pdftex do if user puts such buggy enc file for particular font?
Makes me wonder how these bad enc files can show up at all, as those type 3 fonts are very old school and therefore the problem of duplicate names for different shaped should also have been seen with dvips and so.
Personally, I do not know how many enc files contains duplicates and even if they are any widely used. For pdftex patches, I specially prepared different enc files to test that pdftex with my patches does not crash (either print fatal warning or produce PDF) and that I always get PDF file rendered in same way as enc files must not affect how PDF file is rendered. And I observed problem when enc file contain one glyph name more times, therefore I added that code which deals with duplicates. -- Pali Rohár pali.rohar@gmail.com