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.
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!
Created attachment 47758 [details] Please see Comment 1
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.
Replace whiteboard status "UNCONFIRMED" with a move to status "NEEDINFO" for unassigned new bugs.
needinfo keyword redundant by needinfo status.
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
What information were you asking for that hadn't been submitted????
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.
@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.
(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.
@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.)
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.
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.
(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!
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.
Version is the first version reported. Please don't change that.
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.
(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...
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.
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...
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.
Should be set to NEW not REOPENED. If the bug has been fixed in the mean time please set to RESOLVED -> WORKSFORME. Thanks
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
(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.
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)
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
What are 0 min-denominator-digits good for?
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.
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.