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 writes:

...

On 04/04/07, Reinhard Kotucha 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