[NTG-pdftex] [PATCH v4] Allow .enc files for bitmap PK fonts
pali.rohar at gmail.com
Mon Dec 18 13:37:11 CET 2017
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
> > > 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.rohar at gmail.com
More information about the ntg-pdftex