Download it now!
Bug 86359 - [Mail Merge] "Save as single document" (following File> Print > Mail Merge) had wrong output due to invalid "office:value" in XML
Summary: [Mail Merge] "Save as single document" (following File> Print > Mail Merge) ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
Reported: 2014-11-17 00:44 UTC by minhsien0330
Modified: 2017-12-18 08:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

The procedure to show the bug. (2.34 MB, image/jpeg)
2014-11-17 00:47 UTC, minhsien0330
The spreadsheet for registering database. (29.41 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-17 00:50 UTC, minhsien0330
The odt file for testing this Mail Merge bug. (12.23 KB, application/vnd.oasis.opendocument.text)
2014-11-17 00:51 UTC, minhsien0330

Note You need to log in before you can comment on or make changes to this bug.
Description minhsien0330 2014-11-17 00:44:21 UTC
Problem description: 
The result of "Save as single document" was wrong.

Steps to reproduce:
1. I illustrate the procedure in the attachment "demo.jpg", please take a look.
2. I upload 2 files for your testing. (bug-spreadsheet.ods and bug-mail_merge.odt)

Current behavior:
The result of "Save as single document" was wrong.

Expected behavior:
The result of "Save as single document" should be correct.
Comment 1 minhsien0330 2014-11-17 00:47:00 UTC
Created attachment 109573 [details]
The procedure to show the bug.
Comment 2 minhsien0330 2014-11-17 00:50:38 UTC
Created attachment 109574 [details]
The spreadsheet for registering database.
Comment 3 minhsien0330 2014-11-17 00:51:30 UTC
Created attachment 109575 [details]
The odt file for testing this Mail Merge bug.
Comment 4 Cor Nouws 2014-11-17 12:34:32 UTC
just clarifying the summary - thanks for your report!
Comment 5 minhsien0330 2014-11-17 14:14:26 UTC
I tried Libreoffice, and this bug still there.
Thank you.
Comment 6 Buovjaga 2014-11-22 15:14:10 UTC
(In reply to minhsien0330 from comment #1)
> Created attachment 109573 [details]
> The procedure to show the bug.

When ouput to file, value of 10/03 and 10/10 are 0.

Changed severity, please refer to this flowchart:

Win 7 64-bit Version:
Build ID: a81027b13f1696c1cb2e8bcae3d712a193ff2dfd
TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-11-21_23:15:5
Comment 7 Matthew Francis 2015-04-11 07:59:50 UTC
I get the same result from Linux / LO 3.3.0

-> Version: Inherited from OOo
Comment 8 tommy27 2016-04-16 07:29:03 UTC Comment hidden (obsolete)
Comment 9 minhsien0330 2016-04-17 06:54:16 UTC
LO 5.1.2 still has this bug.

OS: Debian (32 bit)
Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f
CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; 
Locale: zh-TW (zh_TW.UTF-8)
Comment 10 Jan-Marek Glogowski 2016-05-01 14:12:34 UTC
The origin of the problem is the replacement of fields with text strings during single document generation and the cell number formatting of the Writer table.

While the field exists, it gets the formatting and displayed value from the Calc sheet / DB, independent from the Writer cell formatting.

For a new table all cells are set to string and it's not changed, if you move a field from the DB source view into the cell.

But if you have a different number format assigned to the cell, the default value is assigned to the cell, e.g. office:*-value="1899-12-30" for a date. This doesn't affect the formatting of the cell while it's a field.

But when converting the the field to text during mail merge, the text becomes affected by the cell formation. In fact the text is ignored and the cell shows the invalid "office:*value", which is based on the default value when the field was added to the cell, based on the cell number formatting.

Example XML from the merged document:

<table:table-cell table:style-name="表�| �1.A2" office:value-type="float" office:value="0">
  <text:p text:style-name="P3">98</text:p>

Now my current idea to fix this confusion is to change the cell value to string when merging the field. As we already creating a "working source" copy, this can be done at the beginning of the merge. Loosing the Writer table cell formatting for the merged document should not be a problem (famous last words).
Comment 11 Jan-Marek Glogowski 2016-05-01 14:15:38 UTC
I want to change the cell type to "string" and not the cell value, so the actual string content of the cell is displayed.
Comment 12 QA Administrators 2017-10-23 14:08:58 UTC Comment hidden (obsolete)
Comment 13 Timur 2017-10-23 16:24:09 UTC
Looks fine in 5.3. and 6.0. Didn't test with previous versions. 
Looking at XML, it says  office:value-type="string">
Jan-Marek might have fixed that with 
Of course, others should also test.