A bug in the scalable parentheses of math

WRIuser · April 22, 2025, 3:41pm

My trouble is that scalable parentheses of matrices, used in linear algebra, worked perfectly in LibreOffice Math until the advent of LibreOfffice 7 and later versions (up to version 24).
Now they do not work properly any more.
If you typed

left [ matrix {
a_11 # a_12 # a_13 # a_14 ##
a_21 # a_22 # a_23 # a_24 ##
a_31 # a_32 # a_33 # a_34 ##
a_41 # a_42 # a_43 # a_44
} right ]

in the equation editor of Libre Office Writer 6, you got a matrix surrounded by square parentheses as expected.
Now in LibreOffice 24 scaled parentheses disappear as soon as you exit the equation editor; only the 16 elements of the matrix are displayed - although scaled parentheses are correctly inserted when you export the document in PDF format.
Clearly it is a bug of LibreOffice Math and/or LibreOffice Writer that needs to be fixed.
Thank you very much for reading

ajlittoz · April 22, 2025, 3:49pm

Can’t reproduce under LO 24.8.6.2, Fedora 41 Linux, KDE Plasma desktop

Even if I add white borders around the formula with 0 cm padding and heavy strokes, this border does not overlay the brackets. There is still some padding between brackets and border.

For better diagnostic, attach your sample file.

mikekaganski · April 22, 2025, 3:50pm

No problem using Version: 25.2.3.1 (X86_64) / LibreOffice Community
Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b
CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-GB
Calc: CL threaded

brackets

keme1 · April 22, 2025, 3:56pm

What specific version are you using, and on which OS platform?

When I insert your sample matrix, it displays with brackets as expected, like others have experienced with various other versions. This indicates that the error lies within a specific build, or in your specific system setup.

My system:
LO version: 24.8.6.1 (X86_64) / Build ID: 051bf11303684a0a982c9966e8be766d0a9efbc7
OS: Windows 11 X86_64 (10.0 build 22631)

You can find this info for your system in the help menu, the bottom item “about LibreOffice”.

WRIuser · April 23, 2025, 11:53am

This screenshot shows the bug in the latest stable version of the LibreOffice appimage for Linux. The scalable parentheses are missing in the matrix rendering, as you can see. The appimages of LibreOffice 6x render the matrix correctly with the square parentheses.
The language in the screenshot is Italian, but don’t doubt that the bug has nothing to do with the language: it pops up even in the English version.
I have a large collection of equations of mine, sometimes quite complex, which make use of almost all features of LibreOffice Math equation editor. Appimages have the advantage that no installation is required; they work at once out of the box and they are easily portable on different computers.
Before making the transition to a new version of LibreOffice Writer and Math I stress test the software, checking all the equations of my collection: that is how I found the bug. I begin to use LibreOffice Writer for new texts only after the software has been thoroughly checked.
My suspect is that the bug crept into LibreOffice Math when RGB colour for equations - which is a new feature of LibreOffice 7 and later - was added. However ajlittoz has found no bug in his Fedora Linux installation of LibreOffice and mikekaganski has found no bug in his Windows installation.
Therefore keme1 is right: this indicates that the error lies within a specific build, or - less likely - in my specific system setup.
I have some practice of scientific programming in C and C++ with console input and output, but I am not up to handle such a complex software as LibreOffice with GUI. If someone can fix the bug I will send a donation and I volunteer to test the new Appimage Writer and Math with my extensive collection of equations.
Thank you very much for reading

ajlittoz · April 23, 2025, 12:17pm

To make sure attach your sample file. The screenshot shows what happens at your machine but does not lend itself to analysis. By testing your sample file we can eventually rule out an error in the appimage.

koyotak · April 23, 2025, 1:22pm

I’ve enlarged your image.

Take a closer look at the numbers and letters; ‘1’ and ‘4’ are taller than ‘2’ and ‘3’ with overlength, and the variable ‘a’ isn’t italicized. The cause may be the font. I know no font with those overlength, only the ‘6’ and ‘8’ in “Hoeflers” have those. I can’t change the math symbols, which are OpenSymbols, to a different font.

I have no errors on display using LO v.25.2.1.2 and v.24.8.3.2 and v.24.2.7.2 and v.7.2.7.2 unter macOS 15.4 with “Liberation Sans/Serif” and “OpenSymbols”.

I vaguely remember a visual error where characters would sometimes disappear and sometimes reappear at different % display scalings.

ajlittoz · April 23, 2025, 3:37pm

To go further in @koyotak’s idea about font: scalable brackets are built from bits taken in OpenSymbol. Is this font installed on your system? It comes as a dependency on LO packages, therefore automatically installed when you request LO.

I am not familiar with AppImage packaging. I understand it is a stand-alone format. You install it and it runs. It may happen that OpenSymbol is not provided as part of this image and there is no mechanism to fetch the missing dependencies.

koyotak · April 23, 2025, 5:45pm

On my macOS the font OpenSymbol is only part of every LO-App, not installed to my macOS system.

LO-Progs_Installations_073255

I suspect that the original LO program wasn’t unpacked or installed correctly. This isn’t unusual. I’ve downloaded it from the web several times and reinstalled it without deleting the previous version. This worked if I renamed the previous app with the additional version, so that the newly downloaded version without a number could be installed as if it were virgin, including the language pack.

WRIuser · April 24, 2025, 2:25pm

I have several computers, none of them very powerful but all working, so that I can try different configurations. Hence I can rule out that the missing parentheses bug is caused by multiple installations on the same computer because the bug shows up when the appimage of LibreOffice 24 is run for the first time after uninstalling the default version of LibreOffice which comes automatically with Ubuntu Linux.
koyotak has suggested that the bug might be caused by the font. He used Liberation Serif; there fore I have tried Liberation Serif myself instead of DejaVu Serif, but to no avail.
However koyotak is partly right because scalable parentheses are rendered correctly when the font size is small enough - it looks as if scalable parentheses are ignored when their height exceeds a threshold.
ajlittoz has suggested that the bug might be caused by a missing dependency not resolved automatically by the appimage of LibreOffice 24. Therefore I have analyzed the OpenSymbol font used for math in the equation editor. I downloaded the font from OpenSymbol Font | wfonts.com - download free. You get a ZIP file of size 57.3 kb, which turns into opens.ttf (size 103.2 kB) when unzipped. I have reinstalled OpenSymbol but to no effect.
PDF is not affected by the bug - parentheses are scaled correctly in PDF no matter their size.
Here is an .odt document generated by the appimage of LibreOffice 24 for Linux.
Thank you very much for reading
BUG - Missing parentheses around a matrix.odt (31.5 KB)

ajlittoz · April 24, 2025, 3:33pm

Your document displays as expected under 24.8.6.2 coming from standard Fedora 41 packages with all dependencies automatically resolved (if this is a matter of dependency, which does not seem so according to your last post).

DejaVu Serif is not installed on my machine (appears italic in the font selection field of the toolbar). It is substituted, but this is irrelevant to the bracket issue.

I looked at the underlying XML and I am no longer so sure that the scalable brackets are composed of several partial glyphs. We have <mo fence="true" form="prefix" stretchy="true">[</mo> where [ is the usual U+005D. There is no explicit indication to switch to OpenSymbol (it may be implicit). And a closer look to rendering shows that some “standard” glyph is indeed vertically stretched (the small horizontal strokes at top and bottom are much thicker than the lateral vertical stroke).