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("<=";">=").
Created attachment 196864 [details] minimized sample
The problem is that gte attribute is ignored. <cfRule type="iconSet" priority="1"> <iconSet iconSet="3Arrows"> <cfvo type="percent" val="0"/> <cfvo type="num" val="0"/> <cfvo type="num" val="3" gte="0"/> </iconSet> </cfRule>
Created attachment 196866 [details] minimized sample ( > vs >= )
(In reply to Xisco Faulí from comment #10) > The problem is that gte attribute is ignored. > > <cfRule type="iconSet" priority="1"> > <iconSet iconSet="3Arrows"> > <cfvo type="percent" val="0"/> > <cfvo type="num" val="0"/> > <cfvo type="num" val="3" gte="0"/> > </iconSet> > </cfRule> Actually I believe if gte is present then the conditional format is "> 3", otherwise it's ">= 3", The problem is that LibreOffice always uses ">=" like in https://opengrok.libreoffice.org/xref/core/sc/source/core/data/colorscale.cxx?r=27be65a7#1153
Created attachment 196867 [details] LibreOffice ( >= 3 ) vs Excel ( >3 )
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/acc52f9bc0dbfcb5a8893b5aff2d18a2360d46e2 tdf#162948: Add support for gte attribute in conditional format It will be available in 25.2.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.