Running fc-glyphname with the glyphlist.txt as an argument fails.
A binary search shows that it is OK with up to 3615 glyph names in the
files specified as args, but fails as soon as there are 3616 glyph names.
When there are 3616 glyph names, hash is 4549 and rehash is 4547,
and the spin starts when i is 896 in the 1st insert at:
,----(fontconfig/fc-glyphname/fc-glyphname.c:main())
| for (i = 0; i < nraw; i++)
| {
| insert (raw[i], name_to_ucs, FcHashGlyphName (raw[i]->name));
| insert (raw[i], ucs_to_name, raw[i]->ucs);
| }
`----
Given that insert() does:
,----(fontconfig/fc-glyphname/fc-glyphname.c:insert())
| i = (int) (h % hash);
| while (table[i])
| {
| if (!r) r = (int) (h % rehash);
| i += r;
| if (i >= hash)
| i -= hash;
| }
| table[i] = gn;
`----
i starts looping rather than finding an empty slot at that point.
A quick printf shows that i hits 4541 and remains there.
When h is 18188, i is 4541 and r is 0, since 18188 is 4 * 4547.
For the hell of it, I tried adding an i++ just before the i+=r,
and this at least avoided the spin, although I presume it is
less than optimal.
Is this why glyphlist is not getting included in making fcglyphname.h?
Cf my next post for why this came up.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
On Wed, 2007-03-07 at 11:56 -0500, James Cloos wrote:> | if (!r) r = (int) (h % rehash);if (!r) { r = (int) (h % rehash); if (!r) r = 1; } should do the trick. (check out the matching hash function in fcfreetype.c)> Is this why glyphlist is not getting included in making fcglyphname.h?No, the full adobe glyph set has never been a part of fontconfig as I haven''t ever seen a need. Fontconfig only uses this table for fonts with adobe_custom encoding; the only ones I''ve seen like this are the decorative glyph fonts. Do you have a font which requires this data? -- keith.packard@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/07a339f3/attachment.pgp
Here is my propsed patch to fix the infinite loop and then to add
glyphlist.txt back into the generated fcglyphname.h.
It can be pulled (as two commits) from:
git://people.freedesktop.org/~cloos/fontconfig.git
(also via http://, ssh:// or ~cloos/fontconfig.git on annarchy.)
First:
,----
| commit 8b7624793de2b1a7ddf75fe338861495d694f68c
| Author: James Cloos <cloos@jhcloos.com>
| Date: Wed Mar 7 12:36:28 2007 -0500
|
| Prevent infinite loop
|
| fc-glyphname/fc-glyphname.c:insert() could
| enter an infinite loop if the 3rd arg was
| an integer multiple of rehash.
|
| Prevent the infinite loop by incrementing
| i by 1 in the while{} whenever r is 0.
|
| diff --git a/fc-glyphname/fc-glyphname.c b/fc-glyphname/fc-glyphname.c
| index faaa63b..a0e18e7 100644
| --- a/fc-glyphname/fc-glyphname.c
| +++ b/fc-glyphname/fc-glyphname.c
| @@ -207,7 +207,7 @@ insert (FcGlyphName *gn, FcGlyphName **table, FcChar32 h)
| while (table[i])
| {
| if (!r) r = (int) (h % rehash);
| - i += r;
| + i += r ? r : 1;
| if (i >= hash)
| i -= hash;
| }
`----
and then:
,----
| commit b63d40d0a1782dec43a8080d580a01d585e71aea
| Author: James Cloos <cloos@jhcloos.com>
| Date: Wed Mar 7 12:39:29 2007 -0500
|
| Include (Adobe) glyphlist.txt into generated fcglyphname.h
|
| Last commit fixed the infinite loop that prevented
| the inclusion of glyphlist.txt into the genereted
| fcglyphname.h file.
|
| So now include it.
|
| diff --git a/fc-glyphname/Makefile.am b/fc-glyphname/Makefile.am
| index 063ba00..709e11b 100644
| --- a/fc-glyphname/Makefile.am
| +++ b/fc-glyphname/Makefile.am
| @@ -38,8 +38,8 @@ noinst_HEADERS=$(TARG)
|
| noinst_MANS=fc-glyphname.man
|
| -GLYPHNAME=zapfdingbats.txt
| -SGLYPHNAME=${top_srcdir}/fc-glyphname/zapfdingbats.txt
| +GLYPHNAME=zapfdingbats.txt glyphlist.txt
| +SGLYPHNAME=${top_srcdir}/fc-glyphname/zapfdingbats.txt
${top_srcdir}/fc-glyphname/glyphlist.txt
|
| EXTRA_DIST=$(TMPL) $(GLYPHNAME)
|
|
|
`----
Together these get around the bug I was seeing with caching the urw
Symbol clone, by ensuring that FC_GLYPHNAME_MAXLEN is larger than
the length of the glyphnames in Standard Symbols L.
That said, should FC_GLYPHNAME_MAXLEN be only as long as the longest
name processed by fc-glyphname when fc is built? Or should it be long
enough to handle any valid PostScript glyph name? (Which is 127
according to the PLRM.)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
On Wed, 2007-03-07 at 13:13 -0500, James Cloos wrote:> Here is my propsed patch to fix the infinite loop and then to add > glyphlist.txt back into the generated fcglyphname.h.I''d rather not include all of glyphlist.txt in the fontconfig library, especially as each glyph adds a relocation to the library. Restructuring that data to avoid relocations would help, but I''m not sure I can see the need for all of those glyph names to be provided by the library.> Together these get around the bug I was seeing with caching the urw > Symbol clone, by ensuring that FC_GLYPHNAME_MAXLEN is larger than > the length of the glyphnames in Standard Symbols L.Is the urw symbol clone including a character which is not in the zapf character map and is in the larger map? Does Adobe publish a smaller map that includes all of the needed symbol glyphs and yet avoids the plain characters? Does the urw clone offer a Unicode map that can be used to look up the needed glyphs?> That said, should FC_GLYPHNAME_MAXLEN be only as long as the longest > name processed by fc-glyphname when fc is built? Or should it be long > enough to handle any valid PostScript glyph name? (Which is 127 > according to the PLRM.)It doesn''t need to be any longer -- the only use of this constant is in relation to the built-in list of glyph names, so names longer than this will never be useful. -- keith.packard@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/d116113b/attachment.pgp
>>>>> "Keith" == Keith Packard <keithp@keithp.com> writes:Keith> No, the full adobe glyph set has never been a part of Keith> fontconfig as I haven''t ever seen a need. Fontconfig only uses Keith> this table for fonts with adobe_custom encoding; the only ones Keith> I''ve seen like this are the decorative glyph fonts. Do you have Keith> a font which requires this data? I don''t know whether it requires the data, but URW''s Symbol will not cache when FC_GLYPHNAME_MAXLEN is too small for the font''s glyphnames. Including the agl pushes MAXLEN up to 39, whihc is long enough for that font. Another possible patch is to fix MAXLEN at 127. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
On Wed, 2007-03-07 at 14:54 -0500, James Cloos wrote:> >>>>> "Keith" == Keith Packard <keithp@keithp.com> writes: > > Keith> No, the full adobe glyph set has never been a part of > Keith> fontconfig as I haven''t ever seen a need. Fontconfig only uses > Keith> this table for fonts with adobe_custom encoding; the only ones > Keith> I''ve seen like this are the decorative glyph fonts. Do you have > Keith> a font which requires this data? > > I don''t know whether it requires the data, but URW''s Symbol will not > cache when FC_GLYPHNAME_MAXLEN is too small for the font''s glyphnames.That shouldn''t matter; can you explain where in the code the limit is causing a problem? As far as I know, the code compares font glyph names with those in the static table, so font glyph names longer than the largest pre-defined glyph name should not cause any problem. If that''s not true, we should just fix the code; it''s a bug that you are masking by adding piles of data to the library. -- keith.packard@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/e3362da5/attachment.pgp
>>>>> "Keith" == Keith Packard <keithp@keithp.com> writes:>> That said, should FC_GLYPHNAME_MAXLEN be only as long as the >> longest name processed by fc-glyphname when fc is built? Or should >> it be long enough to handle any valid PostScript glyph name? >> (Which is 127 according to the PLRM.)Keith> It doesn''t need to be any longer -- the only use of this Keith> constant is in relation to the built-in list of glyph names, so Keith> names longer than this will never be useful. It gets used by fcfreetype.c in FcFreeTypeCharSetAndSpacing(), which is being called by fc-cache(1) when hitting s050000l.pfb. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Another two font families which may cause fc-cache to fail (this time with a segv) but work with the changes I suggested are those in: git://anongit.freedesktop.org/xorg/font/misc-ethiopic git://anongit.freedesktop.org/xorg/font/misc-meltho More precisely, gentoo sticks both of those in /usr/share/fonts/OTF (and only those) and one or more of the fonts therein caused the SEGV. With the change to FC_GLYPHNAME_MAXLEN and the full set of glyphnames that dir now caches correctly, again. I presume this is due to some change in freetype, since it all of course used to work. But now if fc tries to get the glyph names from a font and specifies a max lenght too short it either dies or goes into an infinite loop, and since it uses FC_GLYPHNAME_MAXLEN as the max length in that function call, either that needs to be large enough to cover any glyph name or another constant is needed for use in FcFreeTypeCharSetAndSpacing(). -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
>>>>> "Keith" == Keith Packard <keithp@keithp.com> writes:Keith> If that''s not true, we should just fix the code; it''s a bug Keith> that you are masking by adding piles of data to the library. Understood. I was quite exhausted by the time I debugged it enough to have any idea of why it was looping. Anyway, in fontconfig/src/fcfreetype.c in a section within: #if HAVE_FT_HAS_PS_GLYPH_NAMES #endif has the function static FT_UInt FcFreeTypeGlyphNameIndex (FT_Face face, const FcChar8 *name) { FT_UInt gindex; FcChar8 name_buf[FC_GLYPHNAME_MAXLEN + 2]; for (gindex = 0; gindex < (FT_UInt) face->num_glyphs; gindex++) { if (FT_Get_Glyph_Name (face, gindex, name_buf, FC_GLYPHNAME_MAXLEN+1) == 0) if (!strcmp ((char *) name, (char *) name_buf)) return gindex; } return 0; } That gets triggered by urw''s Standard Symbol L, and FT_Get_Glyph_Name() needs its last arg to be large enough to handle all of the glyph names in the font. 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, if FC_GLYPHNAME_MAXLEN is not to be enlarged, then FcFreeTypeGlyphNameIndex() needs to use a different constant. The largest legal value it could need in a PostScript font is 127, so name_buf[128] should be a sufficient initialization. At least for PostScript-legal fonts. :-/ 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? Is the answer to add just those 189 glyph names rather than all of the names in glyphlist.txt? 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. 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. 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. I can''t think of any other fonts that may trigger this. Here are the 189 glyph names (other that .notdef) found in URW''s Standard Symbol L, grep(1)ed out of glyphlist.txt: space;0020 exclam;0021 universal;2200 numbersign;0023 existential;2203 percent;0025 ampersand;0026 suchthat;220B parenleft;0028 parenright;0029 asteriskmath;2217 plus;002B comma;002C minus;2212 period;002E slash;002F zero;0030 one;0031 two;0032 three;0033 four;0034 five;0035 six;0036 seven;0037 eight;0038 nine;0039 colon;003A semicolon;003B less;003C equal;003D greater;003E question;003F congruent;2245 Alpha;0391 Beta;0392 Chi;03A7 Delta;2206 Epsilon;0395 Phi;03A6 Gamma;0393 Eta;0397 Iota;0399 theta1;03D1 Kappa;039A Lambda;039B Mu;039C Nu;039D Omicron;039F Pi;03A0 Theta;0398 Rho;03A1 Sigma;03A3 Tau;03A4 Upsilon;03A5 sigma1;03C2 Omega;2126 Xi;039E Psi;03A8 Zeta;0396 bracketleft;005B therefore;2234 bracketright;005D perpendicular;22A5 underscore;005F radicalex;F8E5 alpha;03B1 beta;03B2 chi;03C7 delta;03B4 epsilon;03B5 phi;03C6 gamma;03B3 eta;03B7 iota;03B9 phi1;03D5 kappa;03BA lambda;03BB mu;00B5 nu;03BD omicron;03BF pi;03C0 theta;03B8 rho;03C1 sigma;03C3 tau;03C4 upsilon;03C5 omega1;03D6 omega;03C9 xi;03BE psi;03C8 zeta;03B6 braceleft;007B bar;007C braceright;007D similar;223C Upsilon1;03D2 Euro;20AC minute;2032 lessequal;2264 fraction;2044 infinity;221E florin;0192 club;2663 diamond;2666 heart;2665 spade;2660 arrowboth;2194 arrowleft;2190 arrowup;2191 arrowright;2192 arrowdown;2193 degree;00B0 plusminus;00B1 second;2033 greaterequal;2265 multiply;00D7 proportional;221D partialdiff;2202 bullet;2022 divide;00F7 notequal;2260 equivalence;2261 approxequal;2248 ellipsis;2026 arrowvertex;F8E6 arrowhorizex;F8E7 carriagereturn;21B5 aleph;2135 Ifraktur;2111 Rfraktur;211C weierstrass;2118 circlemultiply;2297 circleplus;2295 emptyset;2205 intersection;2229 union;222A propersuperset;2283 reflexsuperset;2287 notsubset;2284 propersubset;2282 reflexsubset;2286 element;2208 notelement;2209 angle;2220 gradient;2207 registerserif;F6DA copyrightserif;F6D9 trademarkserif;F6DB product;220F radical;221A dotmath;22C5 logicalnot;00AC logicaland;2227 logicalor;2228 arrowdblboth;21D4 arrowdblleft;21D0 arrowdblup;21D1 arrowdblright;21D2 arrowdbldown;21D3 lozenge;25CA angleleft;2329 registersans;F8E8 copyrightsans;F8E9 trademarksans;F8EA summation;2211 parenlefttp;F8EB parenleftex;F8EC parenleftbt;F8ED bracketlefttp;F8EE bracketleftex;F8EF bracketleftbt;F8F0 bracelefttp;F8F1 braceleftmid;F8F2 braceleftbt;F8F3 braceex;F8F4 angleright;232A integral;222B integraltp;2320 integralex;F8F5 integralbt;2321 parenrighttp;F8F6 parenrightex;F8F7 parenrightbt;F8F8 bracketrighttp;F8F9 bracketrightex;F8FA bracketrightbt;F8FB bracerighttp;F8FC bracerightmid;F8FD bracerightbt;F8FE -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
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@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
>>>>> "Keith" == Keith Packard <keithp@keithp.com> writes:>> With only the dingbat names added in fcglyphlist, >> FC_GLYPHNAME_MAXLEN is 4, and passing 5 to FT_Get_Glyph_Name() >> causes a loop.Keith> So FT_Get_Glyph_Name loops? Or we continue to call it with the Keith> same data even though it returns an error? I was so exhausted this afternoon, that after a good day''s sleep everything has run together and is a bit foggy. But after reviewing the long post (crossed to freetype-devel), fc calls FT_Get_Glyph_Name in a loop with glyph_index (the 2nd arg) having values of: 0, 1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3, ... With the buffer long enough to load all of the glyph names it instead increments from 0 to face->num_glyphs as expected. This happens in FcFreeTypeCharSetAndSpacing(). When FT_Get_Glyph_Name fails it returns (FT_Error) 6. I think I might see the problem. ft_mem_strcpyn() looks like this: ,----(freetype2/src/base/ftutil.c) | FT_BASE_DEF( FT_Int ) | ft_mem_strcpyn( char* dst, | const char* src, | FT_ULong size ) | { | while ( size > 1 && *src != 0 ) | *dst++ = *src++; | | *dst = 0; /* always zero-terminate */ | | return *src != 0; | } `---- Unless I''m missing something, the copy is not limited to size octets, yes? That probably writes over the value in FcFreeTypeCharSetAndSpacing()''s glyph variable, if name_buf[] happens to be allocated just before it. I bet that is what causes the loop. Ensuring that the buffer is longer than the glyph names ensures that ft_mem_strcpyn() cannot overstep and therefore avoids the loop. I''ll post that bit to freetype-dev.>> The largest legal value [FC_GLYPHNAME_MAXLEN] could need in a >> PostScript font is 127, so name_buf[128] should be a sufficient >> initialization.Keith> And this seems like a fine work-around; as you can see, these Keith> buffers are just allocated on the stack. Pushing the actual bug Keith> upstream to FreeType should fix the root cause eventually. In that case, I presume something like: diff --git a/fc-glyphname/fc-glyphname.c b/fc-glyphname/fc-glyphname.c index a0e18e7..c2db931 100644 --- a/fc-glyphname/fc-glyphname.c +++ b/fc-glyphname/fc-glyphname.c @@ -282,7 +282,7 @@ main (int argc, char **argv) printf ("#define FC_GLYPHNAME_HASH %u\n", hash); printf ("#define FC_GLYPHNAME_REHASH %u\n", rehash); - printf ("#define FC_GLYPHNAME_MAXLEN %d\n\n", max_name_len); + printf ("#define FC_GLYPHNAME_MAXLEN 127\n\n"); /* * Dump out entries as well as the version you posted to keep i+=r from being constant in fc-glyphname.c:insert() would be enough to avoid the bug until ft is fixed to honour the size arg to ft_mem_strcpyn()? Keith> Does Standard Symbol L also provide a regular encoding for the Keith> glyphs that it uses? The list you provide looks a lot like the Keith> standard Adobe encoding for text fonts. With your buffer size Keith> fix in place, does this font start working? It isn''t the text encoding. Symbol encoding gets its own table in the PLRM (even back to the original Red Book). URW''s version just adds Euro encoded at 0x80. I currently have fc installed with the two patches I posted, so it has the full glyphlist table. With that version, xfd(1x) shows the glyphs in their unicode codepoints for Standard Symbol L, just like it does for ITC Zapf Dingbats. The same holds for Symbol:foundry=adobe. That does seem like the right thing to do, yes?>> Is the answer to add just those 189 glyph names rather than all of >> the names in glyphlist.txt?Keith> Certainly using a small subset of the glyph names would be Keith> preferred to including all of them in the current data Keith> structure form. The list I posted last is exactly the glyph names needed, using the code points in the glyphlist.txt file in fc-glyphname. But I think some of those are outdated. The glyphs put in 0xF8XX: radicalex;F8E5 arrowvertex;F8E6 arrowhorizex;F8E7 registersans;F8E8 copyrightsans;F8E9 trademarksans;F8EA parenlefttp;F8EB parenleftex;F8EC parenleftbt;F8ED bracketlefttp;F8EE bracketleftex;F8EF bracketleftbt;F8F0 bracelefttp;F8F1 braceleftmid;F8F2 braceleftbt;F8F3 braceex;F8F4 integralex;F8F5 parenrighttp;F8F6 parenrightex;F8F7 parenrightbt;F8F8 bracketrighttp;F8F9 bracketrightex;F8FA bracketrightbt;F8FB bracerighttp;F8FC bracerightmid;F8FD bracerightbt;F8FE now have codepoints in 10646. At least these changes are needed: arrowvertex;23D0 arrowhorizex;23AF parenlefttp;239B parenleftex;239C parenleftbt;239D bracketlefttp;23A1 bracketleftex;23A2 bracketleftbt;23A3 bracelefttp;23A7 braceleftmid;23A8 braceleftbt;23A9 braceex;23AA integralex;23AE parenrighttp;239E parenrightex;239F parenrightbt;23A0 bracketrighttp;23A4 bracketrightex;23A5 bracketrightbt;23A6 bracerighttp;23AB bracerightmid;23AC bracerightbt;23AD My understanding is that Adobe put apple, radicalext and the .serif versions (rather than the sans) of the copyright, trademark and registered glyphs in the PUA in SymbolStd.otf. Also arrowvertex, even though that is what U+23D0 is defined to be. With these entries added to fc-glyphname''s loaded table the type1 versions of the fonts should show up just like the otf does. Keith> I would not be averse to including all of them Keith> if we built a data structure that did not use relocations Keith> though. fontconfig has several large tables which have been Keith> carefully designed to eliminate relocations; another one would Keith> not be a terrible plan. That is one programming exercise I''ve not tried.>> Adobe SymbolKeith> Does fontconfig not currently correctly construct the set of Keith> Unicode code points supported by this font? I don''t know. I only have the one box to test on, and I''d like to avoid backtracking to find out. It should be exactly the same as for Standard Symbol L, though, so what do you get from: xfd -fa ''Standard Symbol L'' More than 38 glyphs on the first page? Are the greek letters in the 0300 page? If yes+no, then it does not get the code points correct w/o additions to fcglyphname.h. -JimC