Memory leak or font problem in Acrobat 9

[rich apollo]

There is - check the validity of the fonts! Check that all glyphs are present, that the widths match, that the font data matches the appropriate standards, etc. All of these tests fail on the sample you provided AND they are all tests that are now part of the latest (v4) profiles from the GWG!

That's not quite correct. The type in question is flagged for not overprinting. There is another font that is flagged for widths, but that font doesn't create an issue. What are "the appropriate standards," Leonard?

Acrobat 9 fixed a bug in Acrobat 8's implementation of the PDF standard that caused the change in rendering your broken PDFs. So it's Acrobat 8 that is actually wrong, not 9.

Acrobat 9 is displaying the file differently than it comes out of an APPE enabled RIP. To get the file to output as Acrobat 9 displays it, I have to outline the fonts. If I input the original PDF (created by PrimoPDF) into my RIP, it goes through intact. The errors come up when CS4 gets involved. Acrobat 9 [highlight]IS[/highlight] in error.

Why is ID CS3 doing a different job than CS4 - that one I can't answer.

I really wish you could. Currently, it looks like I'll have to pull CS4 out of production - at least InDesign and Acrobat.

 

[Werby]

While we're on the subject of preflighting... I can't find any of the preflighting tools Rich and Leonard are talking about in Acrobat 9. Where is the preflight profile for "font validation" or "Font inventory"? Validity of the fonts? I just ran every preflight profile that comes with Acrobat 9 Pro on Rich's supplied page and I didn't get anything about glyphs or widths matching or standards compliance. What are you guys talking about? How do I check the validity of the fonts?

 

[marvin]

so are we concluding that the adobe products are "correct" and working the way they are supposed to? i still don't understand how a quark pdf which exported to pdf correctly in cs3, views correctly and rips fine has now been "fixed" to view and rip incorrectly, and that we simply either have to change our workflow or add more to our preflight checks to catchup with the software.

we are not looking for workarounds since that is after the fact. we try and run an as much as we can an automated pdf workflow that receives pdf files originating from a wide range of skill levels. we do not expect our mom and pops to export to pdf/x or for designers to stop using quark. since it works for us in cs3, it is hard to justify the costs of upgrading to cs4 and the production boxes along with it.

i am not trying to place any blame or point any fingers. i am just voicing why we are not upgrading right now, when we otherwise would have. maybe a prinergy update will fix this for us later once they have a cs4 supported update.

 

[rich apollo]

Okay, so try this. Open the PDF I posted in Preview, save as, and then open in Acrobat 8. The problem disappears.

 

[Lukas Engqvist]

If I understand correct current versions of APPE are APPEv1, which is in effect same as Acrobat8. APPEv2 wich has same rendering as Acrobat9 is not yet available in currently released RIPs, corect me if I'm wrong. It means that what was fixed in first APPE we won't have till ApogeeX5, and sorry I don't know what versions of other vendors.

 

[rich apollo]

Still no answers on this one. Just posting to keep it alive. I've sent several files off to a member of the Adobe team, but no insights yet.

 

[Werby]

I'm with Rich - let's keep this thread going. How do I check the validity of fonts in a PDF using Acrobat Professional 9.0? I cannot find such a preflight function.

 

[almaink]

You need to edit the font the profile to show what you want to know about the fonts used as shown in these screen shots. I have my profile set for info but there are others in the flyouts.

 

[marvin]

So are any of these font settings the one I should play with to either pass or fail each of these files attached?

After a quick check, I get the same results in Acrobat 8.1. Anyone else see differently?

And when I do learn of the check, I will need to transfer this profile to pdfInpektor to create reports and redirect the files to specific people to make edits.

The only difference between these files is that the "Pass" was is the "Fail" file re-exported in ID3. Failing a ton of files that have no issues would slow us down drastically.

 

[leonardr]

The text of the file doesn't match what's actually in the document - so I am a bit confused about these files...

In Fail - all fonts are labelled as Type 1/ANSI encoding. In Pass - they are labelled as Type 1 (CID)/Identity-H.

So you've got a situation which is first and foremost the INVERSE of the most press folks who like to complain about CID fonts (w/o good reason, I might add!).

Second, even though you CLAIM that some of these fonts are TrueType, they clearly are NOT = since InDesign won't convert a TTF->Type 1 font.

While I didn't do a full validation, I don't find anything necessary wrong with the "fail" file. It renders and prints perfectly fine with Acrobat 9 on both my Mac and PC to both an Adobe Postscript-based printer and a clone printer.

 

[marvin]

thanks for the reply and interesting catch. i couldn't exactly figure out what happened as the person who supplied those files is out today, but i can assume what happened after a few tests.

what we were testing were different exports from indesign cs4. the artist originally created an illustrator test. the fonts are correct in this file (the fonts are actually what they say they are!).

they then either dropped this file into or totally recreated this from scratch in quark. either way, the fonts are all type one this way. we just noticed this. is there an option we don't have configured correctly to allow this to happen? anyways, both these files ripped correctly in prinergy.

anyways, this quark pdf file was then dropped into indesign cs4 as this was the main issue we needed to test. this produces the "fail" file above.

i know we shouldn't continually nest files like this, but that is currently how our workflow works. a client may submit a quark pdf. sometimes we need to make quick adjustments (add a keyline / flatten transparency) and our people are more comfortable to work in ID. they are used to doing these things in ID CS3.

the "pass" file is simply dropping the "fail" file into ID CS3. it converted those fonts to CID. this particular file rips fine in prinergy now.

we have not upgraded to the new APPE rip in Prinergy, so we are still using CPSI. we are currently working with Kodak to test these files in the new version to see if the issues are still happening. if not we are definitely looking to upgrade, but we have just held off since we would need to upgrade each server (costly).

so to summarize, we tried to build out these similar pdf's in different scenarios and the only one really giving us problems is quark to ID CS4. ID CS3 works fine in the same situation.

please let me know if there are any specific settings in cs4 that we are overlooking. thanks.

EDIT: seems that they may rip correctly as of latest prinergy update. i'll have to take their word for it until i run further tests

 

[Shawn]

Hi Marvin

I just checked the files you and Rich uploaded and they rip fine on Prinergy 4.1.2.3 for us.

Shawn

 

[marvin]

Hi Marvin

I just checked the files you and Rich uploaded and they rip fine on Prinergy 4.1.2.3 for us.

Shawn

Thanks for checking Shawn.

Updating/upgrading Prinergy will be a top priority for us then.

 

[rbailleu]

I hope heidelberg comes out with a fix. I can send files to a new fiery or a clone ps canon copier and it works. drop a pdf from almost anywhere but cs4 and the pdf wont image on meta correctly. at first I thought it was quark pdfs, but I see its most other pdfs as well. bad PR for adobe. does distilling ps out of cs4 help anyone.

 

[rich apollo]

I hope heidelberg comes out with a fix. I can send files to a new fiery or a clone ps canon copier and it works. drop a pdf from almost anywhere but cs4 and the pdf wont image on meta correctly. at first I thought it was quark pdfs, but I see its most other pdfs as well. bad PR for adobe. does distilling ps out of cs4 help anyone.

In my testing, Distilling still works fine.

 

[Vee]

Print to .ps and distill is still the ultimate safety net!

Printing a .ps file and distilling produced 98% of all our jobs running through Meta with no problems. The only time we performed a direct export was if a transparency had to be trapped. If not, ps and distill was perfectly capable of producing a flawless, trouble free print job.

 

[leonardr]

I HIGHLY recommend that you read the Ghent Workgroup's document about Refrying (<http://gwg.org/download.php?f=f121c163fa679f86977235da32290812>) and the problems with doing so and the industry recommendations for alternatives.