Steps: 1. Open attachment 74944 [details] from bug 60957 2. Save it as .DOCX 3. Open the new .DOCX file Observed behaviour: Layout has changed. Besides, if the saved document is open in MSO Word it contains 2 pages instead of one Reproduced in: Version: 5.4.0.0.alpha0+ Build ID: 7a1add76d542e9929c1feab9e06949990e236616 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Tamás Zolnai <tamas.zolnai@collabora.com> 2016-10-28 15:24:51 (GMT) committer Tamás Zolnai <tamas.zolnai@collabora.com> 2016-10-28 14:10:41 (GMT) commit b927c1f4b334f80d2c2965e5b7327d6b6a685105 (patch) tree 81c858f4a49ac09608294088bb2ecab77b93be5a parent 8a22bc93e0988188a87c0a787a9b32a7f74da84d (diff) tdf#103544: DOCX exp.: Image loss when have a frame anchored to the same para. Regression from: 83d51e5e52688c4c9bc0ad70a511458bb06a242d Partly revert the commit causes this regression. I checked the related bugs (tdf#78590,tdf#80748) intended to be fixed by this commit and reverting this part does not bring back the corruption. I guess something changed in frames' and text boxes' import in the meantime, because this MergeMarks::IGNORE is useless now. Adding Cc: to Tamás Zolnai
Created attachment 131842 [details] MobileClientWorkReport - Customer 533455 Job 4528264.pdf: created by Word 2013
Created attachment 131843 [details] MobileClientWorkReport_beforeRegression.pdf: output from LO bibisect before the supposed regression I would not call this a regression. The result of round-tripping this document before Tamás' commit was hardly correct/usable. Primarily, the substitution of the database internals instead of the database record data is the biggest problem in round-tripping. After the so-called regression, more data is shown (because before it was simply discarded) and thus everything shifts down on the page.
Created attachment 131844 [details] MobileClientWorkReport_afterRegression.pdf: output from LO bibisect after the supposed regression
According to the previous comment, I remove "regression". But I don't see the point of this bug. Fileopen is wrong in bug 60957, surely RT will also be wrong. Since Xisco confirmed his own bug, I set back to Unconfirmed for a second opinion.
(In reply to Timur from comment #5) > According to the previous comment, I remove "regression". > But I don't see the point of this bug. Fileopen is wrong in bug 60957, > surely RT will also be wrong. Since Xisco confirmed his own bug, I set back > to Unconfirmed for a second opinion. Just for the record, I confirmed my own bug because I bisected and we have a rule of thumb that bisected bugs can be set to NEW automatically.
The round tripping problem - where database fields do not only print the result, but also "User Field XXXXX = " - is likely inherited from OOo. using linux bibisect43all -oldest (3.5): opens poorly, saves only a small portion of the doc, and opens with "User Field xxx =" -last36onmaster: opens poorly, saves OK, and opens with "User Field xxx =" -last40onmaster: cannot open the test document -last41onmaster: opens poorly, cannot save the test document -last42onmaster: opens poorly, cannot save the test document -last43onmaster: opens better, saves OK, and opens with "User Field xxx =" When saving as .odt, the field variable is preserved as in the original. When saving as .doc, only the text of the field value is saved, but the variable itself is lost. When saving as .docx, both the text of the field name and the field value are saved, but the variable itself is lost.
Created attachment 132906 [details] UserField.odt: a minimal test document. Field lost when saving as .docx and .doc
** 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
fixed for DOCX in LO 7.0 by commit 676862bb8aa043f116615e5d0dac59254eaa8138 Author: Miklos Vajna on Thu Jan 30 10:21:08 2020 +0100 DOCX export: implement support for user fields Updating the field doesn't work yet, that'll need additional markup in settings.xml. Change-Id: I562ae62cebcbd5ca474bd0f7a181773f8e515f5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87720
If commit is known (thanks to Justin) than it's Fixed, but if it's already in a bug, looks like we may duplicate. *** This bug has been marked as a duplicate of bug 68140 ***