HELP! Text disappears in PDFs viewed in Reader 7 and 8

Report · May 24, 2009

Can you help me?

As graphic designer i produce magazines with many adverts. I receive the adverts as pdf-files – they are produced in different countries.

I place the adverts in InDesign 6.0.2 (newly updated from CS2)

I produce pdf-files (File menu - Export) of my magazine for high end press and for web publishing.

Viewing the final pdf-file in Adobe Reader 9: the adverts display correctly. No problem!

Viewing the final pdf-file in Adobe Reader 7 and 8:

MANY OF THE ADVERTS HAVE INVISIBLE TEXT.  Just a few glyphs appear where the text should be. The public, viewing the pdf-file at the Internet, are probably using Adobe Reader 7 or 8 and will see the adverts with no text.

Producing the final PDF from the Indd.6 Print menu: Does not show the problem.

Producing the final PDF from Illustrator 14 using “save as” shows the problem.

Producing the final PDF from InDesign CS2: Exactly the same Ads using the same settings DO NOT show this problem.

I have tried out the default pdf-settings and all provided pdf-versions. Font Subset is set to zero.

Trying solving the problem I found that:

The print menu Indd.6 uses Quartz PDFContext converter

InDesign CS2 uses Adobe PDF Library 7.0 converter

InDesign 6 uses Adobe PDF Library 9.0 converter

Illustrator 14 uses Adobe PDF Library 9.0 converter

Can it be, that Adobe PDF Library 9.0 does not fully support Reader 7 and 8?

Checking the customer-supplied adverts in Reader 7, 8 and 9 before placing in InDesign:

There are True Type and Post Script fonts "(Embedded Subset)".

All Ads appear correctly with "use system fonts" respectively checked and unchecked.

I never had these troubles i InDesign CS2.

My system: Mac OS X 10.4.11

Please try it out: a customer-supplied advert is attached.

Birgitte

Report · May 24, 2009

Can you also post one of the PDFs that has the missing text? It shold use this same ad, or post the PDF that you use to make the bad file.

Peter

Report · May 24, 2009

Find attached the Ad as a PDF produced from InDesign 6.

Viewed in Reader 7 the text i invisible. Viewed in Reader 8 most of the text is invisible.

Birgitte

Report · May 24, 2009

I suspect a font problem of some sort. All of the affected type seems to be the MHCDinLight, and when you look at the file properties that's the only one that say it has custom encoding, even in the original.

I'm afraid I don't know exactly what that means, or why it would behave differently in different versions.

Peter

Report · May 24, 2009

Thanks for your answer.

I have now visited more forums on the web. It seems to be a huge problem for printing houses too. I see, that long time ago the InDesign development Group and members of the Adobe Team were informed about this issue and similar font issues in PDFs.

If you want to know more, go to

http://printplanet.com/forums/adobe/17931-has-font-encoding-cs4-been-discussed

And now we just wait for an update solving the problem.

But until then – ADOBE! – please mention the problem in New features > Export to PDF. If the information had been there, I didn’t need to spend days for searching and reading.

My personal solution: I will produce my PDF-files for the web using the Print menu, in that way I avoid the Adobe Library 9.0 converter which seems to be a part of the problem.

For High end printing, my printing House told me they know the issue and will take special care of the Ads in my magazines.

Birgitte

Report · May 25, 2009

Thanks, Birgitte. I wasn't aware of this issue. I'll add a comment to the Export PDF topic with a link to this thread.

Report · May 29, 2009

Brigette,

The files you provided me display correctly in Acrobat 8.x when exported from a build of InDesign that has the fix we hope to deliver soon. See the attached screenshot.

Report · Jun 02, 2009

Hello Matthew

Thank you for your serious work with this problem.

I look forward to the update.

Birgitte

Report · Jun 24, 2009

Does anyone know if this was fixed in 6.0.3?

I've updated and the few PDFs I've exported seem OK, but official confirmation would be reassuring.

Thanks

Report · Jun 24, 2009

It didn't seem to be explicitly mentioned in the 6.0.3 notes posted.

http://www.adobe.com/support/documentation/en/indesign_incopy/cs4/Adobe_InDesign _CS4_6_0_3_Update_R...

Mike Witherell

Report · Jun 24, 2009

No, it was not fixed in 6.0.3. A fix is under development and planned for yet another upcoming patch, hopefully very soon!

- Dov

- Dov Isaacs, former Adobe Principal Scientist (April 30, 1990 - May 30, 2021)

Report · May 27, 2009

Birgitte - The InDesign team is now aware of this bug and it's scheduled to be fixed in one of the upcoming updates. You can read about workarounds in this tech note:

http://kb2.adobe.com/cps/493/cpsid_49333.html

Report · May 27, 2009

Bob,

The tech note only mentions pdfs created in earlier versions exibiting this problem.

I have a pdf produced in CS4 exported with the PDFX-4 settings which when subsequently placed in an InDesign document produces the same bad pdfs unless the subsequent pdf is also exported using the PDFX-4 standard. This makes interactive PDFs impossible to produce correctly.

Let me know if the team could use the source fonts and documents...

Harbs

Report · May 27, 2009

I authored the technote, so let me elaborate. The fundamental issue is that Products based on PDF Library 8.x and earlier contain a problem which prevent them from reliably rendering text from symbol font dictionaries that use glyph name-based encoding, but don't contain the names of every glyph that the font originally conained. Note that, in addition to Acrobat and Reader, many RIPs that accept PDFs use PDF Library 8.x or earlier.

A change in InDesign's PDF generation in CS4, made it more likely to produce this scenario. So far, the only proven scenarios we have stem from placed PDF content that contains this type of font dictionary already. However,our PDF/X-4 implementation is such that we will always include all of the glyph names (assuming we have access to the original font, so we can). Hence, performing a final export from InDesign with the PDF/X-4 standard enabled, produces a PDF which doesn't show the incorrect behavior in the Acrobat applications.

You might have other scenarios in which you're seeing this problem. I'd certainly like to have access to those files so that we can test it in a build with the problem resolved. We are hoping to have a fix available to the public as soon as possible, but it's very important to us that we carefully test the solution to ensure it doesn't introduce something worse, or more wide-spread.

Please send any sample files directly to me, or email me an FTP location, or send me a note and I can give you our FTP location to post to.

Sincerely,

Matthew Laun

mlaun@adobe.com

Report · May 27, 2009

Hi Matthew,

The files are on their way...

Harbs

Report · May 29, 2009

Harbs,

Your file produced expected results in Acrobat 8.x when exported from a build of InDesign that contains the fix we are hoping to provide soon. See the results in the attached screenshot.

Report · May 31, 2009

Hi Matthew,

Excellent!

Anxiously waiting for the update!

Harbs

Report · May 29, 2009

"The fundamental issue is that Products based on PDF Library 8.x and earlier contain a problem which prevent them from reliably rendering text from symbol font dictionaries that use glyph name-based encoding, but don't contain the names of every glyph that the font originally conained."

I've gotten responses like this from different folks at Adobe. Now I admit, "That," to quote one great American, "my propeller doesn't spin all that fast," but I don't understand how there could've been a problem with software that did not create files that exhibited the offending behavior. The problem occurs now when exporting from CS4. Acrobat, and Reader, 9 do not reliably display the issue. How is that a flaw in the previous software?

Yes, birgitte, this is quite an issue for printers.

Report · May 29, 2009

@richapollo

This isn't unusual in software development; software contains a defect, but there's never any user impact, then some other software makes a change, and now the previously hidden defect has an impact. The PDFs being produced by ID CS4 are valid PDFs. However, it's going to be easier for us to change the way ID CS4 produces PDFs, than to try to change all of the older versions of Acrobat, Reader, PDFLib based RIPs, etc. I'm not sure that most users care which application is at "fault", just so long as the problem is resolved, and that's what we intend to do. In the meantime, I'm hoping that exporting with PDF/X-4 standard, then converting that PDF via Acrobat to meet the needs of your workflow, will allow jobs to get completed. I know this isn't any help for users trying to produce interactive PDFs, but it would be good to know if ithe workaround is proving useful for print production users.

Report · Jul 28, 2009

These 'work-arounds' are bodges for small jobs. In journal publishing, neither will work. X4 PDFs do not flatten the transparency in a document, a sure fire way of getting a mess off the press. If my press-ready PDFs are not Acrobat 4 / PDF 1.3 compatible then most printers will not touch them (understandably).

Any addition to the workflow involving converting advertisers' PDFs to EPS or TIF format before placing and exporting to PDF via InDesign CS4 is a non-starter - the last thing I or any other designer needs is more deeply tedious, time-consuming repetitive tasks. And when the ads number in the hundreds... Yes, I've tried automating the process in P-shop but it seems not to like rasterising and converting to EPS in an automated workflow.

Likewise, mucking about running PDFs from InD CS4 through Distiller is a tragic piece of reverse engineering. It's like having to carry jump leads with you everytime you take a drive because the battery in your new car won't hold a charge.

For me, as a freelance graphic designer, the only really practical fix is to stay with CS3 - and then I get to keep the style-mapping feature too. I'm glad I ran a demo of CS4 and did not just buy it on trust, like one of my big publishing clients did. They are now suffering with a serious case of InDigestion.

Report · Jul 28, 2009

I fully agree. It's ridiculous that CS4 still can't produce reliable PDFs after three updates.

We've upgraded, but still have to use CS3 for most jobs as the PDF workarounds are not practical.

CS4 has some nice features, but it won't take off until the basics are working properly.

Report · Aug 03, 2009

All,

Help is definitely on the way. The fix for this involves two components, both of which have great complexity, so it has required some significant code review and testing before we have confidence to release it. We had a tough decision with 6.0.3, in which we had some fixes we wanted to get out quickly, but feared rushing the work on this critical issue could result in additional defects.

I've been working on the data merge issue too, and it is also likely to bear fruit soon.

Hang in there, and look for more news soon.

Matthew

Report · Aug 03, 2009

@baggi-t,

The PDF/X-4 workaround is only suggested in conjunction with subsequently using Acrobat to convert the resulting file to PDF/X-1a, or other standard required by your press operator.

Matt

Report · Aug 04, 2009

Matt, take a look at your employer's own posting at http://kb2.adobe.com/cps/493/cpsid_49333.html

The X4 format is offered as 'solution' number one. The return to the good / bad ol' days Distiller route is offered as 'solution' number 2. You'll guess that my use of quote marks here implies I consider neither of these suggestions to be a 'solution' in terms of my understanding or the word's definition.

For me, the nearest I have got to a solution is a workflow which at the very least, costs me no more time or money with CS4 than it did in CS3. Personally, CS4 has proved a downgrade rather then an upgrade, so I'm staying with CS3. Embarassingly, though, I have advised and managed the upgrade to CS4 from CS1 for one of my biggest clients and now find myself having to fix the broken workflow that InDesign CS4 has brought to the party.

I have found this solution: speak to your printer and / or to your repro house - anyone in your PDF workflow. Your printer will use PDF editing software as part of the RIP process and you may find that the studio supplying you with advertisers' PDFs will have the same software. I've found my printers and and studio both use One Vision's Speedflow Check - http://www.onevision.com/speedflowcheck.html?&L=%3E%3Coption%3EChooselanguage%3C%2Foption%3E%3Coptionvalue%2Fcontact.html

This piece of software can fix the broken PDFs coming out of CS4 without any need for graphic designers to revisit the PDF-generation, and my printers are doing it for me at no charge. Out-sourcing the Adobe clean-up operation is certainly the best route for me while I'm waiting for Adobe to fix its failings.

I have to say I think the bugs in InDesign CS4 make a travesty of the supposed CS4 upgrade. It strikes me that Adobe has invested too much of its resources in cocktail party tricks like page-flipping swf animations at the expense of the real-word function of its products. Type-setting and press-ready artwork generation might not be the sexiest of software procedures but they are the absolute backbone of everything I do with InDesign and its siblings, and I'm certain my money is safe if I bet that the vast majority of InDesign's users are working in print production. Even with this PDF bug fixed, InDesign CS4 will still be missing the style-mapping function. It came in CS2 and since then has become an integral and massive time-saving part of my workflow. Without it, CS4 is about as much use to me as M!cros*ft Publ!sh*r .