Created attachment 42004 [details] bugdoc with report Open attached file, run report in OOo 3.3RC9 and LibO 3.3RC3. Run Query the report based on this query. Where query contain empty (null) fields, the OOo not contain data empty report field, in LibO there is a NaN. Similar problem was in OOo http://www.openoffice.org/issues/show_bug.cgi?id=112652
@Zoltan : is this bug still around ? I seem to recall that there was another NaN issue somewhere (Calc ??) and that it had been resolved - perhaps this buggy behaviour is linked to that other one ? Alex
Still remain in LibO/OOo 3.3. I submitted only for warning this remained in both final version and not solved until now.
Display NaN with LibO 340rc2 Bernard Ribot
Still remain in LibreOffice 3.4.2 ...
Hi, I think this fix is missing http://openoffice.org/bugzilla/show_bug.cgi?id=116463 applying the extension may be a workaround
Hello, I installed the fixed version of report-builder-1.2.1 from ftp://qa-upload.services.openoffice.org/dba34d/report-builder.oxt. Effectively, it works with the use of the conditional print expression ISNUMBER([field_name]) instead of field_name in the Properties - Data tab of the data field. Bernard Ribot
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Hi Zoltán, is bug still (= for LO 3.5.x or 3.6 RC2) relevant?
It's a problem withe the language in the user-interface. I have tried to change the fields to German (Language-settings in the UserInterface was German) and the NULL-values were displayed correct. Then I tried to change back to English(USA) and the NULL-values where displayed as NaN. When I changed the Language-Settings in Tools → Optins → Lanugae Settings to English(USA) the English version of the report shows correct values, the German version shows NaN. Could not say if this is a bug.
Created attachment 64771 [details] Same document - two languages. When you change the fileds to your language, that is choosen for your GUI, it works.
My personal take on this is that NULL is null, and shouldn't be locale dependent, so for me this would be a bug, but then again I'm not the implementer/coder... Alex
Created attachment 64786 [details] Fields with numbers in diffent language to GUI - NaN, N,aN or date Could be difficult to test. You have to edit a report in your language and then change the language in the GUI to another language. Example is edited in German, fields are formated in German. Then it has been opened with GUI-language English(USA).
Must the titel of the report be changed? It's a problem with differences between GUI-Language and language for formatting the fields in the Report-Builder. There aren't only NULL-values wrong. With currency-fields it changed, in my example, the fields to date-fields.
*** Bug 40150 has been marked as a duplicate of this bug. ***
Apache OpenOffice issues 112652 and 116463 have been fixed in LibreOffice, too. Remaining issue: 114125 *This* issue: ACTUAL BEHAVIOUR -------------------------- If the format of a Formatted Field control is any numeric format other than the "General" (in some languages "Standard") of the *current* UI language, then NULL (empty) fields are formatted as NaN (not a number) instead of empty. The Numeric / General format of the current UI language correctly leaves fields with NULL value as empty. Tested with various combinations of French (France) / French (Luxembourg) / English (USA) / German (Germany). Note that this is the current *UI* language, not the current *Locale*. Also note that even a difference of country within same language exhibits the wrong behaviour: E.g.: - Current UI language=en_US and format language=en_GB: BUG - Current UI language=en_US and format language=en_US: OK - Current UI language=fr_FR and format language=fr_LU: BUG - Current UI language=fr_FR and format language=fr_FR: OK EXPECTED BEHAVIOUR ----------------------------- *ALL* formats leave NULL values as empty. WORK-AROUND -------------------- use "ISNUMBER([fieldname])" as "Conditional Print Expression". OTHER NOTES ------------------ Reproduced with OpenOffice.org 3.3.0 OOO330m20 (Build:9567) DETAILED REPRODUCTION INSTRUCTIONS ----------------------------------------------------- 1) Change UI language to English (United States): Tools / Options / Language Settings / Languages Set "User Interface" to "English (United States) Click OK 2) Restart LibreOffice 3) Open attachment 64771 [details] 4) Database Pane / Reports 5) Reports Pane / double-click on "Query1_table_structure_deutsch": Remarks column and about half of the COLUMN_SIZE column has NaN 6) Double-click on "Query1_table_structure_english_usa": Remarks column and about half of COLUMN_SIZE column is _empty_
Andras, you are listed as our "l10n tools" expert on http://wiki.documentfoundation.org/FindTheExpert Could you please take a look? This seems to be linked to the locale-dependent number formatter behaving incorrectly on "no value", except in the current UI language. See comment 15 for reproduction instructions.
(In reply to comment #16) > Could you please take a look? This seems to be linked to the > locale-dependent number formatter behaving incorrectly on "no value", except > in the current UI language. > > See comment 15 for reproduction instructions. Isn't the locale dependent number formatter Eike's area ? Alex
Yes, but reportbuilder doesn't use the number formatter. Whoever wants to have a look, the code is under reportbuilder/java, and I've heard the 'N,aN' case might be related to some XSLT processing which would make it even harder.
(In reply to comment #18) > Yes, but reportbuilder doesn't use the number formatter. I have trouble imagining what else it would use. I'll try to find out exactly.
I thought it uses the available Java formatting; reportbuilder/java/org/libreoffice/report/pentaho/layoutprocessor/FormatValueUtility.java and import java.text.SimpleDateFormat and dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'.'S'Z'") made me assume such thing.. But then again in the same source the variableSection.setAttribute(OfficeNamespaces.OFFICE_NS,...) indicate that indeed the final result may be thrown at one of the application parts.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b7235573643b898602ccc31eb983c71941aa12c fdo#33091 recognise General format in all languages The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Second commit to master had wrong bug number in message: commit 3a4534be6594c39bf785502e15f2dec22d15b312 Author: Lionel Elie Mamane <lionel@mamane.lu> Date: Wed Apr 24 14:56:00 2013 +0200 fdo#330191 a NULL value of float type is not NaN but it is *still* NULL. This was initially done to "fix" i#108092, but i#112652 comment 13 suggests this may have been fixed more cleanly. Change-Id: I2b76af2182715bc489cb89dd45d6b77d5038b506 https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=3a4534be6594c39bf785502e15f2dec22d15b312
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a4a38895d4e419bf4db57b0668af60b4dc6b595&h=libreoffice-4-0 fdo#33091 a NULL value of float type is not NaN It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.