Re: Demystifying “symbol” fonts

On Thu, 2016-11-17 at 14:00 +0200, Khaled Hosny wrote:
> Hi all,
>
> I’m looking into bug 103944, which is mainly about handling so-called
> symbol fonts.
>
> The bullets in the bug document use the “Symbol” font from Windows,
> which has “symbol” cmap subtable that maps characters from Private
> Use Area to its own glyphs. Because the document uses PUA symbols,
> without this font installed or another font that has the exact same
> glyphs for PUA characters we can get anything from boxes to totally
> unrelated glyphs.
>
> Now, AFAIK, all glyphs in “Symbol” font have proper characters in
> Unicode (and the font itself supports them as well, in its non-symbol
> cmap subtable), so my question is what is the expected behaviour
> here, map the PUA to proper Unicode characters? Expect the font or a
> compatible one to be installed and usable? Bundle a compatible font?

So, IIRC, as an aside, Font::IsSymbolFont is set to true for a font
derived from the  SYMBOL_CHARSET/RTL_TEXTENODING_SYMBOL cases. So a
font like OpenSymbol is !IsSymbolFont, which is why there is code like
IsSymbolFont() || name == "OpenSymbol".

The standard font/glyph fallback stuff doesn't/shouldn't apply to
IsSymbolFont fonts generally, there's another piece of machinery built
around unotools/source/misc/fontcvt.cxx to map "well known" dingbat
fonts to and from unicode or pua opensymbol.

One place in vcl where we make use of this is
vcl/source/font/fontcache.cxx and search for ConvertChar::GetRecodeData
and its use of the ConvertChar class. We have one extra special case
for !IsSymbolFont for the "Symbol" font under Mac already.

My first instincts would be to poke around there and see if that's the
right place to fix it or not. i.e. let vcl use the unotools fontcvt
stuff to map the PUA to something we do have

It might even be that removing the #ifdef MACOSX line does something
useful.

C.