Hubert Figuière wrote on Mon, 30 Jul 2012 14:34:06 -0700:
>> A better solution to solve bug 12334 (wrong bullet symbols in bullet
>> lists) would be to stop using the dingbats and symbol fonts to
>> represent bullets, use instead standard unicode code points
> I definitely prefer that solution.
After a long time of confusion I've finally got why there are these Symbol /
Standard Symbols L / Dingbats issues.
It is a mess!
You'd need the Adobe (Type 1) fonts which are named (nowadays?) "Standard
Symbols L" and "Dingbats". So without some fontconfig intervention there is
no font "Symbol" on your system, and font "Dingbats" misses two glyphs (the
square and the star), so it doesn't really help to install these.
The best thing to do for "Dingbats" is a fontconfig mapping onto an
appropriate Unicode font. That's the easier part and no big deal (and
probably why Hub has all 11 glyphs).
The harder part is "Symbol", because there is a Windows TTF font named
"Symbol" (incompatible with Adobe Symbol, of course). If you happen to have
this one on your system, you're kinda screwed (and that's the reason for
option with-standard-symbols-l).
Ok now, why not being clever and renaming TTF "Symbol" like "Symbol MS" (and
"Standard Symbols L" "Symbol" then - yikes)? Well, there is ugly "Symbol"
detection in gr_CairoGraphics.cpp. It does strstr(, "symbol") and has a
hardcoded list of exceptions: "starsymbol", "opensymbol" and "symbolnerve"
where our "symbol ms" had to go, too, then. Yikes!
So it seems to me that option with-standard-symbols-l isn't that a bad idea
for systems having both TTF "Symbol" and Adobe Standard Symbols L. The
description should be updated ("use font family 'Standard Symbols L' instead
'Symbol' for list bullets" - which is what it finally really does by the way)
and we need an additional #ifdef in gr_CairoGraphics.cpp for the strstr(). We
could define a symbolic constant like FONT_FAMILY_FOR_BULLETS to avoid the
#ifdefs.
With Adobe Dingbats and without fontconfig mapping even direct Unicode points
won't help, because the coding (to unicode) is fine. The glyphs are the
problem.
Ingo
Received on Tue Jul 31 14:08:13 2012
This archive was generated by hypermail 2.1.8 : Tue Jul 31 2012 - 14:08:13 CEST