Has anyone seen this error before in their console:
<Error>: can't get CIDs for glyphs for 'ArialMT'.
I am trying to use an Arial font for outputting to a PDFContext, and am getting this error over and over in my console.
I have tried different fonts, and they all seem to have this same error (just font name changes).
I also get an error like this:
<Error>: CGFont/Freetype: The function 'get_subset_format' is currently unimplemented
Any help on getting rid of these errors would be greatly appreciated. Everything actually renders fine in my PDF, but the vast # of these errors in my console makes it very hard to troubleshoot my app which has several NSLog(...) lines that get lost amongst the sea of errors as noted above.
Has anyone seen this error before in their console:
<Error>: can't get CIDs for glyphs for 'ArialMT'.
I also get an error like this:
<Error>: CGFont/Freetype: The function 'get_subset_format' is currently unimplemented
Thank you.
I feel your pain, as I 'm getting this errors too...
So this is what I've found:
the iPhone only has about 11 families of fonts, being :
American Typewriter
American Typewriter Condensed
Arial
Arial Rounded MT Bold
Courier New
Georgia
Helvetica
Marker Felt
Times New Roman
Trebuchet MS
Verdana
Zapfino
to me, this errors comme with another that says: can't get CIDs for glyphs for `MyriadSet-Bold', so I'm guessing it happens because I'm trying to render a PDFpage that tries to load a non-embedded / non-platform font.
I have tried Arial, Verdana, Helvetica, Times New Roman... all supposedly on the phone, but the all cause the error. I can't believe nobody has a solution for this. I have tried Google, developer.apple.com, and every other source for information, but nobody seems to have the answer.
I think this might be the first question I have actually posed in this forum while answering many, so I am really hoping someone can reciprocate.
The odd things is everything actually WORKS just fine... I see my text on both the iPhone and when viewing the generated PDFs on other machines. It is just very annoying to get all the error messages which making seeing my "real" NSLog statements more difficult when surrounded by a hundred of these errors.
Apparently not many people are creating PDF's as I have gotten no answers, and it happens with all sample code I have found for writing text to a PDF.
I have spent MANY hours trying to come up with a solution, and finally gave up. Our product shipped with these error messages, adn everything works fine. I just hate that when I try and use NSLog(...) for debugging, I now need to wade through tons of these error messages.
If anyone finds a solution, I will be very grateful.
I just tried changing to "Times New Roman", and the error message is still there. The actual font name it is complaining about has now changed, but the message is still there:
<Error>: can't get CIDs for glyphs for 'TimesNewRomanPSMT'
PDF Files generated by the iPhone SDK are not valid
These warnings started when we installed 2.2.1 SDK. We were worried that the PDF files might not be readable because of these warnings. One customer noted that the text was garbled when viewing the PDF, so we analyzed the PDF in detail to check if the fonts are properly represented. Here is what we found out:
The fonts are being inserted into the PDF as CID fonts which allow for more than 255 characters per font. This is useful to support anything more than MacRoman character sets. Here is how the font is typically represented in the PDFs generated from an iPhone application: Main font object:
8 0 obj << /Type /Font /Subtype /Type0 /Encoding /Identity-H /ToUnicode 35 0 R /BaseFont /ArialMT /DescendantFonts [ 30 0 R ] >> endobj
Descendant font (PDF allows only 1 descendant per font)
The font contains a valid ToUnicode entry, which makes the files searchable. It also contains a CIDToGIDMap, which maps the character IDs to GlyphIndexes which is used for rendering the fonts. In order to render the text, a viewer would first map from the character code to the glyph index using the CIDToGIDMap, then retrieve the glyph from the embedded font in order to render it. In this case, there is no embedded font, so in theory a viewer that follows the PDF specs will not view these files. One way a viewer can get around this issue is to ignore the CIDToGIDMap and use the ToUnicode entry, but this is not what the PDF specifications say. The specifications are actually very clear, quote:
"
If the TrueType font program is not embedded but is referenced by name, the
Type 2 CIDFont dictionary must not contain a CIDToGIDMap entry, since it is
not meaningful to refer to glyph indices in an external font program.
"
Acrobat 5 actually refuses to open these files, so does Ghostscript (a library that is behind a number of PDF viewing applications.) Later versions of Acrobat succeed in displaying these files as they seem to ignore the CIDToGIDMap when the font is not embedded. In the Amyuni libraries, we have two modes for viewing PDFs, one mode ignores the CIDToGIDMap and uses only the Unicode table, so this mode has to be used in order to process these files.
Sorry for the bad news, maybe Apple will fix the SDK in a future version.
It's really not that big of a deal... everything works fine with the standard PDF viewer, and the PDF viewer built into the iPhone. The web based PDF viewer in Google Mail does not display the PDF correctly, but as long as the user downloads the PDF to view it, it works fine.
Really no need for a tool to create the PDF... just annoying that we get the warnings in the console log.
Have there been any new developments on this? I am working on an app that generates pdf's, and just started running into these errors, and hence found this thread on google. I am using the latest SDK, so clearly the problem has not been fixed.
This is a pretty big issue for me, because my app emails out the pdf's, so a significant chunk of users will open them in gmail, where they are (still) not readable.
I found this blog post which describes a workaround, but it requires use of an undocumented API, so with the recent changes to the app store, any app that used it will probably get rejected... http://mexircus.com/blog//blog4.php/...with-pdf-files
Quote:
Originally Posted by ftm
It's really not that big of a deal... everything works fine with the standard PDF viewer, and the PDF viewer built into the iPhone. The web based PDF viewer in Google Mail does not display the PDF correctly, but as long as the user downloads the PDF to view it, it works fine.
Really no need for a tool to create the PDF... just annoying that we get the warnings in the console log.
Update, I just noticed that the person who wrote that blog post has some recent updates. He actually did get an app rejected for using that method, so basically he rewrote it himself. So I guess this is a workaround for the problem, though it looks like a lot to digest... CGFontGetGlyphsForUnichars fixes
Quote:
Originally Posted by pmattf
Have there been any new developments on this? I am working on an app that generates pdf's, and just started running into these errors, and hence found this thread on google. Using the latest SDK, so clearly the problem has not been fixed.
This is a pretty big issue for me, because my app emails out the pdf's, so a significant chunk of users will open them in gmail, where they are (still) not readable.
I found this blog post which describes a workaround, but it requires use of an undocumented API, so with the recent changes to the app store, any app that used it will probably get rejected... Messing with PDF files
We still don't have an fix for this, though everything does work fine... it's just an annoying message in the console log.
It is more than an annoying message in the console log, because the resulting pdf's are not valid, and do not work everywhere. In particular, if you email them to a gmail account, and look at it with gmail's embedded viewer, none of the text is visible -- only graphic elements.
The workaround I reference a few posts up is not really a fix, because it basically looks up the glyphs for the font, and renders them as vector graphics. So your resulting pdf will look right, but it will contain graphics, not text. So for example copy/paste and search/spotlight would not work.
It is conceivable that it could be fixed by finding a C library for generating pdf's, and getting that to run on iPhone, and using that instead of the iPhone sdk pdf support. A few that have some promise are libharu, podofo, and libpdf. There may be others. If anybody does this, please let us know here.
Other than that, I think the only other real fix is to develop a corresponding web service with your app, and generate the pdf on your web server instead of in your app.
I have decided to go the route of the Sign Here app. See the "I'm Having Trouble Viewing PDF's" entry in their faq... FAQ | Sign Here by LexAlign
In other words, go ahead and use the iPhone sdk to generate an invalid pdf, and warn your users that they need to use Adobe Reader to see it.
Also, it would be great if everybody following this thread would file a bug report with Apple about this. The more people who report it, the more likely they are to fix it.
Thanks for that tip Panajev -- I can confirm that libharu works. Using that sample as a guide, I have just replaced Apple's buggy pdf code with libharu in my app, and submitted an update. This is my app... mRelease for iPhone, iPod touch, and iPad on the iTunes App Store
The current version generates pdf's where the text is invisible in gmail, and a couple users have reported garbled displays with Adobe Reader and Windows, even though in my testing it works fine (possibly has to do with what fonts are installed on the Windows machine?). In any case, when version 1.0.2 comes through, the problem will be resolved.
Libharu is a bit weird though. A couple things I ran into:
There is a function, HPDF_Page_TextRect, which is equivalent to the NSString drawInRect, which will take a very long string, and do the word wrapping into a box you specify. However, there is no equivalent to NSString's sizeWithFont to tell you how tall the resulting text ends up being. So it is difficult to determine where to place an item that has to go below the string.
This may force you to have to draw out your text line by line. There is a function HPDF_Page_MeasureText() which does make the manual word wrapping much simpler -- it tells you how many characters will fit in a given width, with word wrapping.
Another weird/annoying thing is that the image drawing functions use x, y, width, height, as you would expect, but the HPDF_Page_TextRect uses left, top, right, bottom for some reason.
Quote:
Originally Posted by Panajev
What about the libharu based PDF creator approach (some people mentioned a C based PDF creator approach)?
PDF Font Problem - can't get CIDs for glyphs
Linear Mode
