Current the Math Formula Editor is hard coded to use OpenSymbol  and assigned variables FONTNAME_MATH and then as FNTNAME_MATH  and used as FNT_MATH 
There are a number of high quality font faces that have complete coverage of the Greek and Character Like symbols that the formula editor makes use in its specialized Symbols catalog, e.g. Cambria Math, Asana Math, STIX, etc. Any of which might be preferred by users as functional replacements to the bundled OpenSymbol font.
Suggest an ability in Expert Configuration dialog to change the font assigned to FONTNAME_MATH, or used as FNT_MATH would be useful. It might be grouped with the other org.openoffice.Office.Math StandardFormat stanzas.
This would be as an alternative to the general Tools -> Options -> Fonts: Replacement Table GUI where the replacement is global for all use of a font, OpenSymbol in this case. And if it proves popular, the ability to change the default font could later be added to the GUI settings panel for Math.
Definitions for the other Greek symbols %alpha... %gamma in the Formula Editor symbol catalog look to be defined in:
Glyphs refered to by decimal equivs of their Unicode codepoints, but since the .XCU has a hardcoded OpenSymbol font Name attribute set it may impact ability to have a simple attribute change set from Expert Configuration.
Just changing the font is not enough, may symbols are hardcoded to use PUA code points from OpenSymbol, so changing the font will give you garbage. This needs to be fixed first.
OK, so IIUC use of the font replacement table work because the glyph has already been selected and then the replacement can proceed?
Should the OpenSymbol font be reworked to eliminate any direct use of the PUA defined glyphs?
I'm not sure it's possible. To have correct display, glyph's size should be specifically chosen to be usable stretched, stacked etc. Also, we stretch characters where they should be composed of a number of parts to display OK (braces/parens, etc) - now stretching makes glyphs thin etc. Fixing this requires changing current composition of glyphs. And if we go this route, then substitute should have these glyph parts available at the same codepoints as well.
Sure, and bug 32362 suggests the formula editor must go this direction.
but doesn't all of this require we have the U+239B -> U+23B7 glyphs available to use? Not yet the case in OpenSymbol, but common in other symbol fonts.
Seems like we should dump any hard coded use of OpenSymbol's PUA glyphs, and use Unicode near term in preparation.
And once we move to using the appropriate Unicode glyps, doing proper OpenType Math table shaping seems advisable as in bug 103680.
Problem of the PUA assignment aside, an effort here to provide UI to be able to change the default font seems reasonable, and would survive any refactoring of the sm math internals.
My comment would be that it's essential that we be able to change the font of our formula, independent of this immediate issue with the font metrics of OpenSymbol. Agree with Stuart's comments about the need to move away from any/all hard-coded dependencies on a particular font. But in the interim -- switch to a well-behaved font instead!!
*** Bug 67152 has been marked as a duplicate of this bug. ***
*** Bug 111700 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #5)
> Seems like we should dump any hard coded use of OpenSymbol's PUA glyphs, and
> use Unicode near term in preparation.
I suggest we can replace such hard coded PUA code points to Unicode equivalences firstly, and then create a converter to replace them when LO imported a formulae including such glyphs.
*** Bug 127414 has been marked as a duplicate of this bug. ***
*** Bug 127553 has been marked as a duplicate of this bug. ***
*** Bug 133597 has been marked as a duplicate of this bug. ***
I'm working on this matter. Adding utf32 support for starmath in order to be able to solve a lot of requests. Changing opensymbol is hardcore because it'a a #define where the name is written, but should be possible. Anyway, I would say it's important to be able to get rid of it. Symbols witch are not in opensymbol are not correctly rendered on math. This affects for example resolution of tdf#49990 for example. Would try to use STIX2 or other mentioned by V Stuart Foote before falling onto OpenSymbol.
(In reply to dante19031999 from comment #14)
> I'm working on this matter. Adding utf32 support for starmath in order to be
> able to solve a lot of requests.
@Dante, great to have you hacking at this. As Mike K. and Kahaled point out there is a lot of the PUA mappings in StarSymbol/OpenSymbol that is hard coded into the sm module for composing the sm nodes. Those mappings will need to be reworked to use the Unicode (BMP & SMP) directly.
Assigning specific font as here is less of an issue--though would be nice--as os/DE fallback should protect most usage.
(In reply to V Stuart Foote from comment #15)
> Assigning specific font as here is less of an issue--though would be
> nice--as os/DE fallback should protect most usage.
If I understand this as "having a fallback is not important" (which I may easily misunderstand, sorry), then that's very wrong. I would love to see this fixed; but for Math, the symbols are the crucial part, and not having a font to provide them on a system would make Math broken. So - any fix to this should make sure that we provide a font (I suggest to keep OpenSymbol for that) with the full repertoire of glyphs for Math. Currently we bundle it in all TDF packages, and have it in a special directory in installdir, where it is taken from if not installed in OS. That should remain. Also, the glyphs that are not in some PUA positions should still be available there in OpenSymbol, and also on proper Unicode positions: to allow users to have old documents that use that font for any different purpose (e.g., they could had inserted symbols as bullets in Writer).
(In reply to Mike Kaganski from comment #16)
> Also, the glyphs that are not in some PUA positions should still be available there
Sorry, a thinko. Should have been:
Also, the glyphs that are in some PUA positions should still be available there
(In reply to Mike Kaganski from comment #16)
> If I understand this as "having a fallback is not important" (which I may
> easily misunderstand, sorry), then that's very wrong.
Unfortunately you did (but then I was not clear). What I meant was that a shift to fully Unicode based composition of sm nodes--system provided font fallback should protect against missing coverage in any font selected for formula editor use.
The PUA mappings need to be eliminated. For example, bug 131160#c3 and bug 108697
(In reply to V Stuart Foote from comment #18)
> (In reply to Mike Kaganski from comment #16)
> > If I understand this as "having a fallback is not important" (which I may
> > easily misunderstand, sorry), then that's very wrong.
> Unfortunately you did (but then I was not clear).
Sorry for that; still I think that comment 16 has important things to consider regardless.
> The PUA mappings need to be eliminated. For example, bug 131160#c3 and bug
And what happens then with existing documents using those codepoints? We must not break them.
(In reply to Mike Kaganski from comment #19)
> > The PUA mappings need to be eliminated. For example, bug 131160#c3 and bug
> > 108697
> And what happens then with existing documents using those codepoints? We
> must not break them.
I guess, and two major ones would be default quick select Bullets:
Current PUA -> Unicode
E00C -> U+25C6 BLACK DIAMOND
E00A -> U+25A0 BLACK SQUARE
But while those could be mapped onto their correct Unicode--they and others in common use could be kept also at their PUA assignment. There already are dozens that are duplicated.
On the other hand, since OpenSymbol *really* needs a major clean up to bring its mappings current with Unicode version 13, the STIX2 Math font could instead be the better font to distribute--if the residual PUA and linkage to StarSymbol/OpenSymbol could be redirected, and the font metrics for STIX2 accommodated in the sm node logic and any other locations in the UI.
On one side we have the legacy--but unsupported OpenSymbol needing font design work. On the other multiple license appropriate font projects offering well maintained symbol coverage fonts.
I think we can cobble together the few glyphs Dante needs to round out OpenSymbol (or even agressively expand its coverage) but are we really best served by that?
(In reply to V Stuart Foote from comment #20)
> I think we can cobble together the few glyphs Dante needs to round out
> OpenSymbol (or even agressively expand its coverage) but are we really best
> served by that?
Yes. We have to provide backward compatibility. Which means that even if we decide to use another well-maintained font, we still must provide the old font for use in existing documents (which must definitely *not* change their look after this change, even to something that you, me, or anybody else considers a better-looking alternative). Which in turn means we must make this old font to work with new code that expects to find some things in new places; which means that we have to fix it ... which means that deciding to use another font does not allow us to avoid any burden, only would add (a little (?)) to that burden.
(In reply to Mike Kaganski from comment #21)
> Yes. We have to provide backward compatibility. ...
Found some of that ugliness just now looking at bug 47679 and the StarSymbol/OpenSymbol PUA mapping tables .