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
Just saw this, and decided to leave a comment.
Virendra Bhalla: Adobe has solved that problem relating to Zapf Dingbats. In Adobe Font Folio 11, they included an OpenType version of the font.
We have problems sometimes with CID-fonts in adds, on a new Harlequin RIP! The only thing that differ from all other adds in our workflow is the Identity-H issue, so I guess this is it. What bother me is that this problem maybe will come up regardless which method to use when creating PDF-files (according to Dov above). Or is there some way to do it safe from ID CS3?
A strange thing: RIP-results will not be the same from time to time, even if we put the same file through the RIP. Three times will get three different results, with characters in a mess on some rows!
Why do the chaos theory have to interfere here! :(
We can’t dream of beeing the only company having problem with this issue, on a widely spread RIP-type as Harlequin! I believe Sweden shouldn’t be the only place in the world that uses a lot of Harlequins…
And no, there is no icebears in Sweden… ;)
After exporting an Indesign document to a pdf, I was wondering why some fonts appear twice the same with different font encodings.
As example, the font TnTFormBSK-Light appears once as font encoding ansi and a second time as font encoding Custom.
The export is done on a Macintosh with Indesign version 5.04.
Full explanation with screen shots on:
https://forums.adobe.com/thread/418994?tstart=0
Some of our ads come in as digital ads from outside sources. They come in as pdfs. We call those into our InDesign templates and make an eps file. The eps files are used for proofing and print imposition.
Not all Identity-H fonts cause a visual problem but when they do they always show up after and eps file is made and sent to Acrobat Distiller for proofing purposes (pdf/eps/pdf)
Note: that this does not fail at the distiller or rip but the font is definitely messed up (missing, shifting etc.)
So far the way we fix them is to rasterize the pdf (becoming an eps file) and call that back into the InDesign template. From that a new system eps is made and then it is ok.
We have no choice but to do it this way because we don’t have the original native files.
Anne-Marie and I talk about CID fonts more in this podcast.
Everything Adobe does related to fonts seems to perpetually make things more complicated. This probably has a little to do with the fact that Adobe owns fonts and would like everybody to keep buying them. Has anybody ever been able to simply open an InDesign made pdf in Illustrator without font hassles? The problem is basically it isn’t profitable to make interoperability easy. Font-subsets are basically a ruse (save a few k, oooh) preventing easy editing after the hand-off. Funny, when I combine pdfs, I have mnay subsets of the same exact font bloating the file anyway. I’d like to see Adobe get a good beat-down soon — after Microsoft has ceased to be the only office platform and unicorns are plentiful.
dvd(etc.): a question. Do you only use Type1 fonts from 1985, with no more than 224 characters, or are you happily (without knowing, perhaps) using OTF fonts containing several thousands of different characters and features such as reall small caps, titling capitals, real fractions, swashes, and tons of ligatures?
@dvdrtrgn: I understand your frustration, but remember that Adobe is not the only font foundry in town. In fact, smaller (and other large) font foundries are often far, far more crazed about font security than Adobe. And Adobe doesn’t own the opentype font spec!
Note that using any Wingdings font in InDesign (and some other pi or dingbat type fonts) also appears to create a CID fonts when exported to PDF.
how i can solve the problem if data on pdf is copy on notepad or any editor (such as Word Pad) then
the glyphs or character are shown in unreadble formate that is written into no defination
if pdf is encoding with identity-h their is any way
to identify glyphs used in pdf font
thanks advance
Jaydeep Damodar Surywanshi
Developer