Remove CID font

[petert83669965]

Hi,

I created a PDF form that sends to user who fills it. Then the document sends to printercompany who prints out the PDF document.

The printig Company sends back the PDF and say they can not print because it is the CID font in the document.

"OK, the CID fonts is an adobe construction that uses another font table than regular fonts. In our print process included an optimization step where the font replacement copies of shared resources and where the problem arises. Character table of a CID font is not the same as other fonts. Both TrueType, OpenType, and PostScript using the same font tables."

A colleague has shrunk the file with an external program, but the CID font is left.

I've Googled but can not find how to remove the CID font from Adobe Acrobat Pro DC.

[Test Screen Name · Accepted solution]

Find another printer, they are trying to make you jump through hoops because their software doesn't work. CID fonts are normal everyday things, often used for all kinds of text.

[Dov Isaacs]

On behalf of Adobe, confirming the response vis-a-vis CID fonts. CD fonts have been part of the PDF specification for many years and any RIP, DFE, or PDF workflow software of any recent vintage should be able to handle those fonts.

Either the folks at that printer company are using ancient pre-21st century tools or they are ignorant of the capabilities of their tools and workflows.

[Eyrei]

I work for a company that does printing/mailing and I think there is more going on here than the original question describes.  It is common for printing vendors to be blamed for technical issues that are not their's to solve. It is amazing how people jump to conclusions about companies using inferior tools when there is often another explanation.

The original poster should have made sure he/she had all fonts properly embedded and with a cmap available, because in my experience, the source of problems like this is the designer of the document and not the printing or mailing company.  This is essentially what the printer pointed out in their response.  I hope the end-customer did not fire the printing company, because the designer is the likely culprit.

It is common for mailing companies to use PDF reading software that allows them to barcode multiple sheets of paper to be inserted into a single envelope on inserting equipment.  CID fonts with Identify H encoding present problems for this type of software.  Here is an enlightening discussion on the problem on Stackoverflow.com:

Extracting Text from a PDF with CID fonts - Stack Overflow

The most relevant quote being:

If you have a CID font with Identity-H encoding you essentially cannot know what the glyphs represent without a ToUnicode. Sometimes it is possible to parse the underlying embedded font and check if a cmap is present there that can be used for the reverse mapping of glyph IDs into Unicode characters. If both are missing, you are out of luck and cannot find the mapping from the glyph ids into unicode characters (and hence the text meaning). – Ritsaert Hornstra Oct 30 '15 at 22:31

[Dov Isaacs]

To be very clear, vendor of PDF creation tools that produce PDF files using CID-encoded fonts without the mapping to Unicode characters are very much part of the problem here. Likewise, vendors of “PDF reading software that allows them to barcode multiple sheets of paper …” that either can't handle CID-encoded fonts at all, use the mapping tables, and/or properly diagnose problematic PDF content are part of the problem.

Quite frankly, such mailing software that relies on scraping PDF files to get barcode information as opposed to working with metadata in the PDF file are also problematic.

But again, CID fonts with Identity-H encoding part of the PDF standard and FWIW, the PDF/X-4 subset standard requires the to-Unicode tables. Based on what we know about the base ISO PDF standard, the subset standards, and software (both PDF creation and consumption) in the marketplace, our original response stands.

[Eyrei]

I don't agree with your assessment.  The print vendor (to be clear, I don't even know who the parties are in the original question) did correctly diagnose the problematic PDF content, and if the cmap is not included with this type of font, it is impossible for any software to sort it out, because the information is missing.

Regarding metadata, are you suggesting that the proper way to send a 70k document mailing to a printer is in 70k individual pdfs, so that the page count in the PDF metadata can be used to barcode each set, rather than reading a single PDF and using the elements in the document as control characters?  I'm not sure that is feasible without exploding the file size during the recombination of the PDFs for printing, as the fonts will be embedded 70k times in our experience, but if you have a suggestion I'd be glad to hear it...

I understand about the standards, but I'm not sure how that excuses bad PDF design that leaves out important information about the fonts.  By violating those standards, the designer is the problem, not the print vendor.  You seem to be saying that even if the designer violates those standards, the printer is responsible, which is nonsense.

[Dov Isaacs]

eyrei  wrote

I don't agree with your assessment.  The print vendor (to be clear, I don't even know who the parties are in the original question) did correctly diagnose the problematic PDF content, and if the cmap is not included with this type of font, it is impossible for any software to sort it out, because the information is missing. …

I didn't disagree with that. I'm not blaming the print vendor but there are too many folks out there who issue blanket prohibitions against PDF files with CID fonts with Identity-H encoding. The problem is either the printer's RIP or PDF workflow software or in this particular case, whatever software generated the PDF file. This isn't a “designer” issue but rather an issue with the vendor of the software generating the PDF file.

eyrei  wrote

… Regarding metadata, are you suggesting that the proper way to send a 70k document mailing to a printer is in 70k individual pdfs, so that the page count in the PDF metadata can be used to barcode each set, rather than reading a single PDF and using the elements in the document as control characters?  I'm not sure that is feasible without exploding the file size during the recombination of the PDFs for printing, as the fonts will be embedded 70k times in our experience, but if you have a suggestion I'd be glad to hear it...

No, I am not at all suggesting individual PDF files. How about using the PDF/VT standard that provides such metadata?

eyrei  wrote

… I understand about the standards, but I'm not sure how that excuses bad PDF design that leaves out important information about the fonts.  By violating those standards, the designer is the problem, not the print vendor.  You seem to be saying that even if the designer violates those standards, the printer is responsible, which is nonsense.

Again, the designer is not the problem, but rather the developer of the software generating the PDF itself is the problem here.