With the latest poppler and evince, given a form such as http://www.irs.gov/pub/irs-pdf/f1040.pdf, I don't see checks in the checkboxes when I click them. But it works fine for Carlos, and I'm not sure why. I'm on Fedora 8. I have the Zapf Dingbats -> Dingbats alias in fontconfig, although it doesn't seem to be relevant. Stepping through the code, the Gfx8BitFont constructor in poppler/GfxFont.cc gets called, finds that ZapfDingbats *is* a builtin font (line 522), sets baseEnc to the defaultBaseEnc from the builtinFont (line 690), and initializes enc from that (which is to say, from zapfDingbatsEncoding in poppler/FontEncodingTables.cc). But then, when it gets to the "build the mapping to Unicode" step, the globalParams->mapNameToUnicode(charName) call (line 763) fails for every character in zapfDingbatsEncoding except "space". So then "pass 2" (lines 794-821) interprets the Zapf Dingbats dummy character names (eg, "a20" for the checkmark) as being hexadecimal, and initializes toUnicode accordingly. So the char code -> Unicode mapping ends up completely wrong (except for space), and as a result, when it tries to render the check later, it ends up drawing nothing. If I add the line {0x2714, "a20"}, to nameToUnicodeTab in NameToUnicodeTable.h, then everything works. (Well, at least for that one character, presumably you'd want to add mappings for all of the other Zapf Dingbats characters too.) As I said, the code apparently works as-is for Carlos, so I'm not sure what's going wrong on my machine...
Created attachment 12392 [details] Screensot I don't know why but it works for me. This is an screenshot of poppler git + evince svn trunk.
What versions of freetype are you both using?
freetype-2.3.5-3.fc8
I'm having what looks like a similar problem, freetype-2.3.7, fontconfig-2.6.0, and the solution I eventually tried for my PDF file was to create /etc/fonts/conf.d/31-myaliases.conf like this: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias binding="same"> <family>ZapfDingbats</family> <accept><family>Dingbats</family></accept> </alias> </fontconfig> Suddenly, okular showed everything right. (Oddly, it printed ok without this change.) Note that 30-urw-aliases.conf has almost the same entry, but with a space between "Zapf" and "Dingbats". Not sure - perhaps the code should be space-agnostic?
Created attachment 57208 [details] [review] add zapf dingbats unicode to glyph mappings The bug occurs when the Zapf Dingbats substitute font is a truetype font. When substituting a truetype font GfxFont needs to know the unicode values of the font encoding to be able to correctly map the encoding the glyphs in the substitute font. The attached patch adds the Zapf glyph names to unicode mapping based on the mapping at ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/zdingbat.txt The pdf file in this bug also has the same problem: The https://bugzilla.gnome.org/show_bug.cgi?id=654797 Note that pdffonts does not show the non embedded Zapf Dingbats fonts in f1040.pdf because FontInfoScanner is is not recursing into Form objects in the annotations.
Adrian which ttf font do i need in my system to test this patch?
(In reply to comment #6) > Adrian which ttf font do i need in my system to test this patch? On my system ZapfDingbats maps to one of the gs type 1 fonts. If I do: cd /usr/share/fonts mv type1 .type1 then ZapfDingbats maps to DejaVu Sans and the bug can be reproduced.
I'd prefer if you did not put the ZapfDingbats comment in there since that is not ZapfDingbats specific but falls in the general "Adobe character name" spec it seems. Also please follow the alphabetical sorting of the list (i.e. add it after the entry for {0x0061, "a"},. And then commit :-)
Actually, please do not commit, i'm updating the list from the adobe updated specification list
Commited!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.