When would you want to flatten transparency in a PDF?

Macmann

Well-known member
I am new to the Esko suite of prepress software and I noticed that in Backstage Pilot, in the ticket settings you can check a box to flatten transparency. When would you want to do this? It seems that most of the headaches in a PDF workflow are when the client provides a flattened file.
 
Last edited:
The only time I would ever want to flatten a PDF prematurely would be if it won't RIP as is, or if I was getting results that didn't look right for some reason.
 
You might want to flatten transparency if you want to make use of (heavy) GCR or devicelink profiles.
 
I agree with Dan, this option is useful if your RIP does not interpret transparencies correctly, or when it takes too much time processing them. To avoid this situation you better flatten before. In the case you always have to edit the normalized PDFs and make some kind of corrections, I agree with you sometimes it is a headache, but I am not with you that most of the headaches in a PDF workflow are when the client provides a flattened file. All the contrary, if the incoming file is a Print-Ready file and at the same time it is PDF/X-1a:2001 compliant, you shouldn't have any problems related to transparencies, because they are restricted (not supported) and have been flattened on the PDF creation process.

BTW, If you upgrade BackStage Pilot to Esko Automation Engine (Suite12) you will realize that you don't have this option available anymore in the normalisation ticket.
 
Last edited:
Thanks to all for your quick responses. It's interesting that Esko removed the flatten check box. I look forward to our upgrade. As far as getting a print-ready pdf, I have not been to this Xanadu you speak of. wink
 
Thanks to all for your quick responses. It's interesting that Esko removed the flatten check box. I look forward to our upgrade. As far as getting a print-ready pdf, I have not been to this Xanadu you speak of. wink

My guess is they removed that option because of the unexpected results the end user was receiving after checking that box. I flatten pdfs quite often if I have to outline fonts I don't have in order to manipulate the job in Illustrator. Unexpected results on a large percentage of those flattened pdfs is an understatement.

When Illustrator introduced transparencies is around the same time my hair really started to turn gray.
 
I flatten pdfs quite often if I have to outline fonts I don't have in order to manipulate the job in Illustrator

Get yourself a copy of PitStop Pro and you can convert the text to outlines without flattening the PDF.

If you're running a RIP with the APPE, then you wouldn't want/need to flatten at all unless you ran into something like Dan cited.

Toronar, you say you might want flatten to make use of DVLs. Could you explain? It's not necessary to flatten to use DVLs, but I'm guessing you have reasons that I'm not aware of.
 
Flattening is something I would do only as an exception.

Converting fonts to outlines is a horrible thing to do to a font. I know, sometimes it's necessary. But not very often...
 
Converting fonts to outlines is a horrible thing to do to a font. I know, sometimes it's necessary. But not very often...

I'm curious why you feel it's a "horrible" thing to do to a font?

I've never had an issue with a font that has been converted to paths, either by me or our customers in the 20+ years we've been digital.
 
I prefer not to outline fonts to paths, however there can be valid cases where this is needed. Sometimes outlining is performed if one has an old RIP, if one does not trust an unknown printer, for logo supply, or to make it harder for a proof to be repurposed etc. If a publisher or printer asks for all fonts to be outlined to paths in a supplied PDF as their standard file submission, then I don’t have much confidence in their prepress workflow.

Outlining a font to paths looses the font hinting, which is important for onscreen display. This hinting issue may also affect digital print output, see below.

Outlined fonts (paths) print thicker than a live font on most digital print devices, which is very noticeable at smaller font sizes. The higher resolution of a plate setter appears to overcome this rendering issue. If all text is outlined to paths, then this will not stand out as much as is the case if one has mixed paths/fonts in the same job. This thickened rendering can be exploited for reversals, where you may not have the option to use a thicker font weight, however you do wish to have more legibility in the text. One then outlines the reversed fonts, leaving all other fonts live.

Not all software outlines fonts to paths with the same results, some are better than others. Not all characters are converted with the same fidelity. Depending on the software, paragraph rules, numbering, bullets etc. can all disappear! Flattening to paths/outlines in a PDF export from InDesign is better than converting to paths first. Compare the results carefully of converting to outlines in InDesign, Illustrator and Acrobat Pro for the same font at the same size etc.

Unless one keeps live fonts in a backup layer or duped file, making last minute edits to text is difficult with outlined fonts. Yes, one can copy characters from elsewhere in the document and move them into position etc. If one needs to reset more than a character or two, then live fonts are best. One may not know what the font was, if it had horizontal scaling applied etc. I once asked a peer at another forum to create an AppleScript in Illustrator to retain the font metadata when outlining a font to paths:

Prepression: Retaining Outlined Font Metadata in Adobe Illustrator via Scripting


Stephen Marsh
 
Last edited:
I'm curious why you feel it's a "horrible" thing to do to a font?

I've never had an issue with a font that has been converted to paths, either by me or our customers in the 20+ years we've been digital.

On behalf of Adobe, there are only two good reasons to convert text to paths.

The first reason is to achieve artistic affects with text such as but not limited to joining glyphs or distorting either individual glyphs or text in ways that cannot be done with conventional text transformation capabilities of either PostScript or PDF that are accessible in Illustrator or InDesign.

The second reason is to accommodate devices or braindead workflow systems that feed special devices that only support vector operations, such as specialized sign cutters. (And even for these devices, the RIP should -famous last words - be capable of deriving the vectors for cutter from the font definitions in the PDF or PostScript file submitted!)

Otherwise, converting text to paths or outlines (aka “outlining text”) has a number of very negative consequences:

(1) Once you convert the text to paths or outlines in your source InDesign or Illustrator file, you lose the ability to further edit such text. You'd better save a version of the document with the “live text” before doing these conversions.

(2) The resultant PDF file has no capability for either text search or text touch-up either in Acrobat or in third party plug-ins or applications. All that remains are tons of vectors.

(3) The resultant PDF file is likely to be grossly inflated in size compared to one which uses fonts to render the text. Furthermore, rendering time for that text for both printing and display may increase dramatically since the entire font and glyph caching mechanism of the RIP is effectively bypassed. Each character is its own independent filled polygon (and sometimes more than one such polygon).

(4) For screen display and for printing, depending upon the font's characteristics and the style used as well as the particular point size in combination with device resolution (and viewing magnification for display), you are very likely to get over-emboldened looking text especially in areas of fine detail. These problems are especially evident at text sizes and with serif fonts and can often be seen with devices up to 1200dpi. Why is this the case? Text rendered using fonts take advantage of a feature of most high quality commercial fonts known as hinting. Hinting is data put into the font by the font designer to assist the RIP's renderer when dealing with not enough pixels to fully and properly render the fine detail in a glyph's design, such as serifs and thin stems. Converting text to paths effectively throws away all the hinting information and causes the scaling of the polygons now representing the text to be done entirely linearly, without regard for how the results will look. Rendering text with fonts is intelligent rendering and scaling. Converting text to paths yields simple linear scaling!!

Requirements provided by some print service providers to “outline text” are typically bubbameissas or urban legends based upon some experience that a printer may have had or heard about some other printer having had in the distant past usually due to a combination of a dodgy RIP and/or a very defective font. Having personally monitored the bugs reported to Adobe over the last twenty-something years against both our PostScript and Adobe PDF Print Engine implementations, I can assure you that font rendering problems, at least with products based on Adobe implementations, are very, very few and far between and are typically due to malformed fonts and even then only under fairly oddball circumstances (such as non uniform rendering resolutions such as 600x1200 and/or with antialiasing enabled).

- Dov
 
On behalf of Adobe, there are only two good reasons to convert text to paths.

The first reason is to achieve artistic affects with text such as but not limited to joining glyphs or distorting either individual glyphs or text in ways that cannot be done with conventional text transformation capabilities of either PostScript or PDF that are accessible in Illustrator or InDesign.

The second reason is to accommodate devices or braindead workflow systems that feed special devices that only support vector operations, such as specialized sign cutters. (And even for these devices, the RIP should -famous last words - be capable of deriving the vectors for cutter from the font definitions in the PDF or PostScript file submitted!)


- Dov


Reason #3: Missing a ship date due to not being able to contact the "graphic artist" or our customer not being able to contact their customer who supplied the submitted art.

I agree with converting fonts to paths can and will create issues in some circumstances. If any issues come up on a *rush* job that has been flattened and converted to paths then every effort is made to contact the customer. But if we can correct the issue ourselves, in-house, it can save one or two day delay in the production process. When the end product is time sensitive, dated or with minimal text the issues listed are irrelevant in our situation.

If you're outputting at a high enough dpi/lpi and not attempting to convert 3pt Snell Roundhand or Garamond Light Italic (although I'd rather convert it to outlines since doing so adds about .01pt to the face) serifs and thin stems shouldn't be an issue. We output at 2540/150.

Don't take me the wrong way. I'd rather not covert any submitted art. Or should I save "have" to convert any submitted art. I'm not doing it because my RIP is inadequate. I'm doing it to meet deadlines that otherwise wouldn't be met. Which in turn would mean lost revenue.
 
Reason #3: Missing a ship date due to not being able to contact the "graphic artist" or our customer not being able to contact their customer who supplied the submitted art.

I agree with converting fonts to paths can and will create issues in some circumstances. If any issues come up on a *rush* job that has been flattened and converted to paths then every effort is made to contact the customer. But if we can correct the issue ourselves, in-house, it can save one or two day delay in the production process. When the end product is time sensitive, dated or with minimal text the issues listed are irrelevant in our situation.

If you're outputting at a high enough dpi/lpi and not attempting to convert 3pt Snell Roundhand or Garamond Light Italic (although I'd rather convert it to outlines since doing so adds about .01pt to the face) serifs and thin stems shouldn't be an issue. We output at 2540/150.

Don't take me the wrong way. I'd rather not covert any submitted art. Or should I save "have" to convert any submitted art. I'm not doing it because my RIP is inadequate. I'm doing it to meet deadlines that otherwise wouldn't be met. Which in turn would mean lost revenue.

Of course, that is why we recommend use of PDF/X-4 such that none of the submitted PDF has any pre-flattened elements. But I still don't understand how converting fonts to paths will help a printer fix any issue or what those issues are?

- Dov
 
Of course, that is why we recommend use of PDF/X-4 such that none of the submitted PDF has any pre-flattened elements. But I still don't understand how converting fonts to paths will help a printer fix any issue or what those issues are?

- Dov

I'm lucky if I don't get pdfs with downsampling to 120ppi. Or "smallest file size" because "it emails faster". (insert banging head on desk here). And trust me, it's not for lack of communication with our customers regarding art guidelines.

Issues just off the top of my head would be:

Incorrect bleed.

Die line is 100% cyan or 100% magenta or (insert color here) or not set to overprint.

Backside of a special shape die was not mirrored when creating the art for the backside. An extreme example to picture in your mind would be a crescent moon shape. Why some "artist" don't understand the image needs to be mirrored for the backside is beyond me. I've had to go as far as having them print the front & back side art out on their printer and cut out the image by hand before they could comprehend.

Random elements that were set to overprint in the native file/program. Probably the most frustrating.

Replacing low res logos with high res if we have on file or can find it.

Realize the artwork/pdfs I am receiving are almost never from the artist/customer directly. They are coming from my customer's client. Our customer is always made aware of any issue(s) when we preflight. A majority of the time, the customer tells us to fix it. If not, they would have to contact their sales rep, the sales rep would have to contact the customer and the customer may have to contact their design agency/artist/next door neighbor that created the art. This might be a 2 day ordeal. That can't happen since the job needs to leave my plant in 2 days to make it across country in time to be applied on a certain date. And no one involved wants to pay next day or 2nd day air rates on (5) 60lb boxes of labels. So our customers are very appreciative when we can actually fix 99% of the issues associated with submitted files.

This is my prepress departments biggest complaint. But like I tell them, if we don't fix the job and get the end product where it needs to be within the time it needs to be, someone else will.
 
Sure, I understand all the issues that you enumerate, but how would the customer converting text to outlines help in any of these or other cases. In fact, such conversion would actually limit the freedom you have to make these emergency fixes.

- Dov
 
Sure, I understand all the issues that you enumerate, but how would the customer converting text to outlines help in any of these or other cases. In fact, such conversion would actually limit the freedom you have to make these emergency fixes.

- Dov

I wouldn't have the customer convert to outline. I would have the customer fix the issues. Outlines are only created when we don't have or can't download a missing font.
 
What an interesting contrast the previous posts present. "Dov" coming from a perfect, theoretical point of view and "PreFlexoPress" relaying what it is like in the trenches. I couldn't have put it any more succinctly and probably would've used more colorful language. I have another reason one may be forced to convert text to outlines-Reflow-easily one of the more frustrating problems that can arise. BTW Dov, nice use of the Yiddish term bubbe-meise (a grandmothers fable). I had to look that one up-damn you Dov.
 

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