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@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
