[NTG-pdftex] [pdftex] Font (embedding) problem

Eddie Kohler kohler at cs.ucla.edu
Thu Apr 12 03:05:46 CEST 2007


Hi Reinhard,

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

Eddie


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:
> 
>    http://ms25.ath.cx/testfonts.ps
> 
> 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
> anyway.
> 
> 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.
> 
> Regards,
>   Reinhard
> 


More information about the ntg-pdftex mailing list