Created attachment 154168 [details] Zip file containing 1 docx document and the rendering on windows and ubuntu Hello ! I have an issue when using libreoffice on windows and microsoft word (sharing a document between two persons). We are writing mathematical documents and had issues to show the `doublearrow` in equations. In the attached double-arrow-issue.zip, you can find a file test_equivalent.docx which is the file that is not read in the same way across versions. The rendering on Windows in Libreoffice 6.3.1 (test_libreoffice_windows.PNG) shows that the doublearrow written in unicode (`<m:t>⟺</m:t>`) does not show up at all. As you can see, the rendering is correct on libreoffice 6.0.7.3 on ubuntu (test_libreoffice_ubuntu.png). The last screenshot (test_microsoftword_windows.PNG), shows that the rendering works on microsoft word, except for the `doublearrow` which does not seem to be interpreted, but that is of course not an issue of libreoffice. So the bug is that doublearrows written like this in the document.xml (`<m:t>⟺</m:t>`) are not rendered at all on Windows. Best, Edgar
It is a font issue. The sm Formula Editor will use OpenSymbol by default, with no means to change the default (RFE open as bug 101174). The StarMath macros do have coverage in OpenSymbol and will be rendered, just in a font different to the document text. dlarrow -> U+21d0 drarrow -> U+21d2 dlrarrow -> U+21d4 But since there is no font coverage in OpenSymbol for U+27FA LONG LEFT RIGHT DOUBLE ARROW, font fall back occurs--Ubuntu picks one up, Windows does not. Two means to work around: 1. In LibreOffice Formula editor (OLE link launches the sm Formula editor, the Format -> Fonts menu) to manually change the font for each formula to use the "Cambria Math" that the original document is written in. Tedious but will work. Mostly need to set the "Variables" font (but best to set them all for matching metrics) in the formulas. Once one formula is changed, the fonts are added to the drop list--so simple to work through. 2. use a Font replacement table and replace OpenSymbol with either Cambria Math, or one of the Styx fonts -- font metrics may be off and cause size issues. *** This bug has been marked as a duplicate of bug 101174 ***
Ok, I see, my friend is using Windows and explaining this seems a bit ... difficult... In your response you say the following : font fall back occurs--Ubuntu picks one up, Windows does not. Why can windows not manage to find a fallback ? I'm a huge open-source advocate and like a lot LibreOffice, but here I don't even myself understand what exactly the problem is, I guess I am quite a noob regarding fonts and other related aspects but I'm really confused why there couldn't be an easy fix since it works with the doublearrow "Starmath" macro.
(In reply to 4layq596ovwv from comment #2) > Ok, I see, my friend is using Windows and explaining this seems a bit ... > difficult... > > In your response you say the following : font fall back occurs--Ubuntu picks > one up, Windows does not. > > Why can windows not manage to find a fallback ? Completely different font fall back mechanisims. > > I'm a huge open-source advocate and like a lot LibreOffice, but here I don't > even myself understand what exactly the problem is, I guess I am quite a > noob regarding fonts and other related aspects but I'm really confused why > there couldn't be an easy fix since it works with the doublearrow "Starmath" > macro. Because there is no sm defined macro for the "LONG LEFT RIGHT DOUBLE ARROW", meaning there is no linkage to the Unicode point 0x27fa, even if it were available in OpenSymbol font used by default for StarMath/MathML formulas in the Formula editor. And, while you can enter it as a StarMath litteral, e.g. "⟺", still no assurance Windows (or Linux or macOS) will pick up a suitable fallback font to the default OpenSymbol font. As indicated, you can force use of a specific font per formula, and select a font that has more extensive coverage of Unicode Mathematical symbols--we just can not specify an alternative default font. What prevents us from moving this forward is a fair number of Private Use Area glyph definitions provided from OpenSymbol that first need to be migrated to their correct Unicode point and allow a different font default to be set.