Will Pitstop Pro 10 Find The Following

Norcrans

Well-known member
I am hoping someone can verify for me that Pitstop Pro 10 would be able to detect a problem with an embedded font in a pdf. The reason I am asking is we recently had a job that looked fine throughout our entire proofing process but when we created plates through our Prinergy system something went wrong with the letter H in the word Holidays.

The original job was created in InDesign CS4, the pdf was created by exporting out of InDesign and the pdf version was v1.4. When you open the pdf the letter H looks fine, when you refine the pdf in Prinergy the letter H looks fine and when we did a virtual proof at 600 dpi out of Prinergy the letter H looks fine and when we sent our refined pdf to our Epson proofing device the letter H looked fine. At no point did we receive any errors indicating an issue with the font.

I cannot attach the actual pdf we printed the job from but I have recreated the issue in a different file and attached it to this thread. The pdf attachment called "Type Test.pdf" is a pdf created out of InDesign using the font we had the issue with. The pdf attachment called "HiRes Output.pdf" shows what happened to the letter "H" when the plate were made.

I have never seen an issue before with fonts where everything looks fine with the files until you produce the plates. I've downloaded a trial copy of Pitstop Pro 10 and processed my test pdf through a couple of the built in profiles and it did not indicate any issues with the fonts. I'm not that familiar with Pitstop Pro though so I am hoping that someone here that's familiar with it can let me know if Pitstop Pro would be able to help me catch issues like this on future jobs.
 

Attachments

  • Type Test.pdf
    51.5 KB · Views: 216
  • HiRes Output.pdf
    45.6 KB · Views: 221
Looks like the CID encoding are wrong according to callas pdfToolbox. I used pdfToolbox to fix them, so try RIPping the one I uploaded. You'll also see in the attached report a number of incorrect parameters regarding the fonts, including Times.
 

Attachments

  • Type Test_report.pdf
    227.8 KB · Views: 230
  • Type Test_fixed_cid.pdf
    54 KB · Views: 215
Attached is a Pitstop 10 Preflight report where it flags fonts as composite fonts.

I can verify on my Prinergy 5.1.2.2 I get the same results as you. It looks fine all the way up through the screened VPS at 600 DPI but when you get up to 2400 DPI to output plates the H is hosed in places. I would submit a support request with Kodak.
 

Attachments

  • Type Test Report.pdf
    187.4 KB · Views: 240
Well, if you use PhotoShop to rasterize the PDF at 800 DPI you see the same problem as Prinergy. Even the one that I "fixed" has this problem. So there is something else going on. We'll have to play a bit more and see what we can come up with...
 
It could be Adobe bug.
I tested PDF in Heidelberg Printready workflow and got identical result.
Pitstop 9 update 3 claims everything is just fine with subset font, no flags at all, Prinect preflight goes through just fine, no flags, soft proof that renders @ 300 dpi is just fine but when it renders to 2400 dpi tiff plate, issue is there.
This is different vendor and probably the only common thing is Adobe technology that both vendors license from Adobe.

I re-tested it with CPSI, thinking it might have been APPE issue, but CPSI gives the same result.
 

Attachments

  • spsmall.jpg
    spsmall.jpg
    15.6 KB · Views: 197
  • tiffsmall.jpg
    tiffsmall.jpg
    17.5 KB · Views: 192
  • preflightsmall.jpg
    preflightsmall.jpg
    18 KB · Views: 195
Last edited:
I think I found the problem:

Segoe (pronounced /ˈsiːɡoʊ/) is a Humanist typeface family that is best-known for its usage by Microsoft. The company uses Segoe in their online and printed marketing materials, including recent logos for a number of products. Additionally, the Segoe UI family of fonts are utilized by numerous Microsoft applications, and may be installed by applications (such as Microsoft Office 2007 and Windows Live Messenger 2009) or bundled with certain operating systems (including Windows Vista and Windows 7).
The Segoe name is a registered trademark of the Microsoft Corporation, although the typeface was originally developed by Monotype. It is named after Segoe Road in Madison, Wisconsin, where one of Monotype's engineers lived.


:D
 
Looks like the CID encoding are wrong according to callas pdfToolbox. I used pdfToolbox to fix them, so try RIPping the one I uploaded. You'll also see in the attached report a number of incorrect parameters regarding the fonts, including Times.

Matt,

I took the file that you uploaded and ran through our Prinergy system and I got the same results that I did with the original file. The refined pdf looks fine but when you run it through the Prinergy VPS software at 2400 dpi or produce a plate we get the same results with the crossbar on the H at 36, 48 and 60 point.

Another way to see the results is to take the pdf and magnify the H to 2400% and you will then see how it will be produced on the plate.
 
Sorry Matt, I didn't see your second post before posting my reply before this one.

I've tried about everything I can think of to flush out the problem we are having but I have yet to find a program that gives me a warning that says their is an issue with that particular font and point size. I can find some that say their may be an issue with it but nothing that flat out makes the file fail.
 
well, it's not just Prinergy, my Xitron Sierra rip produced the same results. I saw the change on my TIF preview though, but the high-res PDF proof looked fine.
 

Attachments

  • HiRes Output_2010-Nov-16.pdf
    36.5 KB · Views: 217
  • Screen shot 2010-11-16 at 11.17.13 AM.jpg
    Screen shot 2010-11-16 at 11.17.13 AM.jpg
    12.1 KB · Views: 193
how to predict the issue at hand

how to predict the issue at hand

thats not the first of those i've seen to date but at least one that you could "fix" through converting all type to paths. not the best way to treat all your files but at least a solution for this one.

even worse was a file i've seen that changed the behaviour of a compound path depending on the resolution you rendered the file. and thats worse since its already outline!

might want to mention the fact that there are fonts out there not being able to get embedded into a pdf but at least thats possible to detect way ahead of time.

only solution to secure your workflow would be a highres proof at final output resolution. meaning you need an extremely powerful rip to handle all the downsampling again after you written out all the 2400 dpi seps. most rip manufactures offer this option of rendering the proof at final resolution but just about all of them advice strongly against using this option as a general rule - too slow and only usable as a plot (not a contract proofing option). but in cases where absolute integrity is needed - a must.

time to go back to tiff-it? i don't think so. i guess it is adobes call to finally rid us of all those inconsistencies in supposedly resolution independent pdf workflows. or was that never adobes intention to evolve pdf into a printing/prepress solution - it is after all a great presentation and form creation tool ;).
 
Your proofs dont match your plates! Thats a bit worrying, how much did you pay for your workflow?

A
 
Well guys to make things more complicated I have don the same test on our Nexus WF trough the Nexus Total rip and all is OK here.
So I am not so shure its a Adobe problem.
 

Attachments

  • Screen shot 2010-11-22 at 09.26.41.JPG
    Screen shot 2010-11-22 at 09.26.41.JPG
    198.7 KB · Views: 214
Last edited:
Rampage is Global Graphic's Harlequin RIP, not Adobe.
Good to know.
CHM, are you sure your Nexus is using Adobe Rip?
I am asking as they just recently embraced Adobe PDF Print engine and for a while it was an option.
 
Rampage is Global Graphic's Harlequin RIP, not Adobe.
Good to know.
CHM, are you sure your Nexus is using Adobe Rip?
I am asking as they just recently embraced Adobe PDF Print engine and for a while it was an option.

No, the Total Rip already exist for more than 7 years now, and was 1 of the first Rips that could handle Transparencies, yes even before Adobe RIP.
The library thats inside the TotalRip is from Enfocus (the guys who are in the certifying busyness).
We have been using this RIP from the start, and don't have any problems with transparencies, we even work in full transparencies in Illustrator for years now.

I think the Adobe Rip is implemented in thier Backstage Rip, but not in Tortal Rip yet.
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top