And another thing, I see you use FFPS Core, can't help there, but it means it is more likly you have an FFPS over a Fiery, which means no simple archive job. But, on another note, back to the driver thing.
Xerox sets the driver to replace fonts with the resident fonts on the Printer/DFE. This can cause 2 bad outcomes, one is what you are seeing, and the more common "I have no idea what font that is, so I shall replace it with Wingdings font!!!!" I have no idea why, but it always chooses Wingdings, no matter the device, always wingdings, and I get calls at least weekly saying "It prints this job all garbled", which undoubtedly means they got the wingdings.
GRrrr, Arghhh.
Change the driver from Substitute with Device font
To Download as Softfont
If it is happening with a commonly used font, get a copy of the font and import it into the FFPS via Administration > Postscript/PDF/PCL fonts
Then choose Postscript Soft > Load and browse to a location where you have a copy of the font to load.
It appears the font is unknown, or incorrectly embedded, hard to say without an archive of your job to after it failed.
If you are the content creator, switch to PDF/X, I tend to favor pdf/x3 purely for a compatibility across a wider range of devices.
You can also get these sorts of errors with booklets, mixed finishing and or subset finishing due to how the fonts are sent if they are printed as opposed to imported, in cases where pdf/x doesn't resolve the issue you can simply change the Font and resource Policy to Send for each page instead of the default standard Send by Range (If you ever print a booklet where the outside page prints, back broken PS code fills the rest of the job, this is the fix)
But all in all, Generically speaking, especially in the Production environment, you should be saving everything as pdf/x, and everything should be submitted by hot folder or importing through CWS. The driver and application are needless points of failure and in Production should only be used when things have gone wrong, or for one-off un-important jobs, which in my experience, don't get run on an iGen.
The following is cut&paste from an ACE (Adobe Certified Expert) rep in 2nd level, not my own words, it is dated, but stands up today just as much as when written.
PDFX is a standard Adobe made for the commercial and digital printing industry when PDF went open source . So today, there are good and bad PDFs for lack of a better term. All output devices regardless of manufacturer are PDFX compliant. While things change in our designing and computing environment, like application versions, drivers, operating systems, etc, by using a PDFX workflow, there is a constant that will never change. All output devices have a job submission tool. With Fierys it's Command Workstation (www.efi.com/cws5), some are webbased through an output devices IP, some are remote desktop file transfer, etc. Therefore when you adopt PDFX based workflow without using a driver to submit the job, many things happen. 1, is when you view the PDFX onscreen you are looking at what you will get on output. No longer is there an undesired color shift when printing from InDesign for example if you've used a transparency effect on a file...you don't see how the output device is going to render it until it prints out, then you blame the output device. Another thing that happens is now the file is preconformed to a postscript format the output device recognizes...no longer do you have these enormous bloated postscript files that slow the output device down to a crawl as it chews through all the overhead in postscript code it does not recognize...example: type hi testing output speed in InDesignCS5.5 on Mac 10.7.4 and print it using the driver...observe its behaviour and size going through CWS. Now, with that same file open, click the File pull-down menu, AdobePDFPresets will expand as a tree and click on PDFX3. Drag and drop the resulting PDF onto the HELD Tab of CWS v5.3.1 - boom its held. Now, double click to set print properties and click print button. Observe size and speed difference than printing from native app through CUPS.
Hope this helps in managing a reliable and predictable workflow in all environments.
If absolutely needed, I could maybe look at one of your failed jobs (zip up an archive of it) and the original document if you supply them to me in some way, I don't have any storage space to allot you so you would need to come up with the transfer method from your end. I can't promise a resolution though, just that I would be willing to try in a not time sensitive manner. (Call support if you need quick, Xerox doesn't pay me to help on the forum so time here cannot take away from my primary responsibilities).
P.S. If you have a Freeflow, pretend I didnt mention CWS and replace it with Freeflow Remote Desktop
