[pdftex] Font (embedding) problem
kohler at cs.ucla.edu
Thu Apr 12 03:05:46 CEST 2007
How did Marcel create the subsets? I imagine that pdftex was
responsible for the real subsetting; that the lcdf-typetools simply
created the initial font.
Any subset should remove any /UniqueID and Private /UniqueID, then alter
the font's /XUID array, usually by appending numbers to it that are a
fingerprint of the subset. All modern printers will do the right thing
with /XUID. If you don't modify /XUID, you should remove it.
The specs say that two distinct fonts must not have the same /XUID (or
/UniqueID, if /XUID doesn't exist). Otherwise printers are allowed to
do horrible things. (Fonts with different /Encoding vectors or
/FontMatrix manipulations may have the same UniqueID without problems.)
The lcdf-typetools that alter glyphs, such as mmpfb, already fixed /XUID
and killed /UniqueID. **EXCEPT** that I totally forgot t1dotlessj,
which creates a dotless-j glyph font, and didn't change the UniqueID
there. Now I do (in version 2.62).
Reinhard Kotucha wrote:
> Hi, I now added pdftex, NTG-pdftex, and Eddie to the CC.
> For people who did not follow the thread on the pdftex mailing list,
> here is a short summary:
> Marcel created some subsets of an OTF font using lcdf typetools. One
> subset used normal figures, one used oldstyle figures and one used
> superscript figures. His printer produced wrong output.
> I examined the output files produced by pdftex: All the subsets used
> the same encoding scheme, the glyph names had been /one, /two, and
> /three in all subsets, the /UniqueID is the same in all subsets. The
> only difference was /FontName since an arbitrary string had been
> prepended to the original /FontName.
> It turned out that Marcel's printer ignores /FontName and entirely
> depends on the /UniqueID. I converted the three subsets to PFA and
> wrote a small test file and even Ghostscript (-sDEVICE=X11alpha)
> produced wrong output. See:
> It works with gs if you comment out the /UniqueID in testfonts.ps but
> this seems not to be sufficient for Marcel's printer because:
>>>>>> "Marcel" == Marcel Korpel <marcel.lists at gmail.com> writes:
> > On 04/04/07, Reinhard Kotucha <reinhard.kotucha at web.de> wrote:
> >> The current release (1.40.3) does this already. At least it
> >> removes the first occurrence of the UniqueID. But there is still
> >> a UniqueID in the /Private dictionary. Maybe it should be
> >> removed too. I'm quite confident that no interpreter looks for a
> >> UniqueID in the /Private dictionary.
> > Well, at least the mentioned Océ printer seems to use it. When I
> > only remove the first instance of the /UniqueID, the bug pops up
> > again...
> In my opinion it is wrong to ignore /FontName. But on the other hand
> I think that it is also wrong *not* to delete the /UniqueID when a
> subset of a font is created. I don't know what the Adobe reference
> manuals say, the nasty things are in the TechNotes, but it seems that
> developers of PS interpreters interpret the specs slightly different
> Though I think that the /UniqueID is helpful to distinguish between
> Adobe Courier and IBM Courier (shipped with X11), I now come to the
> conclusion that it causes more trouble than it helps.
> I don't think that it's bad that a font provides a /UniqueID. But it
> is probably quite appropriate to remove it when a subset is created.
> The current release of pdftex deletes the /UniqueID from the font
> dictionary but not the instance in the /Private dictionary. But
> certainly it should.
> I also think that lcdf typetools should remove the /UniqueID if a font
> is altered.
More information about the pdftex