Description: In LO 7.5, when pasting a Calc area into Writer as embedded spreadsheet, Math formulas coming from Calc are not displayed properly. This is a regression from 7.4, on which Math formulas are correctly diplayed. Confirmed on Windows 7 64bits and Ubuntu jammy Steps to Reproduce: 1. Open a new Calc spreadsheet 2. On any visible cell, insert a Math formula (tested with x_1,2 = {-b +- sqrt { b^2 - 4 a c }} over {2a} ) 3. Open a new Writer document 4. On Calc, select an area containing the Math formula 5. On Writer, use paste special (Shift-Ctrl-V) and select "Libreoffice 7.5 spreadsheet" Actual Results: Math formula is not displayed (only horizontal lines shows) Expected Results: Math formula should be visible Reproducible: Always User Profile Reset: No Additional Info: Build info Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-AR (es_AR); UI: es-ES Calc: threaded
Confirmed. But those "horizontal lines" are the bars for the 'sqrt' and the 'over' of the OLE ODF formula coming from the cell on the ODF spreadsheet. Selecting the OLE on the Writer canvas shows the sheet to be complete with nodes for the OLE formula fully rendered. Other text in cells on the inserted OLE sheet is rendered, it is just the text for nodes of the OLE Formula that are not. Toggling the System - Light - Dark does not expose the text nodes of the Formula OLE So not similar to other Dark color theme mode issues we've encountered. Rather something with the OLE handling. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 14a36ad49518bcb5b606b0f1640e3ca56b636e89 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 185412 [details] Writer with OLE spreadsheet inserted with a cell holding OLE formula
So for attachment 185412 [details] opened in 7.4.3 the nodes of the OLE sheet cell held OLE formula were fully rendered. No longer in 7.5 or 7.6 Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I could reproduce as far back as 6.3: Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Not in 6.2.0: Version: 6.2.0.3 Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Maybe confusion came from the formula being restored once the object is double-clicked?
Sorry, I'm introducing confusion myself. With the steps in Description, starting from scratch and clean profile, I can reproduce as described, regression in 7.5, unrelated to dark mode. Repro: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded No repro: Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded About the other issue described in Comment 4, when starting with Stuart's attachment 185412 [details], not 100% sure it is related. Removing the dark mode meta.
Bibisected with linux-64-7.5 repository to first bad commit 5e9e431b4a9bc67357adaf635c34bdfd3ee61321 which points to core commit: commit 1fa731d03ba0f22cb9392a578124ea977eaab2e9 author Caolán McNamara <caolanm@redhat.com> Tue Aug 16 23:39:53 2022 +0100 committer Caolán McNamara <caolanm@redhat.com> Thu Aug 18 20:30:33 2022 +0200 tree fd415b74a5f728e0eb99eb25b552c248c80112e9 parent b72ebcf5b26ab2e54c5251c5c45e6d45cade9236 tdf#150462 don't prescale dxarray before using DrawTextArray setup the device scaling instead and pass in the unscaled dxarray and at least give vcl the chance to retain some accuracy Change-Id: I17660eb77adf8586be6eb54e61bded3a5bcc20a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138448 Caolán, could you please have a look?
seems to render initially ok, but gets mangled when serialized to svm
*** Bug 153873 has been marked as a duplicate of this bug. ***
*** Bug 153544 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba42b8b95b2166f9bd578cd90c54e9826a755a6e tdf#153672 Use RelativeMapMode so text in gdis are scaled/offset correctly It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
seems to be good in trunk, though this path is fragile. backport to 7-5 in gerrit
This bug has been marked as duplicate of this: https://bugs.documentfoundation.org/show_bug.cgi?id=153544 Please note that the issue presented on the bug above has NOT been fixed and still labels are missing from exported charts. Version: 7.5.1.2 (AARCH64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Mac OS X 12.5; UI render: default; VCL: osx Locale: en-GB (en_IT.UTF-8); UI: en-US Calc: threaded
On the Thursday 2nd of March I said "seems to be good in trunk ... backport to 7-5 in gerrit" trunk is 7.6 as shown in comment #10, the 7.5 "in gerrit" is https://gerrit.libreoffice.org/c/core/+/148102 and has not been merged into the 7.5 series yet so it is not in 7.5.1 on Monday March 7th. When someone reviews and approves the backport this issue will mention what version of 7.5 the fix will land in
Sorry, I understood almost nothing of what you said. I use LibreOffice Calc for work and the release 7.5.1.2 was marked as stable so I downloaded it on my machine. I would just understand if developers are aware of this serious bug and if the fix is coming soon. Hope you understand. Thank's.
(In reply to crest.arbours-0k from comment #14) If unfamiliar we don't expect you to know, but the Whiteboard field above will reflect the builds that have received correction/patches/refactoring. So even though closed, it is clearly marked that it has not landed in a 7.5 release yet. Devs are aware, and reopening a resolved fixed issue can be a nuisance especially when user is not working with the corrected or current builds. Sometimes a little challenging to ascertain but necessary. None the less thanks for checking, and either check the fix against a 7.6 alpha nightly or when the patch posts to a 7.5 release build. Useful confirmation feedback is appreciated.
Confirmed it works on 7.6, Windows7 64bits Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7c609dbb1bd08865b43719d2fb7c316d30bcde5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-AR (es_AR); UI: es-ES Calc: threaded
Marking as verified for Emiliano. Thanks everyone!
*** Bug 154033 has been marked as a duplicate of this bug. ***
*** Bug 153757 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/bd42cd1a325cd53db9fca0865f851bcd6e09ccc6 tdf#153672 Use RelativeMapMode so text in gdis are scaled/offset correctly It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 154194 has been marked as a duplicate of this bug. ***
*** Bug 153981 has been marked as a duplicate of this bug. ***
*** Bug 154054 has been marked as a duplicate of this bug. ***
*** Bug 153467 has been marked as a duplicate of this bug. ***
*** Bug 154435 has been marked as a duplicate of this bug. ***
*** Bug 154485 has been marked as a duplicate of this bug. ***
*** Bug 155247 has been marked as a duplicate of this bug. ***
*** Bug 153372 has been marked as a duplicate of this bug. ***