45521 – [FILEOPEN] LibO Writer changes decimal delimiter when opening a sdw file which causes data loss after saving

Bug 45521 - [FILEOPEN] LibO Writer changes decimal delimiter when opening a sdw file which causes data loss after saving

Summary: [FILEOPEN] LibO Writer changes decimal delimiter when opening a sdw file whic...

Status:	CLOSED FIXED

Alias:	None

Product:	LibreOffice
Classification:	Unclassified
Component:	Writer (show other bugs)
Version:	3.5.0 RC2
Hardware:	All All

Importance:	medium major
Assignee:	Caolán McNamara
QA Contact:

URL:
Whiteboard:	target:3.6.0 target:3.5.2
Keywords:

Depends on:
Blocks:	mab3.5
	Show dependency tree / graph

Reported:	2012-02-01 18:02 UTC by Boostland
Modified:	2012-04-04 09:04 UTC (History)
CC List:	3 users (show)

See Also:
i915 platform:
i915 features:

Attachments
Document that shows data loss bug when converted (44.00 KB, application/vnd.stardivision.writer) 2012-02-01 18:02 UTC, Boostland	Details
Document that shows data loss (15.39 KB, application/vnd.oasis.opendocument.text) 2012-02-01 18:05 UTC, Boostland	Details
Document that shows data loss 3.5RC2 (15.46 KB, application/vnd.oasis.opendocument.text) 2012-02-01 18:17 UTC, Boostland	Details
hackaround (725 bytes, patch) 2012-03-13 16:41 UTC, Caolán McNamara	Details \| Splinter Review
View All

Description Boostland 2012-02-01 18:02:56 UTC

Created attachment 56485 [details]
Document that shows data loss bug when converted

Open sdw file save as odt or sxw close then reopen file and some data is changed or lost, this happens on both the 3.5.0 RC2 and on 3.4.5 final.

This bug does not appear to be in the 3.3.4 release.

It is a major flaw as data loss can go unnoticed.

Comment 1 Boostland 2012-02-01 18:05:19 UTC

Created attachment 56486 [details]
Document that shows data loss

Document showing data loss when converted when saved from LO 3.4.5

Comment 2 Boostland 2012-02-01 18:17:41 UTC

Created attachment 56488 [details]
Document that shows data loss 3.5RC2

Comment 3 Boostland 2012-02-05 15:46:04 UTC

Still broken in the 3.5 RC3 for odt & sxw

However saving to a docx file seems to work

Comment 4 Cor Nouws 2012-02-06 00:15:00 UTC

Thanks for reporting.

I can confirm:
- After conversion, saving and re-opnening document "Invoice3.3.4.sdw" in 3.5.0rc3
the numbers in E3, E4, E5 are gone and the number is 0,00

- I notice that in 3.5.0 the other cells the numbers have a comma as decimal delimiter. And in E4, 5, 6 it is an dot.
And the cell format is for all cases "Currency AUD $ ENglish Australia" with the comma as decimal delimiter.

- Opening document "Invoice3.3.4.sdw" in 3.3.0 shows a comma as delimiter also in E4, E5 and E6.

So to me this seems a problem with the import of the numbers.

I test this on Linux 32bits, so set the platform and OS to all.

Comment 5 Eike Rathke 2012-02-06 13:49:00 UTC

Note that the decimal separator you see depends on your system's locale, as the number format's locale is set to Default. Only the currency symbol is defined to be AUD $ Australian Dollar. The cells that appear with $0.00 after having saved/reloaded the document are stored with office:value='0' in the .odt file. The textual representation in the <text:p> element is still correct though.

@mstahl: cell content incorrectly remembered as text somehow after having imported the .sdw?

Comment 6 Boostland 2012-03-05 16:52:51 UTC

This bug is still present in the 3.5.1 rc1

Comment 7 Caolán McNamara 2012-03-13 16:41:53 UTC

Created attachment 58406 [details] [review]
hackaround

FWIW the attached would make it work, probably with some unknown side-effects. But points to the absence of content in xText for these cells for the lack of export of the "office:value" from binfilter in the first place. At some stage it seems the rules for these formulas in writer changed and binfilter diverged from non-binfilter I suspect. A bit of side-by-side debugging of sw and bf_sw for the xText value seems indicated.

Comment 8 Boostland 2012-03-13 17:26:51 UTC

Still broken in 3.4.6 RC1 and 3.5.1 RC2

Comment 9 Caolán McNamara 2012-03-14 03:04:06 UTC

0a063583 seems to be what broke it

Comment 10 Not Assigned 2012-03-14 05:14:43 UTC

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=cfa62900291dc2d89793044a045ac1f29ca8b128

Resolves: fdo#45521 restore ascii export for getTextFromPam

Comment 11 Caolán McNamara 2012-03-14 07:42:28 UTC

fixed for 3.6 anyway, requested review for 3.5

Comment 12 Not Assigned 2012-03-15 04:24:50 UTC

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=a73d29c70cf5cc6ffeddfd5c5dada55a30d55fcc&g=libreoffice-3-5

Resolves: fdo#45521 restore ascii export for getTextFromPam


It will be available in LibreOffice 3.5.2.

Comment 13 Boostland 2012-03-19 14:55:09 UTC

This bug is also affecting the 3.4.6 RC2

Comment 14 Cor Nouws 2012-04-04 09:04:37 UTC

(In reply to comment #11)
> fixed for 3.6 anyway, requested review for 3.5

Is correct in 3.5.2.2 - thanks!
3.4.6 is the last in that line > close this bug

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.