Glyphs mix-up in exported InDesign CS2 pdf files

Paul Dieterman19 Jul 2006

Some time ago I made a Open Type font family, regular, italic, bold and bold italic. When I export a pdf from InDesign CS2 everything looks ok on screen, but when I print the pdf with Acrobat 7.08 to our Canon C2620 color printer I get a strange mix-up of italic and regular glyphs. It’s not in a random way, the scheme is as follows:

For Regular I get this:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
1234567890

Same result with italic:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
1234567890

Bold behaves as it should:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
1234567890

Bold Italic behaves like regular and italic:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
1234567890

One of our printshops had similar results, that’s the reason I jumped in and started to do some testing. I observed the following:
Printing the doc straight from Indesign CS2: OK, results as you should expect.
Exporting the doc from InDesign CS2 to pdf, and print that with Acrobat 7.08 to our Canon Color printer: NOT OK, see above.
Exporting the doc from InDesign CS2 to pdf, and print that with Acrobat 7.08 to our Canon B/W non PS-printer: OK
Exporting a similar testdoc with InDesign CS and print that with Acrobat: OK
Distilling the InDesing CS2 doc and print that with Acrobat: OK
Printing to pdf with Ghostscript: OK

I changed the font subsetting from 100% to 0%, no effect. All four styles have unencoded glyphs in the private use area, but I can’t see the relation with this strange behaviour. If I print to file with the canon printer and open the postscript dump, I can’t see anything strange (I am not a PostScript expert however). This postscript file will distill perfectly.
It all hints at an encoding issue but I can’t see why yet: the characters are in place, it’s the glyphs that are mixed up. Maybe an internal naming issue? The fonts were originally created with Fontlab 4.6, generating again with Studio 5 gave the same results.

Anybody any thoughts on this one?

Best regards
Paul

Village19 Jul 2006#

Paul, the issue sounds like one of encoding and Unicode indexing. First off, make sure that all of your glyphs have the correct Unicode index, and that all PUA-codepoint glyphs have the same index across all 4 fonts. Then, before generating, switch all fonts to Codepages view, and choose the MS Windows 1252 Western (ANSI) codepage. (After much trial-and-error, selecting this codepage results in correct behaviour on both Macs and Windows computers.)

Paul Dieterman19 Jul 2006#

Village:
I usually apply Fontlab's default encoding, switching to ANSI doesn't change the erratic behaviour. regarding the use of PUA glyphs I believe there is some debate whether or not to apply them. In the original fonts, generated with FL 4.6 all PUA glyphs had PUA unicode entries, stripping them in Fontlab Studio 5 made no difference. Anyway, like I said, the characters are in place, there seems to be some strange interaction between the fontstyles. If there would be a real problem regarding encoding, it doesn't explain why all pdf files I create will print OK, except for the one I export with InDesign CS2. To add to the confusion, some further tests showed that point size also makes a difference in the kind of behaviour!
To be continued
Paul

Paul Dieterman28 Jul 2006#

Problem solved:
It appeared some of the fonts shared the same "Type 1 Unique ID number". Those id's (remnants of the original Type 1 fonts) were originally unique for each font, but somehow they must have gotten mixed up in Fontlab, but how, I truly don't know. A slip of the (Wacom) pen I guess.
Anyway, this is easy to fix, I just removed them (Adobe doesn't seem to use them as well). But why the described problem shows up under the given circumstances (exported CS2 pdf), that's what I'd like to know.

Thanks
Paul

Captured from commoncrawl.org on 19 Apr 2015. original URL