Re: [NTG-pdftex] [pdftex] Font (embedding) problem
![](https://secure.gravatar.com/avatar/c1389d0584ea3ced1cff3450a93f7372.jpg?s=120&d=mm&r=g)
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 -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/ceb965f718d9d81e8a49c8f876c5bf41.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/1777c1196c75a513aa09290f14b94c30.jpg?s=120&d=mm&r=g)
On 12/04/07, Eddie Kohler
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.
No, I didn't use lcdf-tools, it wasn't an OTF font. I was wrong in my initial mail. When using a different font encoding with the same PFB fle (produced by lcdf-tools), everything was ok. I created the subsets using Fontforge, manually, and put the right characters in the right positions, so I could use them with pdfTeX. Sorry for this confusion caused, I was not wholly clear. Regards, Marcel
![](https://secure.gravatar.com/avatar/ceb965f718d9d81e8a49c8f876c5bf41.jpg?s=120&d=mm&r=g)
Fonts produced by lcdf-typetools usually work fine with pdftex!... ?? Eddie Marcel Korpel wrote:
On 12/04/07, Eddie Kohler
wrote: 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.
No, I didn't use lcdf-tools, it wasn't an OTF font. I was wrong in my initial mail. When using a different font encoding with the same PFB fle (produced by lcdf-tools), everything was ok.
I created the subsets using Fontforge, manually, and put the right characters in the right positions, so I could use them with pdfTeX.
Sorry for this confusion caused, I was not wholly clear.
Regards, Marcel
![](https://secure.gravatar.com/avatar/1777c1196c75a513aa09290f14b94c30.jpg?s=120&d=mm&r=g)
On 12/04/07, Eddie Kohler
Fonts produced by lcdf-typetools usually work fine with pdftex!... ??
Yes, that's true. As I said, the problem wasn't a font created with lcdf-typetools, as I initially thought, but a font re-encoded manually using FontForge. When trying to use an OTF-font using lcdf-typetools, everything went fine when using this printer. Regards, Marcel
participants (3)
-
Eddie Kohler
-
Marcel Korpel
-
Reinhard Kotucha