>>>>> "Martin" == <msevior@xxxxxxxxxxxxxxxxxxxxxx> writes: Martin> I gather from the lack of response to my question Martin> about Adobe Dingbat fonts that their non-usefulness in Martin> FreeType is a known bug that no one knows how to fix. I just gave it a quick test. ftview has no problem with either Adobe's ITC Zapf Dingbats or URW++'s Dingbats. Xft, OTOH, only displays the space glyph as setup on any box I could test on. Perhaps this should move to fontconfig@xxxxxxxxxxxxxxx If you look at the atms, Zapf Dingbats uses a fontspecific enconding array; the glyph names are of the form aN, where N is an integer. N is not a linear function of the glyph's position in the encoding array. Unicode has set aside a block for the Zapf Dingbats characters¹ (presumably to enable lossless round-trip conversions) and fontconfig or Xft probably needs to special-case Zapf Dingbats and map that block to the glyph names in the t1 versions. As a side note, I expect but cannot prove -- w/o shelling out some cash -- that the otf version of ITC Zapf Dingbats Adobe now ships will work, as it most likely has a cmap pointing the Unicode block at its glyphs. As a test, I've munged the urw version into an otf and uploaded it to: http://cloos.sixbit.org/fonts/dingbat/ It is named DingbatOTF to make it easy to confirm which font is being used. Like the urw font I derived it from, it is of course licensed under the GPL. My quick testing with xfd was successful. The sfd is also at that URL, so feel free to improve it.... -JimC ¹ But note that 13 of the characters in that block are reserved -- they are encoded elsewhere. 4 more characters in that block are reserved because there are no associated glyphs in ZD's vector.
