Looks like currently, libreoffice supports the formatting of mathematical expression by means of an equation editor that is based on "regular" fonts. Recently, OTF fonts including a "math" table have been introduced to improve the typesetting of mathematical expressions. They are used in Microsoft products (typically deploying Cambria Math as the font), but also LaTeX can take advantage of them. Recently a relatively large number of open licensed math fonts has appeared (e.g. see https://tex.stackexchange.com/questions/425098/which-opentype-math-fonts-are-available). Would be great to see this modern math typesetting technology incorporated in LibO: - for better consistency of the math typesetting wrt other tools - possibly favoring the introduction of "inline" math expressions in impress (that is badly needed).
(In reply to Callegar from comment #0) > Looks like currently, libreoffice supports the formatting of mathematical > expression by means of an equation editor that is based on "regular" fonts. > ODF 1.4 remains MathML centric, with no support of TeX's \fontdimen, OTF Math table parameters, or even of UnicodeMath [1] syntax. LibreOffice composes formulas as nodes with ODF compliant MathML interpreted internally to StarMath syntax for rendering into "typeset" formula nodes. > Recently, OTF fonts including a "math" table have been introduced... Nothing new there, but project already has moved the sm Formula editor beyond its legacy OpenSymbol font [2] to enable user to now choose any Unicode font for node composition. For our needs we already accommodate the BIDI "mirror" feature where font designer provides alternates ("RTLM" or "RTLA"). They don't require full OTF "MATH" table [3] support. So try a more fully featured OTF font like "XITS Math" or "Noto Sans Math" to get a better feel for LibreOffice's ODF MathML OTF Math table features aside, within limits of StarMath node composition, any Unicode Mathematical operator and symbol [4] can already be used as literals in composing formulas. But the sm node based engine lacks some key functions (for rendering MathML or eventually interpreting LaTeX) e.g. handling combining glyphs (needed for tall brackets, parenthesis, and integrals as opposed to stretching a single glyph) which are not yet implemented [5]. So certainly room to improve, perhaps even fully integrate LaTeX import/edit composition (as alternative to StarMath) available as extension (TexMaths). But no real imperative beyond sm module support of MathML. Refactoring the sm node engine to use the harfbuzz API to manipulate formula elements against fonts supporting the OTF MATH table is an approach to improving our MathML fidelity. =-ref-= [1] https://www.unicode.org/notes/tn28/ [2] bug 101174 [3] https://learn.microsoft.com/en-us/typography/opentype/spec/math [4] https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode [5] bug 32362 *** This bug has been marked as a duplicate of bug 103680 ***