Bug 38097 - ODF import: <number:fraction> data styles not read correctly
Summary: ODF import: <number:fraction> data styles not read correctly
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Laurent BP
QA Contact:
URL:
Whiteboard: odf target:5.2.0 target:5.1.4
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-08 23:33 UTC by Andreas J Guelzow
Modified: 2016-10-25 19:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file (4.90 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-06-08 23:33 UTC, Andreas J Guelzow
Details
Please see Comment 1 (66.78 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-06-09 01:31 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas J Guelzow 2011-06-08 23:33:28 UTC
Created attachment 47752 [details]
sample file

LibreOffice appears not to read fraction number formats from ODS files. The attached sample file has number:fraction format set for cells B1:B4.
Comment 1 Rainer Bielefeld Retired 2011-06-09 01:30:48 UTC
NOT reproducible with own sample document 8created with OOo 3.1.1) and "LibreOffice 3.4.0  – WIN7  Home Premium  (64bit) German UI [OOO340m1 (Build:12)]". Also new documents respect format "fraction" as expected.

Related to OS, Version, broken document or something else?

@Andreas J Guelzow:
Unfortunately in your report very much required information is missing.

May I ask you to read  hints on <http://wiki.documentfoundation.org/BugReport> carefully?
Then please:
- Write a meaningful Summary
- Attach a sample document with more information
- Attach screenshots with comments (you can add information using LibO DRAW
  and then attach your screenshot with comments as PDF) if necessary
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem
- add information 
  -- what exactly is unexpected
  -- and why do you believe it's unexpected
  -- concerning your PC 
  -- concerning your OS
  -- concerning your LibO version and localization (UI language)
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- how you launch LibO
  -- everything else crossing your mind after you read a.m. URL

Can you please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide? 

Thank you!
Comment 2 Rainer Bielefeld Retired 2011-06-09 01:31:28 UTC
Created attachment 47758 [details]
Please see Comment 1
Comment 3 Andreas J Guelzow 2011-06-09 08:49:06 UTC
To replicate the problem:
-------------------------------------
open LO
open the attached sample file
look at cells B1 to B4 an see they do not show as fractions (Do you really need a screen shot for that?)
-------------------------------------

There is really nothing more I can add to that description and it seems to me that you aren't seeing any fractions in B1 to B4 either.

I have no doubt that LO/OOo generated files are read correctly but that's not what this report is about.

You can use http://tools.odftoolkit.org/odfvalidator/ to verify that this attached file satisfies Extended Conformance (It contains some foreign elements that LO ought to ignore on reading.)

In content.xml there is (for B1):
<table:table-cell table:style-name="ACE-0x975dd60" table:formula="of:=PI()" office:value-type="float" office:value="3.14159265358979"><text:p>3 1/7</text:p>          </table:table-cell>

earlier in content.xml we have:
    <style:style style:name="ACE-0x975dd60" style:family="table-cell" style:data-style-name="ND.2">

So the named data style "ND.2" should be used for B1.
In styles.xml "ND.2" is given as:

<number:number-style style:name="ND.2"><number:fraction number:grouping="false" number:min-denominator-digits="1" gnm:max-denominator-digits="1" number:min-integer-digits="0" number:min-numerator-digits="0"/></number:number-style>

So the content of cell B1 should be shown as a fraction.

All of this comes from the file I provided.
Comment 4 Björn Michaelsen 2011-12-23 13:55:33 UTC Comment hidden (obsolete)
Comment 5 Björn Michaelsen 2011-12-23 17:02:06 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 13:58:23 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 7 Florian Reisinger 2012-08-14 13:59:40 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:04:16 UTC Comment hidden (obsolete)
Comment 9 Florian Reisinger 2012-08-14 14:06:28 UTC Comment hidden (obsolete)
Comment 10 Andreas J Guelzow 2012-08-14 17:22:08 UTC
What information were you asking for that hadn't been submitted????
Comment 11 Michael Meeks 2012-08-14 18:49:15 UTC
Clearly closed in error; re-opening :-) thanks for pointing it out.

Kohei / Eike - incoming bug from gnumeric hacker; do we have 'fraction' number format support in the core ? anyhow - one for you guys.
Comment 12 Andreas J Guelzow 2012-08-19 04:02:26 UTC
@Michael, LibreOffice allows one to set fraction formats which usually seems to work fine (pi is listed as 31/8 when the format is set to ?/8, that is obviously strange). And if one saves and reopens some of the formats in question roundtrip correctly.
Comment 13 Horst 2012-09-25 18:54:11 UTC
(In reply to comment #12)
> @Michael, LibreOffice allows one to set fraction formats which usually seems
> to work fine (pi is listed as 31/8 when the format is set to ?/8, that is
> obviously strange). And if one saves and reopens some of the formats in
> question roundtrip correctly.

Sorry Andreas, I don't see it strange it is closest 8th fraction for pi-decimal. And you FORCE it to be displayed in n/8.
If you use the standard "# ?/?" you get 3 1/7 which is the closest fraction for PI. 1/7 = 0.142857.. slightly more but the closest solution.
If you use "# ??/??" (2 digit fractions) your result will be 3 14/99 = 3.141414.. also very close to PI.
I don't see any bug here. The math is as far as I can see correct.
Comment 14 Andreas J Guelzow 2012-09-25 19:09:52 UTC
@Horst, I have no idea what you are talking about. If I open the file I attached in LibreOffice, cells B1:B4 do not show any fractions although they should. I would expect to see in B1:B4 the fractions curently only shown (as strings) in C1:C4

(In the moment I only have LibreOffice 3.4.5 handy to check.)
Comment 15 Andreas J Guelzow 2012-09-25 19:13:40 UTC
Oh I see:

31/8 = 3.875
30/8 = 3.75
26/8 = 3.25
25/8 = 3.125

SO I would think that 25/8 is muck closer than 31/8.
Comment 16 Andreas J Guelzow 2012-09-25 19:20:04 UTC
I guess I see you are interpreting "?/8" to mean "# ?/8" and so are showing "3 1/8" as "31/8" ie. just without the space.
Comment 17 Horst 2012-09-26 17:48:12 UTC
(In reply to comment #14)
> @Horst, I have no idea what you are talking about. If I open the file I
> attached in LibreOffice, cells B1:B4 do not show any fractions although they
> should. I would expect to see in B1:B4 the fractions curently only shown (as
> strings) in C1:C4
> 
> (In the moment I only have LibreOffice 3.4.5 handy to check.)

@Michael, I see what you mean. If I open your file (LO 3.5.5 is my oldest version) it shows the same what you described above. NO cell shows any pre-formatting what so ever.
I played around and I think you have a case here!
If formated "?/8" result is 31/8 but it should be 25/8 (PI/0.125 = 25.1327) which would be the closest 8th to PI not 31/8 =3.875.
So definitly a bug!
Comment 18 Horst 2012-09-26 18:40:18 UTC
I can see clearly now:)
The problem is that the parser interprets formats "?/n" (n={2..9}) as "#?/n" with missing displayed blank.
I tested it with LO3.5.5 and 3.6.2rc

Format  PI display  should be
 ?/?      22/7       22/7
 ?/8      31/8      (3 1/8) or 25/8
 ?/7      31/7      (3 1/7) or 22/7
 ?/6      31/6      (3 1/6) or 19/6

The table shows it very good (I hope). So far you can not force LO to display fractions as 8th, 7th... correctly.
Comment 19 Kohei Yoshida 2012-09-27 20:21:06 UTC
Version is the first version reported. Please don't change that.
Comment 20 Andreas J Guelzow 2012-09-28 04:10:44 UTC
The primary reason for this bug report was that LibreOffice, when reading the sample file attached doesn't even seem to read teh number formats for B1 to B4 that happen to be fraction formats.

I just tried this with  LibreOffice 3.5.4.2  Build ID: 350m1(Build:2) and it still does not load those number formats.
Comment 21 Kohei Yoshida 2012-09-28 14:37:47 UTC
(In reply to comment #20)
> The primary reason for this bug report was that LibreOffice, when reading
> the sample file attached doesn't even seem to read teh number formats for B1
> to B4 that happen to be fraction formats.
> 
> I just tried this with  LibreOffice 3.5.4.2  Build ID: 350m1(Build:2) and it
> still does not load those number formats.

Thanks for the clarification.

I just loaded the file, and indeed B1:B4 show the raw values without the format applied to them.

When I manually apply the fractions to B1:B4, re-save the file and re-open it, OTOH, the formats do get applied correctly.

Not sure what the difference is between these two files...
Comment 22 Andreas J Guelzow 2012-09-28 14:49:05 UTC
The sample file is an ODF file not generated by LibreOffice (or any other program in the LibreOffice/OpenOffice family).

If you unpack the file you will see that in content.xml B1 is defined as
<table:table-cell table:style-name="ACE-0x975dd60" table:formula="of:=PI()" office:value-type="float" office:value="3.14159265358979"><text:p>3 1/7</text:p>          </table:table-cell>

The ACE-0x975dd60 style is (also in content.xml) given as:
    <style:style style:name="ACE-0x975dd60" style:family="table-cell" style:data-style-name="ND.2">

That style refers to the named data style ND.2 which in styles.xml is given as 
<number:number-style style:name="ND.2"><number:fraction number:grouping="false" number:min-denominator-digits="1" gnm:max-denominator-digits="1" number:min-integer-digits="0" number:min-numerator-digits="0"/></number:number-style>

This data style is clearly a fraction. It seems that somewhere when LibreOffice opens this file it fails to interpret this chain of ttyles or the finalfraction style correctly.

NOte that his file validates under "extended conforming". If required I can also provide a similar file that validates under "conforming". The only differnce would be soe foreign elements in the gnm: namespce that LibreOffice should be ignoring anyways.
Comment 23 Kohei Yoshida 2012-09-28 14:51:04 UTC
Eike, this seems like a mapping issue between the ODF number format and our own.  Maybe you have a better idea on what's going on here than the rest of us...
Comment 24 Horst 2012-10-21 19:09:19 UTC
Added bug 56209. Was a different issue for 3.6.xx but the sample file there TFRAC.ODS shows a similar behavior as "sample file". File was created in Excel and saved as .ODS. When loaded in LO3.5.6 or ..7 only the default LO fraction formats are recognized (row 2,3). the other fraction formats defined in Excel do not show any formating in LO.
Comment 25 Joel Madero 2014-11-04 03:43:51 UTC
Should be set to NEW not REOPENED. If the bug has been fixed in the mean time please set to RESOLVED -> WORKSFORME. Thanks
Comment 26 QA Administrators 2015-12-20 16:11:32 UTC Comment hidden (obsolete)
Comment 27 Laurent BP 2016-05-03 19:46:19 UTC
(In reply to Andreas J Guelzow from comment #22)
> That style refers to the named data style ND.2 which in styles.xml is given
> as 
> <number:number-style style:name="ND.2"><number:fraction
> number:grouping="false" number:min-denominator-digits="1"
> gnm:max-denominator-digits="1" number:min-integer-digits="0"
> number:min-numerator-digits="0"/></number:number-style>
Actually, this file was created with Gnumeric as gnm:max-denominator-digits indicates.
LibO do not know how to treat if number:min-integer-digits="0"
This special case should be treated.
Comment 28 Laurent BP 2016-05-03 19:54:53 UTC
Steps to easily reproduce:
1. Open Gnumeric
2. Format > Cells > Format > Number
3. Select Fraction and set "Minimum number of denominator digits:" to 0
4. Save as ODF 1.2 Extended, Close
5. Open with LibO

Actual behavior:
Format is General

Expected behavior:
Fraction format should be kept

Verified with Version: 5.1.3.1 (x64)
Build ID: 115e0e13d3c8ac1452186ad2394abce2dd5c2b57
Threads CPU : 4; Version de l'OS :Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR)
Comment 29 Laurent BP 2016-05-03 20:04:38 UTC
A simple fix would be, while max-denominator-digits is not treated by LibO, to force min-denominator-digits to at least 1 when creating format string:
http://opengrok.libreoffice.org/xref/core/xmloff/source/style/xmlnumfi.cxx#1218
Comment 30 Eike Rathke 2016-05-09 14:56:38 UTC
What are 0 min-denominator-digits good for?
Comment 31 Commit Notification 2016-05-09 14:56:58 UTC
Laurent Balland-Poirier committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a75aa73b2bf793faac1adb3b5f67e09d252d5fe9

tdf#38097 min numerator/denominator at least 1

It will be available in 5.2.0.

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.
Comment 32 Commit Notification 2016-05-25 15:44:41 UTC
Laurent Balland-Poirier committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f599fb158d5a94128e9eb28b6787f5116df9e8b&h=libreoffice-5-1

tdf#38097 min numerator/denominator at least 1

It will be available in 5.1.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.