Created attachment 52670 [details] Malformed input that LO accepts, leaving human wondering what's going on. This is more of a question than a bug report, but I'm not sure where to "discuss" or ask this question. Distilled from a legitimate case of a program outputting slightly malformed input, the question is "how strict should LO be about interpreting it's input?" The attached document and screenshot showcase an example where a bit of ODS input is slightly malformed. This apparently doesn't bother LO, but certainly messes up the logic, as the background of the cells should be blue, not red (based on conditional formatting logic). Content.xml is slightly malformed on lines 34 and 39. Line 39 is the more "insidious" case as the output within LO even passes the basic inspection of a human eye. (Click on cell C15, then click Format -> Conditional Formatting, and inspect the values. It /looks/ right, doesn't it?) This is "broken" as far back as OpenOffice 3.2, but I don't have any interim LibO versions installed; I'm not sure what version to set the dial to for this bug report.
Recreated as of: $ git log -1 commit 237c5f0290169aa31e10990c05b7ea39d9fc70bd Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sat Oct 22 12:36:07 2011 +0200 another fix for 68dd19a368fb4afbf3eba4cb722f56b87f8ea7c1 on OSX And never sure what is helpful to a developer tracking down a bug, so: $ uname -a Linux hani 2.6.35-30-generic #60-Ubuntu SMP Mon Sep 19 20:42:44 UTC 2011 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local --enable-ld=yes --enable-lto --enable-bootstrap Thread model: posix gcc version 4.6.1 (GCC)
Created attachment 52696 [details] Associated screenshot Doh! Forgot to include the screenshot last night. And the description in Comment 0 should read "cells should be blue, not green".
Thanks for bugreport reproducible in 3.3.4 and 3.5.2 on Fedora 64 bit changing version to 3.3.4 as most early reproduced When save this file and reload again, it works correctly IMHO it is functionality request for adding warning for user if in opened odt file is some problem
Just updating version to inherited from because of the OP stating that it's been an issue since OOo 3.2. @Kevin - from what I can tell this is still a "problem." If you could confirm on 5.1 or later that'd be great. Thanks!
Created attachment 126122 [details] Malformed input as viewed in LO 5.1.4.2 Yes, it appears to be still an issue. What's more, either there's another malformed tidbit in the file, or LO now also does not show cell A4 (reference attached screenshot, where the content is shown in the input bar above, but not in the viewing area below). For this test, I used the version packaged with Ubuntu Xenial. From the About dialog: Version: 5.1.4.2 Build ID: 1:5.1.4-0ubuntu1 CPU Threads: 1; OS Version: Linux 4.4; UI Render: default; Locale: en-US (C)
(In reply to sasha.libreoffice from comment #3) > IMHO it is functionality request for adding warning for user if in opened > odt file is some problem Design team: any idea about this? The report does not seem to be clearly defined as to what needs to be implemented.
What happens is that conditional formatting on C10 has three conditions with an invalid value on the second item (A10+B10) of the first condition. I guess the evaluation ignores this value and use just the first one, A10-B10, which is true so condition 1 is taken. Another example of false input is entering a string into a field where numeric values are expected. The input is colored in those cases meaning we recognize it as an error. What we should block the dialog until those errors are fixed. PS: Please don't mess up with the content of odf files.
BTW the bad expression in condition it's signaled with a red background color (7.1.3), so LibreOffice verify the formula has a correct syntax (not about their result). I can't see a bug here