Demystifying “symbol” fonts

[Khaled Hosny]

On Thu, Nov 17, 2016 at 09:10:28PM +0000, Caolán McNamara wrote:
> 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.

OK, looks like the mystery is unfolding :) So IIUC, we are supposed to
remap the PUA. Indeed with https://gerrit.libreoffice.org/#/c/30932/ the
remapping happens even for the original bug document (U+F031 → U+0031).
However we insist on using OpenSymbol which does not have U+0031, and I
guess this is what the original commit was trying to fix.

So I think the problem here is that we are not doing any glyph fallback
for OpenSymbol. Looks like we skip glyph fallback for symbol fonts in
vcl/unx/generic/fontmanager/fontsubst.cxx
FcPreMatchSubstitution::FindFontSubstitute(), which makes sense generally,
except when you need it…

Regards,
Khaled