Bug 31449 - Calc doesn't save user-defined format string
Summary: Calc doesn't save user-defined format string
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Laurent Balland
URL:
Whiteboard: numberformat target:5.2.0 target:5.1....
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-07 14:16 UTC by Alexander O. Anisimov
Modified: 2023-10-11 13:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander O. Anisimov 2010-11-07 14:16:50 UTC
Example of the issue:
1. Open calc and type in A1 cell "=0.2", in A2 type "=1.2". Then select these cells, go to Format-Cells, on the tab "Numbers" in the list "Category" select "User-defined" and in "Format string" type "#/#" (without quotes).
2. Now you can see "1/5" in A1 and "6/5" in A2.
3. Save document. Close LO.
4. Open document again. And now you can see "1/5" in A1 and "1 1/5" in A2. The cell's format changed to "# ?/?"
Comment 1 Kohei Yoshida 2010-11-07 17:00:39 UTC
Confirmed.  I'm taking this.
Comment 2 Kohei Yoshida 2011-01-04 16:12:24 UTC
Looks like the next significant release will be 3.4, not 3.3.1.  Resetting the target accordingly.
Comment 3 Kohei Yoshida 2011-05-06 15:39:29 UTC
Ah, this may be an ODF number format mapping issue.  Saving it as xls preserves the format just fine.

The relevant code to look at is SvXMLNumFmtExport::ExportPart_Impl() in xmloff.
Comment 4 Kohei Yoshida 2011-05-06 15:45:13 UTC
I don't know what '#/#' is supposed to mean exactly, but it gets only saved as

<number:fraction number:min-integer-digits="0" number:min-numerator-digits="1" number:min-denominator-digits="1"/>

when saved as ods.  And I guess the number format code gets re-created on import from that above xml element data, which gets mapped to "# ?/?".
Comment 5 Kohei Yoshida 2011-05-06 16:14:40 UTC
I guess this has been a long-standing issue not something new.  And unfortunately, fixing this will involve making changes to the ODF specification.  So we cannot do that in a hurry.

I'll punt this for later.
Comment 6 Alexander O. Anisimov 2011-05-06 20:41:28 UTC
'#/#' represent digit as improper fraction and '# ?/?' represent digit as proper fraction.

If I understood you correctly, at the present time, two different formats generate the same xml.

Is it possible to use number:max-integer-digits="0" (instead of|together with) min-integer-digits? I think this can solve the problem. Or it is not in odf specification?
Comment 7 Kohei Yoshida 2011-05-06 20:55:17 UTC
(In reply to comment #6)

> Is it possible to use number:max-integer-digits="0" (instead of|together with)
> min-integer-digits? I think this can solve the problem. Or it is not in odf
> specification?

That attribute is not in the specification yet.  But we may be able to propose something like that as amendment to the current spec.
Comment 8 Roman Eisele 2012-05-03 09:57:30 UTC
This is a Calc issue, therefore changed the 'Component' field accordingly.
Comment 9 Kohei Yoshida 2012-06-01 11:42:04 UTC
This one is for Eike.
Comment 10 Eike Rathke 2012-06-06 14:11:36 UTC
Damn, someone discovered an undocumented feature of the number formatter ;-)

Ok, I think we can solve this only by enhancing the ODF spec, the number:fraction element doesn't provide means to store this, see http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#element-number_fraction
Comment 11 Horst 2012-10-26 20:09:53 UTC
May I complete the confusion.
Excel keeps the "#/#" format even it is sort of illegal.
Why not just change the "#/#" to the correct "?/?" and problem solved.
Comment 12 retired 2014-02-12 14:47:29 UTC
Eike, are you still on this?
Comment 13 QA Administrators 2014-10-23 17:32:04 UTC Comment hidden (obsolete)
Comment 14 Matthew Francis 2015-04-07 05:36:33 UTC
There's no loss of data involved per se, it's just a feature that ODF itself doesn't support yet. I think it's appropriate to label this as an enhancement.

-> Severity: enhancement
Comment 15 Laurent Balland 2016-04-27 20:23:06 UTC
As a first fix, I think there is no need for ODF specification modification.
LibO should read #/# as ?/? and there will be no integer part.
Code is here:
http://opengrok.libreoffice.org/xref/core/xmloff/source/style/xmlnumfe.cxx#1456

  if ( pElemStr && (*pElemStr)[0] == '?' )

may be replaced with

  if ( pElemStr && ( (*pElemStr)[0] == '?' || (*pElemStr)[0] == '#' ) )

to take into account both cases where format has no integer part.
Comment 16 Laurent Balland 2016-04-30 19:56:22 UTC
(In reply to Laurent BP from comment #15)
>   if ( pElemStr && (*pElemStr)[0] == '?' )
> 
> may be replaced with
> 
>   if ( pElemStr && ( (*pElemStr)[0] == '?' || (*pElemStr)[0] == '#' ) )
> 
> to take into account both cases where format has no integer part.

I was wrong. Test must be rewritten, as it tests format  "? ??/??" as true.
New proposition:
https://gerrit.libreoffice.org/24540/
Comment 17 Commit Notification 2016-05-03 11:57:53 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=3beb146b34fa931e2d63f4738a3ae69fe286545f

tdf#31449 Correctly test if fraction has no integer part

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 18 Commit Notification 2016-05-25 15:43:14 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=f3de0caba189ff7d17a2f37495147673e68c2e7f&h=libreoffice-5-1

tdf#31449 Correctly test if fraction has no integer part

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.
Comment 19 Buovjaga 2023-10-11 13:16:13 UTC
Notes for unit test writers:

At the moment requires a (trivial) manual revert for svl/source/numbers/zformat.cxx

A bit similar is the test for bug 70565 in 9b9bcef5ef1858c63c8708bfae2ecea3d398eeb8 (XLSX import)

The functioning of formats themselves is tested in svl/qa/unit/svl.cxx Test::testUserDefinedNumberFormats()