OTF output to Acrobat problem

Nick Cooke's picture

I have developed an Opentype family for a client. I generated them all and produced a test document using InDesign CS3 and exported the document as a pdf to Acrobat 8. So far so good.

The client sent an email last week which stated that they had done the same thing in InDesign CS4 and exported the document as a pdf to Acrobat 9. Both documents were fine. They then sent the pdf to their printer who tried to open the pdf in Acrobat 7. Using Acrobat 7 the OpenType font appears as 'notdef' symbol apart from a couple of characters.

The so-called technical expert at the printers is insisting that the font is corrupt and unusable, whereas I think it is an Acrobat issue. He knows that he can just download the latest version of Acrobat 9 for free, but for some reason insists on using Acrobat 7, making out that downloading and installing the latest version would be a major inconvenience, while insinuating my incompetence.

The strange thing is that an earlier Postscript typeface (in blue) displays with no problem in both versions of Acrobat. Have I done something wrong when generating the OTF?

Has anyone else had this incompatibility problem with InDesign CS4, OpenType fonts and versions below Acrobat 8?

Thanks in advance for any replies.

bemerx25's picture

I think the issue is from trying to open up a newer PDF-version file with an old version of Acrobat. Try a test - save your PDF's down to Acrobat 5 level and see if the printer can open that successfully. If so, that proves that it's Acrobat 7 at fault and not the font.

AGL's picture

If possible, convert the fonts to outlines. Output to a .ps, distill, done.

If no Acrobat present, convert to outlines, save as eps, drag to Apple Preview, it distills the file and give you a good pdf. Done.

Nick Cooke's picture

If only it were that simple André. I know that would be a perfectly workable solution but the client has paid for custom typefaces - they want to use the typefaces, not turn them to outlines.

After the technical expert at the printers so unhelpfully stuck the boot in, the client now believes there is something wrong with the fonts.

I need to know if this is a compatibility issue with CS4 programs and pdf's viewed on Acrobat 7 or lower.

Ben - I don't have CS4, I'm still on CS3 so I can't replicate the problem, but thanks anyway.

Nick Cooke

Quincunx's picture

What version of Acrobat did you select by 'Compatibility' in the PDF export options?

Set it to Acrobat 5.0 (PDF 1.4). Or choose PDF/X-1a:2001 under 'Standard', which sets it even to Acrobat 4 (PDF 1.3). I don't think it has anything to do with CS4, but with compatibility settings.

He should be able to open the PDF in his old Acrobat 7.0 then.

Nick Cooke's picture

Somebody has been looking into this and this is their response:

The font in question is broken/invalid inside the PDF (don’t know about the original, but whatever embedded and/or modified the embedding killed it).

A Type 1 font’s built-in encoding shall be defined by an Encoding array that is part of the font program, not to be confused with the Encoding entry in the PDF font dictionary.

The encoding array in the problematic font has only ONE ENTRY (the ‘A’, which is why it displays correctly).

We have code now in CT/PDFL/Acrobat that detects this bogus case and falls back to using the Encoding from the PDF font dictionary instead of the embedded Encoding...

I have no idea what this means, But I presume it relates to CS4. I do know the font does not have a standard Adobe character list, and when I generated the font window name was set to 'MacOS Roman' - maybe it should be set to 'Imported'?

Where is the info for the encoding array in the font which shows only ONE ENTRY?

Nick Cooke

Miguel Sousa's picture

> A Type 1 font’s built-in encoding shall be defined by an Encoding array

This should usually be set to StandardEncoding. In FontLab this can be achieved through the Preferences. But you're generating an OpenType font from FontLab, so I'm not sure how this option affects that.

Nick, I have CS4. If you send me one of the fonts I'll test it along with some of our fonts.

Thomas Phinney's picture

Yes.

I believe that even in FontLab, this determines the encoding used inside the CFF table, which is independent of the encoding used in the cmap table. My recollection is that using stuff other than StandardEncoding for the CFF table can cause problems....

(Miguel, if you want more info on this, I think Sairus may have been involved in investigating the issue. David might also remember.)

Cheers,

T

Bendy's picture

Odd that the bold weight comes out ok, no?

Nick Cooke's picture

Yes - that's an old Postscript Type 1, but then again they were much simpler to generate in Fontographer; no need to fill in loads and loads of info boxes with the potential of getting something not quite right.

Nick Cooke

Nick Cooke's picture

Yes - that's an old PostScript Type 1, but then again they were much simpler to generate in Fontographer; no need to fill in loads and loads of info boxes with the potential of getting something not quite right.

Nick Cooke

polyglot opa's picture

Nick,
I know this is an old question, but I've just encountered a similar problem by another means. I'm a Ventura user and have found difficulty with the interface between Ventura and Acrobat, mostly related (I believe) to the amount of RAM available. In replacing an old desktop with a new machine with 8 MB of RAM, running Ventura 10 and Acrobat X, I discovered when I tried to use Adobe's Caslon Pro in its .otf format, Ventura would display the typeface with no trouble, would print to an HP 1320 with no problem, but Acrobat would generate blank pages whereever I had the .otf font. Acrobat printed rules (e.g., crop marks) fine and rendered heads and subheads that used a .ttf font, but NO GO on the .otf. When I uninstalled the Caslon Pro set of fonts, converted the 4 weights to .ttf, and reinstalled, I was able to generate a pdf (though a request for a pdf of the entire publication elicited an error message in Acrobat). Using CorelDraw X3 for comparison, I found when I changed the text to the .otf font, the text disappeared in Draw. So the problem must be a matter of interface between .otf and some applications (notably both Acrobat and Draw).

Syndicate content Syndicate content