Create a Math formula in Math module and save it to odf. For example use "y=sum from k=1 to n {1 over k}". Use larger basic font size of e.g. 30pt, that makes the formula better visible in the tests. Go to Advanced Settings and search for the property "PrinterIndependentLayout". It should exists for Draw and Impress. Set the value to 1 for the Impress one. "1" means "disabled". Start Impress. On the slide do Insert > Ole Object. Select "from file" and search for the formula you have created in the beginning. OK. The formula is wrongly rendered. Close the file. Go back to Advanced Settings and set the value of property "PrinterIndependentLayout" to "2". "2" means enabled. Start Impress. Again insert the Math-OLE. Now rendering is OK. The value of "PrinterIndependentLayout" is saved in the registrimodifications.xcu. "PrinterIndependentLayout" has no UI and I do not know how the value was originally set in my profile as I have used the profile throughout many versions. But it had value 1, which caused the rendering problems. "PrinterIndependentLayout" is property in css.document.Settings in API. I see the problem in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 976567aee323afd09629b6adf13537908f43d2a8 CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded The behavior was OK in Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Created attachment 196620 [details] Screeshot with parameter value = 1 Works fine for me, no matter if the value is 0|1|2 Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5b54f68599d9a9b6f4d21fd8c0cdac746ea71ecb CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Created attachment 196621 [details] Screenshot of correct rendering (In reply to m_a_riosv from comment #1) > Works fine for me, no matter if the value is 0|1|2 Your image clearly shows the wrong rendering. Compare with my screenshot of the correct rendering.
Checked the value of "PrinterIndependentLayout" on a /a admin install, which shows value of "2"--so build default? Followed STR but could not reproduce with value set to "1". My system default printer is a ghostscript based print engine, CutePDF so guess that could be involved. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d14e79bf7680db2180e40ba52fc3305a84c586f6 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to Regina Henschel from comment #2) > .............. The error is there no matter the value.
I have tried different default printers. That has no influence. I have found that the error depends on the font, that is set for category "Variables". If I use "Liberation Serif, Italic", then the formula is badly rendered. If I use "Source Serif Pro, Italic", then the formula is rendered correctly. My version of Liberation Serif is 2.1.5. Can you please look whether your formula uses "Liberation Serif, Italic"? Is version 2.1.5 the most current version? If not, where can I download a newer version?
Created attachment 196638 [details] Screeshot with 'Sans Serif Collection, italic' (In reply to Regina Henschel from comment #5) > .... > I have found that the error depends on the font, that is set for category > "Variables". If I use "Liberation Serif, Italic", then the formula is badly > rendered. If I use "Source Serif Pro, Italic", then the formula is rendered > correctly. > > My version of Liberation Serif is 2.1.5. > > Can you please look whether your formula uses "Liberation Serif, Italic"? > If I change the font for 'Variables' to 'Sans Serif Collection', I think it works fine.
From versions, that I have installed: Broken is Version (15.Jun): 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aaf2967d74a9a7ba2d28433e1872422ce38b6244 CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded OK is Version (11.May): 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2b85bceca88ab119fff5cbdc41fe913435a479ca CPU threads: 32; OS: Windows 11 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
OK, confirmed what Regina has happening I changed my system default to a physical printer (Brother HL6200DW), and made sure LibreOffice was configured to use that printer (File -> Printer Settings). In expert configuration set "PrinterIndependentLayout" to "1" disabled, and restart LO, so the printer metrics are being considered. Creating the ODF Fromula and adding it as OLE to Impress, I get a corrupted OLE with a way over width bounding frame. Even some glyphs in the nodes are missing. Likewise, if I change the font for 'Variables' from Liberation Serif, Italic to Libertinus Serif in the font listbox and Format -> Font Size (increase or decrease) the OLE formula nodes will reform, and on exit from OLE edit its frame will shrink to enclose. Changing the format for Variables back to Liberation Serif again corrupts the OLE frame. For the PrinterIndependentLayout setting (1|2) to apply you have to restart LibreOffice. =-testing-= Version: 24.8.1.1 (X86_64) / LibreOffice Community Build ID: ef51c4a0cd35185debf25ad9d0db6a1c14bed5a0 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #8) Changing the PrinterIndependentLayout back to 2, i.e. enabled and ignoring the printer, restarting LibreOffice the Formula OLE handling returns to normal.
And finally, I again tested with default printer and LibreOffice set to a ghostscript based file printer. Restart LibreOffice and verify the PrinterIndependentLayout is set disabled. When the ODP was saved with the mangled OLE, a change in printer did not clear it and it remained missized/shaped--getting progressively worse with any font changes. But a newly created presentation, using the same ODF formula inserted as OLE, with ghostscript based printer is correctly formatted/sized and changes in font do not mangle the frame. So there is some facet to the type of printer attached, but any printer can be affected when the PrinterIndependentLayout is not active.
PrinterIndependentLayout blocks creation of the <config:config-item config:name="PrinterSetup" config:type="base64Binary">... </config:config-item> in the settings.xml for the documents. It creates it for *both* the OLE inserted ODF formula, and the Impress ODP, is that the issue? And if I deleted the stanza from the OLE's ODF settings.xml then the Impress rendering seemed stable.