Steps: 1. Open attachment 73104 [details] from bug 59426 2. Save it as .DOCX 3. Open the new .DOCX file Observed behaviour: Title is at incorrect position after RT 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
** 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
Repro 7.0+ as of today.
Created attachment 160972 [details] Screenshot of the minimized document in Writer before and after saving The original frame has Wrap: None set, this is imported correctly, but it's then exported as Wrap: Through Version: 7.0.0.0.alpha1+ (x64) Build ID: 557c6777ad33b54af28541a96bcf91596995b388 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: hu-HU (hu_HU); UI: en-US Calc: CL
Created attachment 160973 [details] Minimized document
Another fun detail (probably for a separate bug): The original document has two frames after each other, anchored to the same paragraph. These are imported as a single frame, with the alignment etc settings of the first and combined text of both.
The export wrap of the frame is now fixed with bug #133924 We can keep this one for the part where two frames become one on import.
Hi Nisz, I see you doing a lot of reviews and retests which is great. Sometimes like here you notice that original issue was fixed but you keep the bug for some other issue, which is fine, I do the same. Only, in those cases, please also rename bug and add "per comment .." to focus immediately. I do it here.
The bibisect/regression information is now obsolete. I tested the two frames combining into one with LO 3.5 and it was already happening at that time, so likely inherited from OOo.
*** Bug 127622 has been marked as a duplicate of this bug. ***
The two frames are different because style Cm has a <w:framePr w:w="9360" while style Authors has a <w:framePr w:w="9072"
Created attachment 186488 [details] TRANS-JOUR_min2.docx: modified example, where the two frames overlap Even though the original file (TRANS-JOUR_min.docx) has two framePr's that have the same vertical distance of 0, they don't overlap. However, in this version2, it does overlap (in MS Word 2010), but only until you look at the properties of the bigger frame and then hit OK. So Word is a bit flaky in how it lays out frames. Great.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e0e33aa622968bc2e182099670a024a1d00b8e5c tdf#105035 tdf#127622 writerfilter framePr: compare using style info It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cbdd54e41a78e6a567d7ff97935721b07461cce5 tdf#105035 writerfilter framePr: don't allow overlap in extreme case It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'll mark this as fixed and close it. There is still a problem - the order of the frames is reversed. But I don't know what could be done about that. After all, the frames really ought to overlap - since they specify the same X,Y coordinates. The only reason one "should" come before the other is because it is defined first. I assume our layout code just finds the shorter one and the larger one ends up second. In any case, it will be layout/wrap related code. Better to just have the user move things around and export proper coordinates.