[Fontconfig] fc-glyphname bug

[Keith Packard]

On Thu, 2007-03-08 at 02:16 -0500, James Cloos wrote:

> With only the dingbat names added in fcglyphlist, FC_GLYPHNAME_MAXLEN
> is 4, and passing 5 to FT_Get_Glyph_Name() causes a loop.

So FT_Get_Glyph_Name loops? Or we continue to call it with the same data
even though it returns an error?

> So, if FC_GLYPHNAME_MAXLEN is not to be enlarged, then
> FcFreeTypeGlyphNameIndex() needs to use a different constant.

FC_GLYPHNAME_MAXLEN is just used to allocate these static buffers; as we
cannot usefully use names which are not in the pre-computed tables, we
know that any name which cannot fit in the provided buffer cannot
possibly be found in the pre-computed tables. If FreeType has a bug, we
should first report it upstream and then provide a workaround

> The largest legal value it could need in a PostScript font is 127, so
> name_buf[128] should be a sufficient initialization.

And this seems like a fine work-around; as you can see, these buffers
are just allocated on the stack. Pushing the actual bug upstream to
FreeType should fix the root cause eventually.

> All of the glyph names in Standard Symbol L are in the glyphlist.txt
> file.  Can fc deal with a font with a non-standard encoding when it
> does not have a list of the unicode values of those glyph names?

Does Standard Symbol L also provide a regular encoding for the glyphs
that it uses? The list you provide looks a lot like the standard Adobe
encoding for text fonts. With your buffer size fix in place, does this
font start working?

> Is the answer to add just those 189 glyph names rather than all of the
> names in glyphlist.txt?

Certainly using a small subset of the glyph names would be preferred to
including all of them in the current data structure form. I would not be
averse to including all of them if we built a data structure that did
not use relocations though. fontconfig has several large tables which
have been carefully designed to eliminate relocations; another one would
not be a terrible plan.

> Adobe Symbol, as it was distributed in the linux version of acroread 5
> (where it was included as a type1 font), has all of the same glyphnames,
> except only that it lacks a Euro glyph which is in the URW version.

Does fontconfig not currently correctly construct the set of Unicode
code points supported by this font?

> The glyph names in GohaTibebZemen.otf (from xorg/font/misc-ethiopic)
> are completely non-standard.  It looks like the fonts from misc-meltho
> mostly follow the AGL, except they use a majuscule U rather than a
> miniscule uni as the prefix before the hex digits.  I'm guessing the
> ethiopic font was the one causing the segv.

Presumably as an otf file it also has regular unicode encoding tables
though; those are always preferred to glyph names.

> Some of the fonts designed by the TeX community use some non-standard
> glyph names.  Or at least have done so.  Since there is a movement
> towards using fontconfig to find fonts by TeX engines, that may be (or
> may become) a relevant issue.

Note that the only use of these glyph names by fontconfig is to
construct a map of available Unicode code points; applications simply
looking to locate fonts by name can use FreeType APIs as they choose to
find glyphs. Having fontconfig contain accurate information is helpful
when applications are looking to use fonts that they are unfamiliar
with.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070307/60d03f75/attachment.pgp