https://bugs.documentfoundation.org/show_bug.cgi?id=101889
--- Comment #3 from Mike Kaganski <mikekagan...@hotmail.com> ---
It's not that straightforward to fix the font substitution.
The actual used font is selected in ImplFontCache::GetFontInstance() and
PhysicalFontCollection::FindFontFamily(). The latter performs several steps,
and on my system, it finds OpenSymbol as Symbol's replacement at
rFontSubst.getSubstInfo( aSearchName ). There, it searches for exact match of
searched name in sorted list. If it wouldn't find OpenSymbol here, e.g. by
explicit break for Symbol search, then PhysicalFontCollection::FindFontFamily()
will use next method: for symbol fonts, it uses LO configuration
org.openoffice.VCL:LocalizedDefaultFonts['lang'].SYMBOL, that is a list of
fonts: on my system, it is StarSymbol;OpenSymbol;Arial Unicode MS;StarBats;Zapf
Dingbats;WingDings;Symbol. If I add e.g. Standard Symbols L to the head of the
list, then "it works".
To fix it properly, I think, two things are necessary:
1. To update OpenSymbol (that is LO native font, and so it must support the
necessary glyphs itself, instead of hoping that some system font will happen to
have those). I wonder if just copying those glyphs from Standard Symbols L is
OK? According to https://en.wikipedia.org/wiki/Ghostscript, the font is either
GPL or AFPL.
2. The first step alone if not a proper fix: if user installs a font with a
name that will intercept the search in the above-mentioned algorithm, then
OpenSymbol won't be selected. So, some hardcoding may be necessary.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
