Created attachment 143427 [details] sample file Steps to reproduce: 1. Open attached document 2. Save is as .DOC 3. Open the new file -> the vertical line in the middle is on top and horizontal after RT Reproduced in Version: 6.2.0.0.alpha0+ Build ID: c290f692dd28094d41dff686f3faa1c4e14b556e CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded [Bug found by office-interoperability-tools]
regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=1cedd88d40a26a55ce433f8b742215aea83a5382 author Justin Luth <justin_luth@sil.org> 2018-06-28 15:48:40 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2018-06-29 07:43:40 +0200 commit 1cedd88d40a26a55ce433f8b742215aea83a5382 (patch) tree 2104981b42e82ef069992eb94a1cd71b4151e81e parent e20b14e1e9f22a4ac55a7c9e6160f0b7665ff24d (diff) tdf#118421 ww8export: rotate vertically: not Lines or groups Bisected with: bibisect-linux64-6.2 Adding Cc: to Justin Luth
Created attachment 143448 [details] Microsoft Word2003 - CrashingRT.pdf - position still not correct before regression Good: this is not a regression that anyone will notice since it was only working for a couple of days since bug 118421 fixed regressions caused by the fix for bug 70838.
I'm going to remove regression since it never affected a released version. And I'm probably going to wash my hands from this since I don't intend to get into shape fixing. But this is a good document to add to the "complicating factors" of handling rotated shapes.
Dear Xisco Faulí, 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.1+
In the following version the line is vertical after the roundtrip to DOC, but slightly displaced compared to the original: LO 7.3.0.0.alpha0+ (36efb384a66b6dd645e0ae80fd7df68370a9dc8b) / Ubuntu.
Created attachment 174409 [details] sample compared sa DOC and DOCX in LO and MSO
Improvement in 7.2: commit e11c40ab22cfe2daeb80698ba9d27894d8f3d2e6 Date: Tue Jul 20 13:32:49 2021 +0200 source ae0c6da13c9b92757ff0f4ba360308ee50c701cf author Hossein <hossein@libreoffice.org> tdf#123321 Fix DOC/DOCX export bug which made some lines disappear
I can no longer reproduce this problem with LO 7.5, and LO 7.6 dev. The vertical line is placed in the same position before and after saving to .doc and reload. This is nearly identical to what MSO shows. The only difference is that MSO shows 1 page, and LO shows 2 pages, which seems to be unrelated to this issue. Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0a6db8c2d6fdf5cb2dfad9381f82f730021a9a9d CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded
I could bisect the fix, and I should say that the previous commit, ae0c6da13c9b92757ff0f4ba360308ee50c701cf has already fixed the problem with the lines. The new patch from Vasily, fixed the problems with the tables (tdf#148578). Now, the output is nearly similar to the output from MS Word. $ git bisect log git bisect start # bad: [f6782ca20a5b0405beffdea4062a99cd043ffe9f] tdf#155179 Replace in Solver "=>" with ">=" git bisect bad f6782ca20a5b0405beffdea4062a99cd043ffe9f # good: [50add7c97e75d604287218f49c9283aab052fdf0] tdf#148253: fix matching algorithm git bisect good 50add7c97e75d604287218f49c9283aab052fdf0 # good: [56b5046e03d2db684fe35239acfea553ff7d9b7f] _MSC_VER is more appropriate to guard MSVC-specific #pragma git bisect good 56b5046e03d2db684fe35239acfea553ff7d9b7f # bad: [a21aad5e084e3901a1e216ef9006b0f8b6132c39] tdf#153341: try to parse alpha value when copying HTML text git bisect bad a21aad5e084e3901a1e216ef9006b0f8b6132c39 # good: [5816474c37293cc791fdb9cb042d11be7d809d0b] Update git submodules git bisect good 5816474c37293cc791fdb9cb042d11be7d809d0b # bad: [af27dabe816666945b02cd31bb6d6f9d84f732c0] mbDragDrawn is always false when queried git bisect bad af27dabe816666945b02cd31bb6d6f9d84f732c0 # good: [29c2bba1f3ef216d226c97197185066880fc1ab5] svx: use array for colors in ColorSet, add consts, rename vars git bisect good 29c2bba1f3ef216d226c97197185066880fc1ab5 # good: [f011a13b3e9d3edf85fa8cb17d612934e589e672] writerfilter: removed remains of GAP_HALF define and its usage git bisect good f011a13b3e9d3edf85fa8cb17d612934e589e672 # bad: [13810281fe1297833a849bf5adea0be8ea77ca88] Resolves: tdf#152950 don't set_active while frozen git bisect bad 13810281fe1297833a849bf5adea0be8ea77ca88 # bad: [42d9077fc4ffc35d769412a979d91e836adb2536] Missing include git bisect bad 42d9077fc4ffc35d769412a979d91e836adb2536 # good: [81e6d47635656297cdddc9030f4422c0bcc203f9] tdf#152896 do not apply color shading twice git bisect good 81e6d47635656297cdddc9030f4422c0bcc203f9 # good: [4ddfdeefe78e725b8d28fd60dbe32e7f4f054724] remove dead code git bisect good 4ddfdeefe78e725b8d28fd60dbe32e7f4f054724 # good: [3babbc31bf4bba35924c25c5fbd59e1c314d3627] Revert "Resolves tdf#143100 - Disable cell style commands when sheet is protected" git bisect good 3babbc31bf4bba35924c25c5fbd59e1c314d3627 # good: [5c4fa7ddb0b12d30304bbc6119a0aa1d3d65b55d] Fix deprecated Curl elements for minidump part git bisect good 5c4fa7ddb0b12d30304bbc6119a0aa1d3d65b55d # bad: [788cc6ff3b186ceb8f265e53b5482f808f6536f4] tdf#148578: Do not apply table shift for RTF git bisect bad 788cc6ff3b186ceb8f265e53b5482f808f6536f4 # good: [8ae84bb5566e12df64236a116b9d1889d6f5f052] Update git submodules git bisect good 8ae84bb5566e12df64236a116b9d1889d6f5f052 # first bad commit: [788cc6ff3b186ceb8f265e53b5482f808f6536f4] tdf#148578: Do not apply table shift for RTF 788cc6ff3b186ceb8f265e53b5482f808f6536f4 is the first bad commit commit 788cc6ff3b186ceb8f265e53b5482f808f6536f4 Author: Vasily Melenchuk <vasily.melenchuk@cib.de> Date: Thu Jan 5 18:17:12 2023 +0300 tdf#148578: Do not apply table shift for RTF Table shift based on cell lect margin should be applied for DOCX (earlier compat options) but not actual for RTF. Maybe earlier RTF version did behave this way, but nowadays this behavior does not match MS Word 365. Change-Id: Icdc4fa6298167fe5f263c85164d7c4c4176be25f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145088 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>