Memory leak or font problem in Acrobat 9

[Lukas Engqvist]

Can't call it just a customer issue, it seems to consistently happen when processing PDF's that are not fully compatible. The glitches seem to be in either the software or alternative PDF creators, such as JAWS or even exporting with Adobe PDFwriter from Office (I do hope they will fix it in future, but the risk of a non Adobe PDF maker seems to me to be too high, so the competition will have to get their act together if they want to play the game). We must pressure the software creators to fix there buggs and glitches. Some will listen some won't, so we will allways need to know the work arounds, and isn't that the whole point of forums like this?

 

[disbellj]

My testing, results, and opinions

My testing, results, and opinions

This PDF Rich attached says it was made by InDesign CS4. I do not have CS4, so my testing reveals what those that don't have CS4 would experience with this PDF. I don't have Pitstop, since I have done fine without it up until now, and will continue to try and not use it, since it has way more options that I need mostly, and if I did work with PDFs a lot (which I don't because of these types of problems, so I still ask for native files and will continue to do so until these problems get worked out with PDF and PDF workflow is actually better than a PostScript, ROOM workflow that I have now), then I would be moving straight to PDF/X-4 and a (Real) PDF-editor (NOT Acrobat, even Professional, but probably Neo).

When preflighted in Adobe Acrobat Professional 8, the fonts show as embedded subset. Arial shows as CID. But no problems are shown, since all are embedded subset, the assumption would be that everything is OK.
When preflighted in Adobe InDesign CS2, the fonts show no problem. Again, the assumption would be that everything is OK.
When preflighted in Adobe InDesign CS3, the fonts show no problem. Again, the assumption would be that everything is OK.

Note that at no time does the PDF look correct, either when opened in Acrobat Professional 8, or placed into Illustrator CS3 (which the flattening transparencies didn't work for me), or placing in InDesign CS2 or CS3.

Output all proved a waste of time. I couldn't export as PS and distill, EPS (level 2 or level 3) and distill, or export as PDF/X-1a:2001 without Distiller giving a .log that everything was OK, but it wasn't, which was apparent when the resulting PDF was opened in Acrobat Professional 8. Note: when exported as PDF from InDesign CS3, all resulting fonts were CID (shows a re-encoding did occur IMHO, since the PDF that Rich uploaded only has Arial as CID font).

As a last-ditch effort in my ancient workflow (Nexus 7.5), I dropped the PDF on a hotfolder, and it failed at the rip because transparency is not supported in that version of Nexus (although I must run that version of Nexus to print to my older Sherpa2 printer, so I'm stuck in-between a rock and a hard place for the time being, which is out of my control). Even if it would have worked, I don't think that version supported CID fonts.

So I have tried literally everything I can think of, and I could not output this PDF to look correct.

OK. I even have to try one last thing: Start up the newer Nexus (newest that I have since our service contract expired), Nexus 8.3 Rev 4, and the PDF ripped fine no problem, was seen as black plate only (correctly), and there was no problem in the raster workflow. Artpro (the newer companion to go with the newer Nexus version) also had no problem with the PDF file, although fonts were outlined so that no type changes using the customer's specific embedded version of a font could be used for any future possibly required type changes. But if I actually did this on a real production file, because of licensing restrictions, and because of rip manufacturer non-support (even though support was paid for for years and they never fixed the problem), I couldn't actually proof the file. Neat huh?

See Leonard, this is what Rich and people like myself have been trying to get across for years. We don't get to choose how the PDFs are made before they get to us. And we may have older software that we must use (not in our control), or we may have to use the old software because of a dependency to older hardware we have, that using the upgraded version breaks that dependency (again, not in our control necessarily). That's why we appreciate that up until now Adobe has allowed us to "dumb-down" the PDFs if need-be, to get the jobs out. PDF/X-1a has been a sort of cure for many ailments. It's not a solution in this situation.

Although I can't see any print-related reason to upgrade to Adobe CS4 or Quark 8, it's these types of problems that is entailed in this post that make these basically forced upgrades IMHO. If I didn't have Nexus 8.3 Rev 4 or Artpro 8.3, or NexusEdit 8.3, or above, but only had access to Nexus 7.5 Rev 10 and Artpro 7.5, then I couldn't get the job out. Now I know that the company I work for needs to spend some money on upgrades, but we haven't had much co-operation from those that are supposedly helping us (and no I don't want any other vendor offers).

So really the questions are:
Why does Adobe show no problems during preflight of this PDF in non-CS4 programs, even though there are apparent visual problems in any non-CS4 program?
Why is this not an Adobe problem?
Shouldn't Adobe, like us, have to deal with these problems and provide fixes, so that each and every customer doesn't have to?
What got changed/broken in CS4 that makes this PDF incompatible with CS3 or CS2, to where it can't be output correctly except using a newer rip or PDF editor (not even PDF/X-1a works)?
What if I have no access to anything but CS3? I would be screwed in this instance, correct?
If embedded fonts aren't working, then why should I assume that getting loose fonts will work? Why shouldn't I be able to use embedded fonts and it be reliable?
What if I did have a PDF editor that couldn't handle this (like Acrobat can't without help from PitStop)?

I see these as valid questions. I know there are times when we must upgrade, but I can say that when I don't see any reason to upgrade from a print stand-point (what I do), then unless I had an all-PDF workflow or PitStop, I would essentially be forced to upgrade my Adobe apps because of new problems that didn't exist before.

Please look into this and see if Adobe will fix CS2 and/or CS3 to be able to output files such as this. If not, then it looks like I'll have to gear towards an all-PDF workflow, and quit upgrading my Adobe apps (and would look to quit upgrading my Quark app too). That is, unless I would have to keep upgrading my Adobe and Quark apps anyways, because of upgrades breaking my all-PDF workflow (which I wouldn't doubt, but would become apparent to users, and be discussed with bosses, when all-PDF workflows that shouldn't keep breaking through upgrades become broken with each new upgrade).

Must say that I also tried printing from InDesign CS3 to Nexus 8.3 (where the PDF dropped onto it worked before), and printing the placed PDF from InDesign CS3 to Nexus 8.3 did NOT work. So InDesign looks to be a culprit (although I really would say that anything that's not CS4 and has to have this PDF placed for output would not work, so the problem ultimately is created with CS4-created files).

Thank you,

Don

 

[marvin]

we also have been dealing with this issue the last few weeks since we last upgraded a few boxes to cs4. this is a cs4 indesign issue! we seem to have it narrowed down to quark pdf's placed in indesign cs4.

we've had varying font issues ranging from boxes, to garbage, to simply dropping out. we have had to reprint a couple jobs already as it had been missed the first few times. we have not found a way to preflight for this issue other than having the prepress operator flag that it is a cs4 file so that the prinergy page assemblers can double check the work. if an error was found, then we would convert the text to outlines, as it seems to be a stable fix. it is still inexcusable to have to implement this kind of workflow to catch this. this is a huge issue which is preventing us from upgrading the remaining boxes.

attached is a simple file we created as a test, and the results which is a screen cap of a prinergy vps.

this did not happen in cs3!!!

we run a pdf workflow, so i have more examples if requested.

 

[leonardr]

Leonard, I can't control how the PDFs are made. I have to be able to work with what the client passes on.

Understood. So you need to institute quality checks on your side and then standard processes for correction of failing files.

What would I be looking for in the preflight? The fonts are in the original PDFs, albeit in subset form.

As I mentioned, Acrobat 9 Preflight and the latest version of PitStop (8.x) have various checks for font validity - checking matching widths, missing glyphs, compliance with the various standards, etc. USE THEM - that's why they are there!

Nobody has answered the original question - why does Acrobat 9 handle this differently than Acrobat 8?

I haven't compared the file between the versions, but I suspect that answer is that Acrobat 9 isn't letting the bad font data through like it used to. Another area where we've tightened things up according to spec.

 

[leonardr]

So really the questions are:
Why does Adobe show no problems during preflight of this PDF in non-CS4 programs, even though there are apparent visual problems in any non-CS4 program?
Why is this not an Adobe problem?
Shouldn't Adobe, like us, have to deal with these problems and provide fixes, so that each and every customer doesn't have to?
What got changed/broken in CS4 that makes this PDF incompatible with CS3 or CS2, to where it can't be output correctly except using a newer rip or PDF editor (not even PDF/X-1a works)?
What if I have no access to anything but CS3? I would be screwed in this instance, correct?
If embedded fonts aren't working, then why should I assume that getting loose fonts will work? Why shouldn't I be able to use embedded fonts and it be reliable?
What if I did have a PDF editor that couldn't handle this (like Acrobat can't without help from PitStop)?

Don (and everyone) - if you look at various online forums, industry conferences and just talk to customers, there is no question that the number one problem with "problem PDFs" is with fonts. It is for this reason that groups such as the Ghent PDF Workgroup have been adding font-related checks and validations to their latest specifications and vendors (like Adobe, Enfocus, etc.) have been therefore improving our products to address these changes.

But it's clearly a "Catch-22" as Rich's file demonstrates...On one hand, you have the "the file isn't valid/compliant" and on the other hand you have the "but it views and RIPs fine with my tools". Which is more important? Same argument that we have to apply to each "bug file" that comes across our desks at Adobe - if we change the product to render that PDF as expected by the customer it will violate the rules of the PDF Standard (now ISO 32000). Who wins?

PDF is an open international standard that is implemented by thousands of vendors using hundreds of different "PDF Libraries" each with their own idiosyncrasies and/or bugs in implementing this very complex standard. Folks don't always get it right - Adobe included sometimes. (eg. anyone remember Acrobat 4?)

We (the software industry) are trying to improve the tools while stabilizing the technology. But if you (or anyone) chooses not to invest in the better tools - there isn't anything we can do .

 

[rich apollo]

As I mentioned, Acrobat 9 Preflight and the latest version of PitStop (8.x) have various checks for font validity - checking matching widths, missing glyphs, compliance with the various standards, etc. USE THEM - that's why they are there!

I'm at a loss as to what to look for.

The questionable fonts get flagged for not overprinting. Some other fonts, which output correctly, get flagged for "Glyph width info in PDF matches width info in embedded font". There are some flagged as "composite fonts" - these also output correctly.

 

[Lukas Engqvist]

If you want to be resiliant to change the only software you will need is the latest version of Acrobat Standard as you can export to PS and move from there. If in a bad crunch even export to TIFF

 

[Vee]

What a royal PITA PDF is becoming....... who'd a thunk it!?

 

[almaink]

So if I get this correctly, Adobe has decided to take PDF's that used to rip just fine and flag them as no good now? LOL this makes no sense at all IMO. No wonder CS4 isn't selling with those type "improvements".
I'm still waiting on an answer as to why Adobe decided to strip OPI comments in used PDF fpo's, from PDF's exported from InDesign CS3. Still broke in CS4 as well. No problem in CS or CS2.

 

[leonardr]

So if I get this correctly, Adobe has decided to take PDF's that used to rip just fine and flag them as no good now? LOL this makes no sense at all IMO.

Consider that PDF has been an open specification for 15 years (and is now an ISO standard). In those 15 years MANY MANY people have written PDF creation software - and MANY of them have gotten it wrong .

YET, people expect Adobe Acrobat/Reader to render EVERY PDF file - no matter how flawed - "correctly".

So we are faced, from time to time (when an issue is discovered), of having to choose between compliance with the standard VERSUS rendering bogus/broken/invalid PDF documents.

And there is no right answer - and we don't always vote the same way...it's ALWAYS taken on a case by case basis where we look everything from the technical details to the market considerations (eg. is this a common error by a popular tool, or just a "one off").

I'm still waiting on an answer as to why Adobe decided to strip OPI comments in used PDF fpo's, from PDF's exported from InDesign CS3. Still broke in CS4 as well. No problem in CS or CS2.

I can't specifically comment on why ID made such a change, but I can comment on OPI and PDF. OPI is an ANCIENT technology (came out of Aldus, before the merger/acquisition) and is NOT SUITABLE for use in modern PDF workflows as it isn't compatible with features such as transparency, layers/optional content, etc.

instead, PDF has a similar technology (that has been part of the language since PDF 1.3) called "Reference XObjects" and it is what the ISO standards of PDF/X-2 and PDF/X-5 are based on. In addition, the forthcoming ISO standard of PDF/VT (Variable and Transactional) is also based on it. THIS is where you want to be investing your time/resources and NOT the past.

OPI is dead. Let is Rest In Piece...(but not RIP .

 

[pcmodem]

But it's clearly a "Catch-22" as Rich's file demonstrates...On one hand, you have the "the file isn't valid/compliant" and on the other hand you have the "but it views and RIPs fine with my tools". Which is more important? Same argument that we have to apply to each "bug file" that comes across our desks at Adobe - if we change the product to render that PDF as expected by the customer it will violate the rules of the PDF Standard (now ISO 32000). Who wins?

If Adobe/Acrobat knows the PDF doen't meet ISO 32000 standards when viewing. Why not have a message come up stating it doesn't and the reasons why. Perhaps then, people might not be as upset with Adobe. You could even have a check box to not show again. If Adobe changes the way something is done, they need to make sure people are warned about it in the software, not in a user forum, help system, manual, or release notes. Every day people use software without reading the prementioned places. They expect the software to work the same way it did before but with improvements and added features. If there are improvements that might effect how someone works, it should be flagged. As a software company, Adobe needs to stand out from the rest and prove themselves to be top notched and remember to keep striving for it even if you are at the top. Making poor decisions can be fatal.

Adobe has positioned PDF as a standard. Within newer versions of Acobat, there should be a compliance box. Showing if the opened PDF meets standard, just like Pitstop does with a certified PDF. Adobe should not rely on vendors to do this. It should be control from within.

 

[michaelejahn]

PrimoPDF - LOL - not so "primo" is it !

-- another PDF making clone, another developer that wants to provide a free tool that cuts corners, makes compromises, claims huge installs at fortune 1000 companies - and all that is great when you are creating Microsoft application documents and want to make a PDF files of them and not pay for anything from Adobe. Horray for free, and you get what you pay for apparently !

Toss that crappy PDF constructed using dicey PDF code into the high end prepress world, and suddenly this house of cards collapses.

We have been complaining about non-adobe gadgets for decades !

Quark made bad PostScript, and all RIP manufactures had to pre-process that before sending it to our Adobe licenced gear - not everything we needed to combat this bad postscript was in the Adobe SDK.

AGFA was hardly alone in preprocessing - Scitex, Harlequin - everyone had a PDL for pre-translation, before we could apply the rendering and rasterizing. When we went to PDF workflows, suddenly Adobe was exposed to this bad PostScript, and Adobe have been doing all they can to enable Distiller to gracefully convert a big mess to a relaiable PDF.

This also is a problem for Adobe and any other developer that wants to import / place a PDF, as it needs to parce it - never mind trying to even simply pass a bad PDF through to a VDP system or impose / paginate them...

Many developers are deluded into thinking "hey, no biggie!" - they think it is no big deal and they create fragile PDF files that often display in Apple Preview or Foxit, because they simply leap over and ignore much of the crappy constructs.

Okay, so that is my rant.

Hey Rich - don't think I am not feeling your pain my brother !

You can't control what walks in your door - but perhaps (with some not so gentle invoice related persuasion) You can get them to listen to a PDF/X 'life would be better" story ?

- nthing like an addition charge on that customer file for fixng (perhaps re-doing) the job. Of course, if they pay up and give you crap, you gotta love that !

-- I love ignorant customers with a budget !

- or, if they don't explain that they need to prove the files they give me are reliable before they send them to me.

As we all have discovered - Just because a PDF file can display in Acrobat Reader does not mean it is ready for prepress - clearly, this PDF file is crap, and you have discover that - clear as day. They want reliable production, tell them to toss that crap and buy some Adobe kit.

It took many many years for Enfocus to finally make an Adobe less PDF application ..

(Enfocus introduces PitStop Extreme

- this is NOT that simple !

 

[leonardr]

If Adobe/Acrobat knows the PDF doen't meet ISO 32000 standards when viewing. Why not have a message come up stating it doesn't and the reasons why. Perhaps then, people might not be as upset with Adobe.

Do we bring it up once on the entire file? And if so, should we slow down the opening of the file until we check the entire file for all issues? _OR_ should we "check as we go", and then bring up one error message per problem that we encounter as we encounter them?

and then should these be warnings ("you might have a problem, but I'll try to continue") or real errors ("sorry, this file is bad and can't be viewed"), or both?

And while someone on this forum, whose paid for Adobe Acrobat and uses it for their livelihood, might be OK with getting such a message - what does the average user of Adobe Reader (who probably had it pre-installed on their computer) think?

And what about when users start posting (as they already do) - "but it views fine in Joe's Reader..."

[I pose these questions here to give you some small inkling of the issues that WE FACE around this problem and that we have discussed MANY MANY times over the years...]

Adobe has positioned PDF as a standard. Within newer versions of Acobat, there should be a compliance box. Showing if the opened PDF meets standard, just like Pitstop does with a certified PDF. Adobe should not rely on vendors to do this. It should be control from within.

You haven't tried Acrobat/Reader 9, have you?? See <http://www.acrobatusers.com/blogs/leonardr/2008/06/02/acrobat-9-knows-standards/>

 

[Vee]

Why not make it a preference to display such warnings just as you have identified them above in your post. Then if a user needs this vital information it is available, if not, turn off the warnings.
What about a specific Acrobat version for professional printing / prepress?! I think we've been asking for that for years now.

 

[rich apollo]

Primo PDF didn't create the problem. This problem cropped up when I created a new PDF out of InDesign CS4.

I don't think that there's any preflight that would highlight the problem.

If I can process these files, I make money. If I can't process these files, I don't make money. I'm not gonna' sell designer X desktop software any more than I'm gonna' sell any of you a car.

I've heard over and over "don't print - save directly to PDF". Well that ain't cuttin' it. Pointing the finger at somebody else's workflow ain't cuttin' it. And the stinkin' ISO ain't paying me 10¢ for donuts!

So, once and for all, why does the file display differently in Acrobat 8 than in Acrobat 9? Where the hell is Acrobat 9 pulling these fonts from?! Why does the file export out of CS3 correctly? And why is InDesign CS4 having problems exporting PDFs?!

 

[pcmodem]

Rich,

The file doesn't display correctly in Acrobat 9 because Adobe fixed some bugs within their software. InDesign CS4 also uses the newer Acrobat 9 items so it will be the same. InDesign CS3 would use Acrobat 8 items. Since Acrobat 8 has a bug in the software by not conforming to standards, you see your PDF correctly.

When it comes down to it, Primo PDF probably did create the problem. But you didn't notice it until Adobe fixed a bug in their software. This is like having a crack in your dry wall that you don't notice until you get new glasses. The crack was always there but you didn't see it because your eye glass prescription wasn't correct.

 

[pcmodem]

You haven't tried Acrobat/Reader 9, have you?? See <http://www.acrobatusers.com/blogs/leonardr/2008/06/02/acrobat-9-knows-standards/>

I have not spent that much time in Acrobat 9 to notice this. Now that I see this new feature. I have a different train of thought, which takes both of my ideas from before and the new feature and merges them together. Always show the Standards Panel, but when the file doesn't have a standard assigned to it. Put a Red circle with a slash through it, like the no smoking sign. The information is already there, or not. Just need to display it on screen. Perhaps even a preference to have a pop up warning "This document doesn't meet ISO standards". The preference could be off by default.

Over time I see more and more companies requesting PDF documents to meet ISO standards.

 

[leonardr]

What about a specific Acrobat version for professional printing / prepress?! I think we've been asking for that for years now.

Should it only come as part of the Creative Suite OR only available stand alone?

What would it do differently? Have more features or less?

Would you be willing to pay extra for it? If so, how much more?

If we do this, should we also do "Acrobat for Lawyers", "Acrobat for Government Workers", "Acrobat for Engineers", etc.? Where do we draw the line?

 

[leonardr]

I don't think that there's any preflight that would highlight the problem.

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!

I've heard over and over "don't print - save directly to PDF". Well that ain't cuttin' it. Pointing the finger at somebody else's workflow ain't cuttin' it. And the stinkin' ISO ain't paying me 10¢ for donuts!

10c - you're cheap . I'll be glad to send you a $1 for donuts if you'll change your workflow.

So, once and for all, why does the file display differently in Acrobat 8 than in Acrobat 9? Where the hell is Acrobat 9 pulling these fonts from?! Why does the file export out of CS3 correctly? And why is InDesign CS4 having problems exporting PDFs?!

Already answered this, I thought.

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.

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

 

[almaink]

"Why is ID CS3 doing a different job than CS4 - that one I can't answer."
Nor can anyone from what I've seen. It's the same question I asked about CS3 behaving differently than CS2 with PDF's. I have press sheet imposed PDF's that will fail to export from CS2 but go right though in CS3 and 4. So for me it's a blessing in that regard. The only issue I have is CS3 and CS4 stripping OPI comments from imposed FPO PDF's created by Rampage rip. If I use eps FPO's I have no problem, but why did Adobe change this is the answer I'm still waiting for before I dump CS2 and use CS3 or CS4 full time.