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.

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.

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

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.

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

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

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

Odd that the bold weight comes out ok, no?

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

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