[Fontconfig] Re: [Devel] Adobe Dingbat Fonts - do they work at all in FreeType?

James H. Cloos Jr. fontconfig@fontconfig.org
03 May 2003 10:04:13 -0400


>>>>> "Martin" ==   <msevior@physics.unimelb.edu.au> 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@fontconfig.org.

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.