Issue with hard returns in PDFs

[rich apollo]

We get A LOT of PDFs from various Windows apps (Word, Publisher and the like) that contain numerous hard returns. Think of hitting a bunch of returns to move the type insertion point down the page. The problem that arises is that the font used for the returns is not embedded. So, of course it throws a red flag during preflight - and those red flags have to be investigated.

In testing with InDesign, I built a document with:

type
<return>
type
<return>

et cetera. I changed the fonts used for the returns to a host of different typefaces that were used only for those returns.

When I printed to file and Distilled, and when I exported directly to PDF, the resulting files excluded the returns altogether. The type showed up as separate lines of disconnected text.

So, is there a way to:

1) get these fonts that are used only for returns to embed?
2) exclude these fonts that are used only for returns?
3) alter Acrobat's Preflight to ignore instances of unembedded fonts that are used only for returns?

I'm looking for automated ways to handle this.

 

[kyle]

Rich,

I think the invisible text lines have a single space character in them. You will usually get this at the end of any line with a hard return also, not just the empty ones, and it should be in whatever font the return character was in. I'm curious how you're getting PDF's with all fonts embedded except for the empty lines. I'm assuming the Word user ended up with a document that had fonts that were only used for the consecutive return characters, but I tested it with Word from Office 2004 for Mac, and it still embedded a font only used for return characters. Are these PDF's that also have unembedded fonts in the visible text that you have to force the fonts into? Indesign never does this because the coders were smart enough to realize that invisible text lines are a waste of space and processing. Maybe Microsoft did this on purpose so we can have a good laugh when we realize the document creator repeatedly banged away at the return key like a coked-up woodpecker in order to effect a page break.

You indicate that it would work for you to have Acrobat's preflight ignore these empty lines. Does that mean your RIP is okay with them? I don't think you can modify the Acrobat preflight to exclude these false positives. If you have Pitstop, you can run this action list:

Select unembedded fonts
Select object with height of zero
AND
Remove selection

This should remove any of the text segments that are exactly horizontal, and you could then repeat the Acrobat preflight to get a cleaner report.

Alternatively, if you save the PDF as Postcript out of Acrobat and refry with Distiller, I think the empty text segments will be removed. This will of course flatten transparency, but I'm not sure you can even get transparency out of Office applications. It's too bad Word doesn't have the "print to file" option anymore, then you could just start out with Postscript.

 

[rich apollo]

I think the invisible text lines have a single space character in them. You will usually get this at the end of any line with a hard return also, not just the empty ones, and it should be in whatever font the return character was in. I'm curious how you're getting PDF's with all fonts embedded except for the empty lines.

You indicate that it would work for you to have Acrobat's preflight ignore these empty lines. Does that mean your RIP is okay with them?

I opened one of these PDFs in Illustrator to find out what the characters are, but Illustrator disregards them, too. Using PitStop I copied one and pasted into Illustrator - all I got was a return.

They don't seem to bother anything in the RIP, but many of these folks will fail to embed any of their fonts. So, I can't really give up preflighting. I assume they don't wreak havoc at the RIP because they reference invisible characters. There is a Preflight setting for invisible text (¿rendering mode 3?), but I couldn't get it to fire.

 

[kyle]

Rich,

I think the rendering mode allows text that uses normally visible glyphs to be invisible (maybe to insert a hidden sort of "watermark" or to overlay OCR text over a scanned image to retain the image but have searchable text).

The problem is that every check (at least that I know of) in either Acrobat or Pitstop doesn't regard the invisible segments as being any different than the rest of the text. It's in the normal rendering mode, it has a fill color, but it just doesn't show up because it uses an empty glyph. If only there was a way to check for text segments that use or do not use a specified character. This leaves the height as the only dividing attribute (and then only for exactly horizontal text).