Has the Font Encoding in CS4 been discussed?

[Lukas Engqvist]

Have been wrestling with some PDF files that have characters replaced by null character in Acrobat8 and earlier, and the RIP.

When placing PDF files in CS4 and then exporting to PDF, it appears that "custom" encoded fonts are re-encoding resulting in Null characters (Crossed out square, "[X]" ) replacing other characters.
This seems to be at random.
There is ofcourse no way to know if a custom encoding is correct or incorrectly encoded, but there is an inconsistency in how Acrobat 8 (and previous) and Acrobat 9 views fonts.

Most RIPs, due to the life cycle will render as Acrobat 8. Problematic PDFs can be exported to Postscript to generate printable results. But a Bug fix, or a backward compatibility patch is in order.

Exporting an erronous PDF as PDFX, or runniing preflight does not fix these issues. (reminds me a little of the Legacy Text issue we had in Illustrator a while back come to think of it)

What I am missing from the Acrobat is an option to re-encode fonts, especially subseted fonts.
This is what happens when we export to Postscript and redistill?

Using a joboption with PDFx4 was able to circumvent the problem… but it is impossible for us to tell how many levels of placed PDFs and what settings are used in each stage, on a PrintReady PDF.

Is this an issue Adobe is Aware of? Will there be a patch?
This is a somewhat urgent appeal to Adobe as it will greatly affect the confidence service providers have in CS4 uppgrade.

 

[thegnat]

Hi Lukas,

finally someone with the same issues we have. :/
We recently upgraded to CS4 and our customers complained about PDF files not readable on their machines.
They reported missing text and unwanted characters like you described.
So I had a look into it, because our RIP (Apogee Prepress 6) can handle these files without any problems.

We also place delivered PDF files in InDesign and then re-export them to PDF.
With some PDFs there are these squares in Acrobat Pro 7, but they aren't in Acrobat Pro 9.
Many of our customers have "outdated" Adobe Readers that display the files wrong, too.

The Fonts used in the Example are Times New Roman and Arial. Original PDF was generated by QuarkXPress, then placed in InDesign and exported.

Hopefully someone will bring up a fix for this issue...does anybody know if this issue is known to Adobe?

Robert

 

[almaink]

One of the reasons I won't use CS4 unless I have to. I have a few PDF's here that look different depending on what version of Acrobat is used. This is just ridiculous as there is no way I can tell all my customers they must buy Acrobat 9. To make it even worse those same PDF files won't even place in Indy CS3 or CS4! They will place in CS2 and CS but they don't look correct. They look the way they look in Acrobat 6 & 7. Problem for me seems to be a smooth shade tho not fonts on these. I was able to "Fix" them using both Acrobat 9 and Acrobat 7 with Pit Stop but this has got to stop. Why does Adobe always feel the need to "fix" things that are not broken? I have enough to do without this crap!

 

[Lukas Engqvist]

The important thing is to help Adobe nail the problem so that it can be fixed. "Constructive Barking" like a sheepdog, not like and annoying lap dog.

 

[almaink]

Problem is I have tried to help. I sent files I had issues with when CS3 came out, at Adobes request, and never heard back from Adobe and the problem is still there in CS4. Thing is it wasn't a problem in CS2. Hence my comment about fixing things that don't need fixing. IMO Adobe could care less about printing anymore. All I see are things for web, movies, and office, nothing new for us prepress monkey's except trying to get us all canned by adding Preflight!
Come on Adobe, and remember the people that got you where you are today!

 

[Lukas Engqvist]

Letts stick to the font issue here. And why not open another thread with the smooth fill, either you will start the ball moving or find you were at the wrong tree. Please.

thegnat, you say Apogee 6 is free from this issue? (I'm glad to hear just waiting to get upgraded) But the issue still needs to be resolved for others. What export settings did you use? Could you confirm that exporting with PDFx4 settings from InDesign means that the PDF is free from this issue? I find it strange that this is the case, was expecting PDFx1a also to wash away the problem but it doesn't.

 

[thegnat]

Lukas,

I used our own export setup, since we don't want to have ICC included for our print-PDFs.

And I tried your suggestion to export a PDF/X-4 file : it works fine with all Acrobat versions, it really seems that the text is encoded a different way from other export conditions. So I can confirm that PDF/X-4 files have no such issues.
I compared it to PDF/X-3:2003, PDF/X-1a:2001 and our export profile (PDF 1.3) where its all jacked up.

Why does the PDF/X-4 profile use another text encoding? It makes no sense to me.

Robert

 

[leonardr]

The issue has to do with transparency flattening and the potential need to "transcode" any imported files. With PDF/X-4, there are many less things we need to "transcode" when producing the output PDF - so less changes to your data. But when you use earlier versions of PDF (or earlier PDF/X flavors), changes may/will occur.

 

[thegnat]

Thanks for the input leonardr.

Why this issue wasn't present in CS2 and CS3 when flattening transparencies?
The same source-PDF placed in CS2 or CS3 and then exported as PDF 1.3 (e.g. PDF/X-1a) never resulted in such "transcoded", not readable texts elements.
As we stated above, this is giving us a really hard time with clients not able to view their print data right.

Are there any plans on fixing this issue, or is it considered a feature?

Thanks

Robert

 

[Lukas Engqvist]

OK Leonard, has Adobe made a statement about this? It is very hard for us service providers to tell customers od flaws/weaknesses in Adobe software. Will Adobe officially maka a statement, recoment to use PDF/X4 ?
Also on PDF/X-4, will there be a patch to update CS3 to export for PDF/X-4:2008? We want to make it simpler for our common customers to do things right. Best for all.

If this is a potential problem that Adobe is Aware of there is nothing in the preflight (InDesign or Acrobat) to detect or warn for potential errors due to "transcoding". Isn't that the purpose of prefligh, to forecast and warn for potential problems?
The warning should occur at export saying "You are about to export a file that will only voew correctly in Acrobat 9 and print correctly using a RIP that is hardly available even to those with upgrade plans"

Please don't get me wrong leonard, I think you are doing a great job, just want to give you the material to push for improvement.

 

[Predisposed]

There where some issues with PDFs created from CS1/2 when using PDF checking softwares, giving the dreaded xxx instead of characters, so every level of software and release has its own new problems, just as well otherwise we would be replaced by 16 year olds fresh from school for a 3rd of the money!!!... ...embrace these issues (and kick the waste paper bin around a bit). I don't have CS4 yet I consider it a rip-off at the moment as so little has changed but try this.. I know its only a work-around (they always seem to appear when softwares are updated) but have you tried saving the PDF as an eps file and then placing in CS4. Obviously No good if you have spot colours and tranparencies but it should sort the font issue out, I apologise if i'm barking up the wrong tree.

 

[thegnat]

We are processing hundreds of files per day, 50% contain spot colors. So recomposing / redistilling every job, just to make sure it "looks right" would be a neck break.
But clients are forcing you to do so, because they reject to upgrade their software.
Other clients, owning CS4, force you to have it too to process their files.
Whats our choice as a medium/large printshop?

The easiest solution in my opinion would be to make the behaviour like CS3 where it worked, even when flattening transparency.

Robert

 

[Lukas Engqvist]

The biggest problem is the customer made PDF files. If there is a way to catch these with a prefligt script we can implement it. What we will have to tell customers at the moment is proof your files in Acrobat 6, 7, 8 and 9 if you don't get null character errors you may consider the file printable.

I am just afraid of the job that will pull us down as the customer says "It looked fine in my Acrobat 9" and you are Adobe Athourised Service Provider... so you pay the bill? Will Adobe pay for a reprint? Doubt it, but I could be wrong.

 

[Ritter]

I've been following this thread closely and restraining myself.

To me this seems to be yet a continue of two alarming trends that seem to be repeating over and over again...

First a rant:
Software companies building backwards compatibility in for decade old files and programs. Sometimes you just have to make a clean break and start fresh. Apple did this in steps with migration to OSX then dropping virtual Classic OS support then migrating to Intel with rosetta which is already in the steps of being phased out. Microsoft doesn't seem to get it and now it is becoming more and more obvious that Adobe doesn't either.

Adobe's near complete monopolistic manhandle on the graphic arts industry both in printing and with digital media with a complete lack of transparency and oversight is very troubling. There is one central reason why RIP technology is always a step behind the Adobe PDF engine.

Now on to the more on-target thought:

The most obvious solution for Adobe to implement is to completely drop backwards compatibility with PDF/X4:2008 and make it only readable by Acrobat 9 and above. It obviously isn't truly backwards compatible anyway; why release a half-ass solution and cause a mess? As others have mentioned we can't be expected to run parallel workflows and to rework everything because of an executive decision made behind closed doors at Adobe.

 

[Lukas Engqvist]

PDF/X are ISO standards. You cannot drop backwards compatibility or we undermine the meaning of standard. Adobe have been in the groups creating the standard.
When backwards compatibility is dropped it is common practice to warn the user that the exported/saved file is no longer compatible with legacy? Photoshop manages to save fat files for maximum compatibility.
It would be OK to drop backward compatibility if the file was PDF 1.8, but a PDF 1.3 or 1.4 should be compatible with Acrobat 4 and up or Acrobat 5 and up. (but then it would not be any of the current PDF/X standards)

The whole purpose of Protable Document Format was to preserve visual integrity, this is what has made us move to PDF workflows.

P.S.
There is one problem and that is there is no way to Bugg report APPI, PDFLib or PDF, ony applications. I think it is a case of falling between Acrobat and InDesign developing teams? There must be a team connected to Core technology. I am optimistic Adobe CMM was released, wich does show that there is some kind of understanding.

 

[Predisposed]

Good thread.. Alas for pre-press, just as software becomes stable and we start to settle into a workflow that actually works, a new software release comes along!
In pre-press the problems are doubled due to (as Lukas has mentioned ) the problems when one part of the workflow is updated and this then has a knock-on effect.
One workflow - Designer uses new CS4 - PDF 1.8 Acrobat 9 un-flattened PDF - Prinergy PDF engine
At the same time you have a Designer using Quark ver 4 - Postscript/PDF 1.3 flattened - Prinergy PDF engine/(CPSI - if required). Any combination of these plus the wonderful 'Microsoft-Word' etc etc.
A change in any area can drop a spanner in the works.. it will never change unfortunately its part of Job. I do however struggle to believe that designers for the print industry need anything better than CS3 which is capable of producing great 'Un-flattened' PDF1.8 files suitable for any kind of design/print you could wish for. So far we have no designers currently using CS4 or Quark ver 8, and speaking to them on a daily basis CS3 seems to suit them fine... long may it continue!
PS. most of our clients have completely ove away from Quark (due to its inability to handle transparencies properly) have yours?

 

[Joe]

In this business it's always a good idea to keep up with the latest software and I don't think asking a customer to use the latest version of Acrobat Reader is too much to ask. It is FREE after all.

And why would you need X4 compatibility in CS3 and below? The problem only occurs out of CS4 right? And getting Adobe to update it's older suites will be more difficult than putting nylon stockings on a cat.

 

[rich apollo]

This issue was brought up long ago here in another thread. Also a thread on the Adobe forums. I've sent files off to the InDesign development group, and to members of the Acrobat team.

The question of backward compatibility doesn't address the issue. The output from my RIP appears as the files look in Acrobat 8 and earlier. I'm on ApogeeX 5, and so am up to date. Version 6 is still in beta, as far as I know, and is therefore not in widespread distribution.

Something else I found curious, open one of these problem PDFs in Preview, resave and the font display issue goes away.

 

[Lars Jacobsen]

Prepress 6 is not Beta any more. Some companies has already got the upgrade, we´re waiting for the first Hotfixes before we upgrade.

 

[leonardr]

One workflow - Designer uses new CS4 - PDF 1.8 Acrobat 9 un-flattened PDF - Prinergy PDF engine

There is NOT, nor will there EVER BE, a PDF 1.8.

Because Adobe no longer owns the PDF specification (it is now ISO 32000-1:2008), we can no longer update the version number to match the version of Acrobat as we did in the past. Instead we use the extensions mechanism as defined in ISO 32000-1:2008 to identify PDFs that have features from newer versions of Acrobat (aka >= 9.0).

As such, a PDF file containing one of the new features of Acrobat 9 - for example, Portfolios - will be identified as PDF 1.7-ADBE-3 (PDF 1.7 with Adobe Extensions Level 3).