Bug 101889 - Using OpenSymbol font with proper codepage in Linux
Summary: Using OpenSymbol font with proper codepage in Linux
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:5.3.0
Depends on: 99402
  Show dependency treegraph
Reported: 2016-09-04 06:18 UTC by Aron Budea
Modified: 2022-08-22 23:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2016-09-04 06:18:39 UTC
Mike Kaganski pointed out in bug 99402 that the symbol font handling in Linux wasn't done properly in the first place:

"The Symbol font that is shipped with Windows (and is used in WMFs) has Symbol charset (see https://www.microsoft.com/typography/fonts/font.aspx?FMID=1650). OpenSymbol, on the other side, only has 1252 Latin-1 charset in it.

Fixing the original Linux problem by forcing Win1252 codepage everywhere seems to work, even under Windows (at least my Win10 shows it well; seems that Windows somehow makes internal recoding here). But I'm not sure if that's a correct solution. IMO, more correct solution would be adding the Symbol charset to OpenSymbol font itself."
(see full comment at [1])

Currently empty rectangles are displayed instead of brackets in mathtype formulas.

"Under Linux, after the regression is fixed, the attacment 124514 from comment 0 shows two problems: one with brackets, and another one with "h" with stroke in second line in h^2/2m. Both problems are caused by absent fonts: brackets - from Symbol; stroked h - from MT Extra. Symbol font is mapped to OpenSymbol under Linux. (I only mention MT Extra here for completeness/reference; it's out of scope here.)"
(also from [1], attachment is [2])

Setting to NEW, as this is a confirmed issue.

Behavior can be fully seen with 5.3 master builds that include this commit (but some brackets were already wrong before the regression in bug 99402 was introduced):

tdf#99402: fix Metafile Font handling

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=99402#c18
[2] https://bugs.documentfoundation.org/attachment.cgi?id=124514
Comment 1 Aron Budea 2016-09-04 06:21:03 UTC
Mike, thanks for your analysis in bug 99402, here's the new bug report as requested. Please adjust component if a different one is more suitable.
Comment 2 Mike Kaganski 2016-09-04 07:07:40 UTC
This problem is described as #6 in bug 39256.
As that bug looks more like a meta-bug for tracking WMF-related problems, I add it as "See Also" and will work on it here.

Further analysis shows that my previous statements need correction.
1. Always using 1252 doesn't work for Windows; I must had been dreaming when wrote that it worked under Win10. So, the only way to fix this by selecting encoding is conditional compilation (symbol charset for Windows, 1252 for Linux).
2. OpenSymbol doesn't contain necessary glyphs for brackets/braces/parentheses. Standard Symbols L actually does. When Symbol font encoding is set to 1252, Standard Symbols L is used by LO, while for symbol encoding, OpenSymbol is used, with recoding using utilities from unotools/source/misc/fontcvt.cxx. I see preferable way to fix this by enabling LO to substitute Standard Symbols L for Symbol font when symbol charset is used.
3. MT Extra problem mentioned above (and in bug 39256 #6) is fixed by using symbol encoding, works both for Windows and Linux (MacOS isn't tested).
Comment 3 Mike Kaganski 2016-09-04 12:13:47 UTC
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.
Comment 4 Mike Kaganski 2016-09-06 04:04:00 UTC
Posted a patch to gerrit: https://gerrit.libreoffice.org/28677

I managed to avoid using external fonts as source of absent glyphs, using and modifying OpenSymbol's own glyphs.
Comment 5 Commit Notification 2016-09-12 15:38:18 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


tdf#101889: add absent brackets to OpenSymbol

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 6 V Stuart Foote 2016-09-12 16:51:51 UTC
@Mike, Khaled * 

So, just a thought here--not sure of the feasibility, or the work involved.

Could the scope of OpenSymbol be expanded, its encoding & format adjusted if needed--or a new font spun off to replace it in LibreOffice--that covers more of the Unicode SMP--including the BMP & SMP codepoints for Emoji that we have defined notation for use? And in process maybe expand glyph coverage for musical and mathematics notation.

With so many glyphs enabled now in the GUI we are missing coverage in a project deployed font--could some set of glyphs from Unicode be added to OpenSymbol to cover the glyphs we are defining as Emoji input in the autocorrect tables?

Similar issue in that OpenSymbol is hard coded for use in Math, but misses large chunks of otherwise useful glyphs for formula composition.

Also missing are most of the coverage BMP & SMP for musical symbols. Seems like they all would be well served with a reworked OpenSymbol font.
Comment 7 Mike Kaganski 2016-09-12 17:05:54 UTC
(In reply to V Stuart Foote from comment #6)
> Could the scope of OpenSymbol be expanded, its encoding & format adjusted if
> needed--or a new font spun off to replace it in LibreOffice--that covers
> more of the Unicode SMP--including the BMP & SMP codepoints for Emoji that
> we have defined notation for use? And in process maybe expand glyph coverage
> for musical and mathematics notation.

IMO, the OpenSymbol is a good place to all that stuff, but... that's a (font) designer's work. If someone volunteers for that, that would be great.
Comment 8 Khaled Hosny (خالد حسني) 2016-09-13 08:15:44 UTC
I’d not added any new characters to OpenSymbol unless we really have to, I actually think we should move characters from OpenSymbol (e.g. math, but this require bigger changes in Math) and keep it strictly for bullets and other similar things.

If we really need to bundle and emoji font, we can just use one of the existing freely licensed emoji fonts.
Comment 9 Xisco Faulí 2017-07-13 10:25:31 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 10 QA Administrators 2018-07-14 02:45:11 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2020-07-14 04:02:58 UTC Comment hidden (obsolete)
Comment 12 V Stuart Foote 2020-11-08 15:51:25 UTC
remains an issue