When Xerox FreeFlow Core Rejects a Customer PDF — What 26 Problem Files Taught Us About Intake

A bindery print shop's day starts with customer PDFs. An order comes in, the customer sends the manuscript as a PDF, and an operator drops it into a print workflow such as Xerox FreeFlow Core. Most files go straight through. The trouble starts when a few stall in the workflow. The error dialog rarely says why. The operator opens the file, re-saves it in Acrobat, and when that doesn't help either, calls the customer.

This article is a record of 26 customer PDFs that caused real problems in production at a mid-sized bindery print shop in Korea. One file went through once we changed the color of a single line of text. Some warnings looked alarming but had nothing to do with the printed result. Some files couldn't be fixed with any tool and had to be requested again from the customer. Sorting files into those three groups at intake is what the customer intake feature in Pressria Bridge (PB) 1.6.0 is built to do.

Print workflows assume a well-formed PDF

Workflows like FreeFlow Core preflight incoming PDFs, convert fonts to outlines, and hand the result on to imposition and output. All of this assumes the PDF was built to spec. But customer PDFs don't come out of design applications. They come out of Hancom Hangul (HWP), PowerPoint, Word and scanner software. Some use structures that are legal but unusual; others are damaged outright.

The problems in the 26 files fell into three groups.

• Fixable — a single structure or property blocks the workflow. Leave the original alone and make a separate fixed copy.
• Looks like a warning, but doesn't affect the print — the operator doesn't need to care. When there are many of these, the real problems get buried.
• Unfixable — the data isn't in the file. The only way out is to get the file again from the customer.

Case 1: One line of copyright text at the foot of the page — Type3 text in RGB

One file of more than 800 pages kept failing on the FreeFlow Core binding path. The failing range was pages 797–808, twelve pages in all. To narrow it down, we extracted just pages 797–798 and built several variants, and the print shop ran each one through FreeFlow Core.

The cause was the copyright line at the bottom of each page. That line alone was set in a Type3 font (we suspect it came from Hancom Hangul's PDF export), filled in DeviceRGB blue. Everything else on the page used regular fonts in grayscale.

A Type3 font defines its glyphs directly with PDF drawing operators. Instead of carrying a font program the way TrueType or Type1 fonts do, it effectively carries a small drawing for each character. The Type3 glyphs in this file had no color of their own, so they were painted in whatever color was current when the text was drawn — here, the RGB blue.

There is no public documentation of why FreeFlow Core fails on this combination. What we did confirm comes down to three things:

1. Removing the line makes the file pass (C).
2. Changing only the text color to CMYK also makes it pass (D).
3. Converting the text to outlines to get rid of the "font problem" leaves the workflow unable to finish (E).

So PB makes the smallest possible change. It converts only the RGB color (fill and stroke) in effect while Type3 glyphs are drawn to CMYK, then restores the original color. The font itself is not changed. Shapes and images that share the same color state are not affected. The conversion uses the output ICC profile, or a default profile if none is set. Gray (R=G=B) goes to the K plate only, so small text doesn't turn into four-color black. After the change, PB renders the page before and after, and drops the fix if anything outside the target glyphs looks different.

One of the 26 files had this structure. It isn't common, but a print shop that receives textbooks or handouts made in Hancom Hangul can run into it.

There was one more lesson. When we first tested the file in Acrobat Preflight, splitting the fonts (B) looked like the fix. In FreeFlow Core it failed. Passing a desktop tool doesn't guarantee passing the print workflow. The final call has to be made in the real workflow.

Case 2: An alarming warning that doesn't affect the print — hidden text

Scanned and OCR'd PDFs carry a text layer you can't see on screen. It's there for search and copy, and the PDF marks it as invisible (text render mode 3). At first we flagged it as a warning: if that text were printed visibly when fonts are converted to outlines, it would be a real accident.

So we checked. We ran a 48-page file with a hidden text layer through Acrobat Preflight's "Convert fonts to outlines" fixup. All 10,240 operators that drew the hidden text disappeared, and the before/after rendering differed by zero on all 48 pages. Outline conversion doesn't draw invisible text.

We downgraded the item to Info. The report only notes "hidden text (for search) present — no effect on print," and the verdict doesn't go up.

When a font used only by hidden text isn't embedded in the PDF, PB puts a substitute font into the fixed copy and marks it "font used only by hidden text — no effect on print." The missing font itself still stays at Warning, as the rules say.

Cutting warnings is a feature too. If the operator has to ask "is this one OK?" every time, the real risk flags end up read with the same weight as everything else.

Case 3: Files that can't be fixed — and "It opens fine on my PC"

Three of the 26 files were damaged.

• One file wouldn't open in one PDF engine. Another engine opened it, but pages 168–170 were blank.
• One file was cut off at the end, as if saving had been interrupted.
• One file had a broken cross-reference table (xref), so engines disagreed on the page count: one read 180 pages, another 216.

What makes these files tricky is that they do open on the customer's PC. Viewers like Acrobat try to repair a damaged file when they open it. A repair notice flashes up and the document opens — but along the way some pages come up blank or go missing. The customer says "it opens fine," and the print shop is left with the risk of printing a book with blank pages in it.

Damaged data can't be recreated. The intake step has three jobs:

1. Don't pass the file on to the print workflow.
2. Show the operator exactly what's wrong — for example, pages 168–170 damaged.
3. Keep the round trip to the customer short.

PB flags these files as Critical and doesn't copy them to the print folder. If the file came in with an order, the operator can send the customer a notice with the [Request re-upload] button in the intake history. The button appears only for files flagged Critical, and only once the print shop has registered a message template. In Korea, the message goes out as a KakaoTalk business message under the print shop's own name. It includes:

• The file name and the problem, for example "Some pages (pp. 168–170) are damaged"
• A request to save the PDF again from the original application
• The upload link

A file the customer uploads again comes in as a new intake and is inspected again.

We reworked the wording, too. At first the message said "The file is damaged and can't be opened." But on the customer's PC these files open after repair, so customers often wrote back to ask what we meant. Now, when we know which pages are damaged, the message names them.

What happens at intake — Pressria Bridge customer intake

When a customer uploads files on the upload page, PB receives them, inspects them, makes fixed copies of anything it can fix, and sends only printable files to the print folder. For how files reach PB in the first place, see Customer File Intake.

• Organized by order (Korea) — In Korea, files that come in with an online-store order get the buyer's name (or the recipient's, depending on settings) and the last four digits of the phone number added to the file name, and each customer gets a folder. Example: original-name_홍길동-1234_120p.pdf. The page count is in the name, so the operator knows it without opening the file.
• Separator sheets — When turned on in settings, PB makes a separator (slip) sheet for each customer folder: a one-page PDF with the name printed on it. Its page size follows the size used most in that folder.
• Inspection — PB looks for damage, missing fonts, structural errors (such as references to deleted pages), mixed page sizes, and spot colors.
• Fixed copy — The original stays as it is; fixes go into a separate fixed copy.
  • Embedding missing base fonts with compatible fonts
  • Cleaning up the structure
  • Converting the RGB color of Type3 text
  • Removing print and edit restrictions. Open passwords are not removed.
• Copy to the print folder — When a copy path is set in settings, PB copies inspected files straight into a hot folder such as the FreeFlow input folder.
  • If there's a fixed copy, the fixed copy is sent. Critical files and separator sheets are not.
  • Files are written under a temporary name and renamed when complete, so the workflow can't pick up a half-copied file.
  • Network share paths work too.
• Re-upload request (Korea) — Sent from the intake history, as described in Case 3.

What PB deliberately doesn't do

• It doesn't convert fonts to outlines. That's FreeFlow Core's job. If PB did it first, it could stall the workflow, just as E did. PB stops at embedding fonts in the PDF.
• It doesn't remove open passwords. Print and edit restrictions are lifted, but the password that opens the content has to come from the customer.
• It doesn't change the original. Every fix is a separate file. The Type3 color fix is checked by rendering before and after; the other fixes are checked to make sure nothing on the page changed beyond the part that was fixed. If anything is off, that fix is dropped.
• It doesn't print damaged files "as best it can." Getting the file again from the customer ends up cheaper than repairing it and printing whatever survives.

An intake checklist

You can apply these right away, with or without PB.

• When a Hangul or PowerPoint PDF fails in the workflow, extract only the failing pages and test those. Narrowing the range exposes the object that causes it.
• Make one version with the suspect object removed and one with a single property changed, and run both through the real workflow. Don't decide on a desktop preflight pass alone.
• Re-sort inspection warnings by one question: does this affect the printed result? Downgrade the ones that don't to Info.
• Don't print files that trigger a repair notice in the viewer. If you can, compare the page count in two or more engines.
• When you ask the customer for the file again, say what's wrong and on which pages.

Closing

Output devices and workflow software keep getting more sophisticated, but the customer files that feed them still come out of Hangul and PowerPoint. The cheapest place to close that gap is at intake, not right before output. Fix what can be fixed, quietly. Say so when something is fine. Send back what can't be fixed, quickly. That's what PB customer intake is built for.

---

References

• Xerox — FreeFlow Core — product overview of the print workflow
• ISO 32000-1:2008 (PDF hosted by Adobe) — section 9.6.5, Type 3 fonts

---

Pressria automates print production workflows — white layer generation, cut-line handling, nesting, and Illustrator integration. Learn more at pb.pressria.com, and try the file verification tool at verify.pressria.com.

Xerox and FreeFlow are trademarks of Xerox Corporation. Acrobat is a trademark of Adobe. Other product names are trademarks of their respective owners.