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.
Created attachment 109573 [details] The procedure to show the bug.
Created attachment 109574 [details] The spreadsheet for registering database.
Created attachment 109575 [details] The odt file for testing this Mail Merge bug.
just clarifying the summary - thanks for your report!
I tried Libreoffice 4.3.4.1, and this bug still there. Thank you.
(In reply to minhsien0330 from comment #1) > Created attachment 109573 [details] > The procedure to show the bug. Reproduced. When ouput to file, value of 10/03 and 10/10 are 0. Changed severity, please refer to this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Win 7 64-bit Version: 4.5.0.0.alpha0+ Build ID: a81027b13f1696c1cb2e8bcae3d712a193ff2dfd TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-11-21_23:15:5
I get the same result from Linux / LO 3.3.0 -> Version: Inherited from OOo
** 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.5 or 5.1.2 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 If 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: 2016-04-16
LO 5.1.2 still has this bug. OS: Debian (32 bit) Version: 5.1.2.2 Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: zh-TW (zh_TW.UTF-8)
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> </table:table-cell> 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).
I want to change the cell type to "string" and not the cell value, so the actual string content of the cell is displayed.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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 https://gerrit.libreoffice.org/#/c/26435/. Of course, others should also test.