CID Identity H Fonts are Back?
Oh, woe is us! It appears that the CID font mess never really left us. Some of you may remember that when InDesign CS came out, all heck broke loose because it started to write its fonts in its PDF files using something called CID encoding. We don’t need to get into the technical details of CID, other than to say:
- CID font encoding is a valid way to write fonts (even if it was originally meant to be used only for Asian fonts with huge character sets), and all PostScript and PDF readers should be able to deal with it fine.
- Many “clone” RIPs couldn’t or can’t deal with it, and they would often barf unceremoniously on these PDF files.
- Adobe heard so many complaints about this that they changed the encoding in CS2.
That was supposed to be the end of the story. Sure, CS2 and CS3 would still encode Asian fonts with CID, but that was simply to be expected and people dealt with it.
But sometimes, every so often, in the middle of the night, right before a deadline… CID rears its head again in a PDF near you. Why?
Deb Roberti wrote to us today with such an issue, and after much searching, she had found the answer:
I know you can fix it by making a PostScript file and distilling that instead of Exporting directly to PDF but Adobe and the other web sites I visited insist that upgrading to CS3 will solve the CID problem altogether. However, I am using CS3, the font is only Frutiger and I was left annoyed and baffled til I found this web page.
In tiny type at the bottom of the page it says:
InDesign CS3 has a known issue that bullet characters, for instance bullets and hypens in a list, are listed as CID fonts in the PDF.
Wow! What the heck?! Bullets and hyphens cause CID? Yup. Even if you just type a bullet character (Option-8 on the Mac) and export a PDF usign File > Export, it gets converted into a CID “Identity H” font. You can see it if you open the file in Acrobat, choose File > Properties, and click on the Fonts tab:
It’s not just bullets; it happens with a number of different characters. I believe it has to do with characters that don’t actually exist inside the font you’re using, but which get referred to a different font. For example, most fonts don’t have a square root character, so the OS points to Symbol or something like that. I’m sure someone (Mr. Phinney?) can offer a better explanation. And perhaps it’s only on the Mac? I don’t know. But when this switcheroo happens, InDesign appears to revert back to its old behavior.
Now, once again: This should not be a problem. Most printers handle this just fine now. However, it wouldn’t surprise me one bit if it was causing headaches here and there, especially on older devices. But education and awareness is the first step in getting through the day without Ibuprofen, so I thought it’d be a good idea to pass Deb’s excellent discovery on to all our readers. Thanks, Deb!
Oh, workarounds! David, don’t forget the workarounds:
- You can print PDF via the Print dialog box (or create postscript and use Distiller).
- You can use a character that does appear in the font itself rather than a bullet or whatever.
- You can convert the character to outlines (ick).
- You can find a printer that doesn’t barf on these files; that shouldn’t be too hard here in the 21st century.
- If you are having a problem with this, let Adobe know and perhaps they’ll change it someday.
Not just on Mac. This also occurs on Windows.
The first workaround, distilling a PDF, while minimizing CID encoding is not a guarantee that it will be eliminated and of course introduces other issues such as transparency flattening.
It doesn’t appear that choosing a character in the font itself is going to fix this. I used a round bullet in Times New Roman and whether I used the alt+0149 Windows code, alt+8 InDesign shortcut or simply a bulleted paragraph style the results were the same. A CID encoded font.
All that said, I would have to think that even the majority of clone RIPs out there have been upgraded for the most part to allow for CID-encoded fonts. In fact, this is the first complaint I’ve read about CID fonts in a long time and the forums were loaded with posts about it when CS was introduced.
So, I would have to agree that finding a new printer shouldn’t be all that hard. It’s also possible that the printer is unaware that there’s a simple firmware fix for the current RIP being used and perhaps the printer should be discussing this with the RIP manufacturer.
Bob, when I wrote “use a character that does appear in the font,” I meant, “use some other character that looks like a bullet, but isn’t that character.”
The more I look at this, the weirder it is; in some cases, just adding a bullet character anywhere in a document will make the entire font change to CID encoding. Strange behavior.
Also note that it’s not just printer RIPs that may have this problem. Other PDF-processing software (apps that need to read the pdf and do something with it) may have troubles. But again, that would likely only be an issue with old software.
Well, I’d be banging my head against a wall a bit more if Adobe didn’t have a technote on it already.
I’m going to guess that any software or RIP that’s going to have problems because of this is going to have problems with just about any advanced features of exported PDFs.
And if that’s the case, and your stuck with that workflow, distilling is probably your best bet. In fact, you may be even better off supplying EPS files which shouldn’t present any problem for any workflow that doesn’t involve a camera.
A quick test to see why I hadn’t been seeing this problem and it appears that using ornaments — at least those in Warnock — as bullets avoids the problem.
LTM
Interesting discovery which I can confirm. I played around with several fonts and no CID encoding.
Bob, you must have tried playing with Adobe fonts only. The problem is more often with Truetype fonts. Try Zapf dingbat.
Virendra
LTM’s point was that ornaments don’t get encoded as CID. I tested that out and as I already said, it’s true.
I’m curious, though. You refer to this as a problem. Are you a service provider that runs into this with your equipment or are you designer that has service providers with problems?
Lets all just use the Ellipse tool and draw little circles where ever we need bullets!
(Kidding of course, sorry I just had to!)
(1) InDesign 4 (=CS2) attempted to avoid CID encoding as much as reasonably possible, but there were no changes in this for InDesign 5.
(2) Use of the Distiller to produce PDF either from InDesign or any other application does NOT guarantee that you won’t get CID encoding. In fact, the Distiller uses CID encoding for optimization its conversion of PostScript to PDF.
(3) CID encoding has been an integral part of both the PostScript specification since 1996 (although it is supported by most PostScript Level 2 devices) and the PDF specification since PDF 1.3 (Acrobat 4 - 1999). In reality, if a print service provider (or a content creator) is using software that is NOT CID-encoding compatible, it is saying that software is being used that is also most likely incompatible with ICC color management, transparency, layers, and JPEG2000 image compression. This is a recipe for disaster for print customers. If your print service provider has problems with CID encoding, you should seriously question whether your print service provider is competent to handle your 21st century print needs with 20th century workflows and tools!
- Dov