Created attachment 196426 [details] LibreOffice vs Excel This is a follow-up of bug 162938, thus it has to be tested after 27be65a7d5326608f75839e3964ac322e88224a1 Steps to reproduce: 1. Open attachment 196417 [details] from bug 162938 -> Conditional format for =0 is displayed with a green arrow. it should be yellow. See comparison.
Also reproduced in Version: 6.4.0.0.alpha1+ Build ID: 9bc848cf0d301aa57eabcffa101a1cf87bad6470 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3; Locale: es-ES (es_ES.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 196427 [details] Screenshot of the rules Excel vs LibreOffice Seems the rules are wrongly imported. Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 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
As mentioned in bug 162938, already in 5.2, never supported.
In Excel, it's possible to select something else than >= For yellow, it's defined as >= 0 but for green, it's defined as > 0, that's why it works on Excel.
The goal of the patch reverted was to allow <, =, <=, etc. the pb shown in the screenshot is due the failing import which uses "=" for the 3 cases + first case uses "Percent" instead of "Value". BUT if you fix the rules, it displays like in Excel.
(In reply to m_a_riosv from comment #2) > Created attachment 196427 [details] > Screenshot of the rules Excel vs LibreOffice That screenshot shows something "fishy". In Excel, the second condition (for the yellow arrow) shows 2 contradicting conditions in that screenshot. Is it ">=" (right, on drop-down symbol), or "<=" (left, on text), or "both" conditions simultaneously (resulting in effect as an "equal" ("=") condition? The additional point to consider is whether Excel and Calc are evaluating the priority of (potentially conflicting) conditions in the same order. I am pretty sure that on the master branch (which includes additional recent patches to CF), the priority is not clearly established nor clearly displayed. FWIW, the patch 27be65a7d5326608f75839e3964ac322e88224a1 was/is actually a (possible) solution for tdf#162942 (to be tested by other users) but not (or not enough) for tdf#162938. Examples for tdf#162938: attachment 196417 [details] and/or attachment 196414 [details].
(In reply to Julien Nabet from comment #5) > BUT if you fix the rules, it displays like in Excel. The conditions are imported incorrectly. If the Excel file has a compound condition (e.g. AND("<=";"<="), the import to Calc (for that specific compounding condition) seems to be either incomplete or non-existent. That compounding condition is equivalent to "=", but the intention is to give an example that Calc seems unable to import correctly – the export from Calc should be tested too.
(In reply to ady from comment #7) > (In reply to Julien Nabet from comment #5) > > BUT if you fix the rules, it displays like in Excel. > > The conditions are imported incorrectly. If the Excel file has a compound > condition (e.g. AND("<=";"<="), the import to Calc (for that specific > compounding condition) seems to be either incomplete or non-existent. > > That compounding condition is equivalent to "=", but the intention is to > give an example that Calc seems unable to import correctly – the export from > Calc should be tested too. Sorry, that was supposed to be AND("<=";">=").