Created attachment 148320 [details] Sample DOCX The attached DOCX was created in Word, and has two crossing lines (like a +). When it's opened in Writer, the lines are shown as | (both lines are there, but the one supposed to be the - is just a point). Observed using LO 6.2.0.2 / Windows 7. No issue in 6.1.0.3. => regression Bibisected to the following commit using repo bibisect-win32-6.2. Adding Cc: to Armin Le Grand. The commit is the same as in bug 118693, but the symptom seems to be somewhat different. https://cgit.freedesktop.org/libreoffice/core/commit/?id=36bade04d3780bc54c51b46bb0b63e69789658a5 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-06-28 19:48:59 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-07-02 18:03:44 +0200 tdf106792 Get rid of SvxShapePolyPolygonBezier
Confirm. Version: 6.3.0.0.alpha0+ Build ID: e8bee017fb46
*** Bug 127364 has been marked as a duplicate of this bug. ***
I have used the attachment of the duplicate bug 127364 for some investigations: The problem is related to the length of the line. For example 18cm shows the error, but 17.9cm and 18.1 cm are OK. During opening, the method SdrPathObj::NbcSetSnapRect() [svdopath.cxx#2379] is called. With the 18cm line length the rectangle aOld is LT[4530,53] and RB[4530,10257], and rRect is LT[4530,53] and RB[4531,10258]. So that later nDivY != nMulY and therefor not forced to 1. The following call of SdrPathObj::NbcResize then calculates for fResizeY a value different from 1.0. That results in a call of SdrTextObj::NbsResize [svdptxtr.cxx#106] and then a call of Poly2Rect from svdtrans.cxx#486 in turn. And there the bad rotation happens. Whereas in case of 18.1cm the rectangle aOld is LT[4530,53] and RB[453010314], and rRect is LT[4530,53] and RB[4513,10314]. So in this case nDivY == nMultY and therefor forced to 1. The following call of SdrPathObj::NbcResize then calculates both fResizeX and fResizeY as 1.0 and aborts. The method has an hint to bug 106792 in its comment, why the abort is necessary. (For further investigation it is too late in the night for me.)
The same commit is also responsible for the shorter fuchsia-coloured lines in https://templates.office.com/en-us/Fashion-newsletter-TM16412247 as discussed in https://www.dedoimedo.com/computers/libreoffice-7-review.html
The line is vertical since https://cgit.freedesktop.org/libreoffice/core/commit/?id=c9e5640c8fcad7beb42a66f9bee0252eee9fe323
Repro 7.2+. Not fixed with other meta bugs.
*** Bug 141120 has been marked as a duplicate of this bug. ***
(In reply to Regina Henschel from comment #3) > I have used the attachment of the duplicate bug 127364 for some > investigations: > > The problem is related to the length of the line. For example 18cm shows the > error, but 17.9cm and 18.1 cm are OK. > > During opening, the method SdrPathObj::NbcSetSnapRect() [svdopath.cxx#2379] > is called. With the 18cm line length the rectangle aOld is LT[4530,53] and > RB[4530,10257], and rRect is LT[4530,53] and RB[4531,10258]. So that later > nDivY != nMulY and therefor not forced to 1. > The following call of SdrPathObj::NbcResize then calculates for fResizeY a > value different from 1.0. That results in a call of SdrTextObj::NbsResize > [svdptxtr.cxx#106] and then a call of Poly2Rect from svdtrans.cxx#486 in > turn. And there the bad rotation happens. > > Whereas in case of 18.1cm the rectangle aOld is LT[4530,53] and > RB[453010314], and rRect is LT[4530,53] and RB[4513,10314]. So in this case > nDivY == nMultY and therefor forced to 1. The following call of > SdrPathObj::NbcResize then calculates both fResizeX and fResizeY as 1.0 and > aborts. The method has an hint to bug 106792 in its comment, why the abort > is necessary. > > (For further investigation it is too late in the night for me.) In my case I didn't think it was the length, but the width; if the line is a line which never had any arrows it was fine for me; but if the line has (or previously had) start/end arrows then the width is none-0 and gets passed NbcResize's check. That check replaced a different hack that was taken out by Armin's patch - which added 1 to a width somewhere to stop this happening.
*** Bug 141239 has been marked as a duplicate of this bug. ***
Similar to bug 118693, it might be that https://cgit.freedesktop.org/libreoffice/core/commit/?id=36bade04d3780bc54c51b46bb0b63e69789658a5 just uncovered a previous hack
So, I analyzed this isssue a bit. Initially, the horizontal/vertical problem was fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=627c2469843c9461b665c4571f1214aca7fc36a4 ( bug 96674 ). Later, in commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=36bade04d3780bc54c51b46bb0b63e69789658a5, the code introduced in 627c2469843c9461b665c4571f1214aca7fc36a4 was reverted, with the comment "I doubt that the additional code to make a line not exactly hor/ver is needed. Checked and it is not needed, thus removed the change from tdf#96674 in shape.cxx." maybe it's still needed ?
Proposed patch: https://gerrit.libreoffice.org/c/core/+/113102
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3e4eb070787d4d44b3bdc95046e5b231dbbef42b tdf#122717: fix handling of zero width/height lines It will be available in 7.2.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.
My commit should fixed the vertical vs horizontal problems. For other problems, please create a new ticket! Testing is appreciated.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/11d344f6271e4171f8006c2cb29372f612cbdc00 tdf#122717: fix handling of zero width/height lines It will be available in 7.1.3. 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.
Thanks; confirmed it fixes it on head. I did look at this hack that was removed; but I never figured out why it's needed; what is it that treats horizontal lines specially - and why? I realise there's code to fix up the rotation to make sure text follows line roation - but it's not clear to me what the horizontal case is special; or for that matter whether the rotation variables are well defined.
(In reply to Xisco Faulí from comment #14) > My commit should fixed the vertical vs horizontal problems. For other > problems, please create a new ticket! Testing is appreciated. Better test and reopen duplicate bugs.
(In reply to Timur from comment #17) > (In reply to Xisco Faulí from comment #14) > > My commit should fixed the vertical vs horizontal problems. For other > > problems, please create a new ticket! Testing is appreciated. > > Better test and reopen duplicate bugs. duplicated bugs are also fine with regards to horizontal/vertical display so they shouldn't be reopened.
Thanks Xisco. I'm removing tag "test" then. Glad you managed to fix couple of annoying bug by reverting. And with all UI tests you make, your work is very important. For those who don't follow Lo development closely, let be explain. Lo had large development, but that also included a lot of regressions. When project got QA engineer, things definitely got better. It included different automation, but now increasingly also code, UI etc. So my congrats and hopes that Lo will be even better, chiefly reliable.
Created attachment 170789 [details] PDF export from Word My mistake, I haven't added a reference before, here it is. The line is now horizontal, but it isn't in the correct position, and not of the correct size. Tested using LO 7.2.0.0.alpha0+ (db7b7d43169e3029d3dd71e287e9c2ccbcce1f77) / Ubuntu.
Created attachment 170790 [details] Comparison screenshot (7.2 vs. 6.1)
(In reply to Xisco Faulí from comment #14) > My commit should fixed the vertical vs horizontal problems. For other > problems, please create a new ticket! Testing is appreciated. Hi Aron, please see my comment. Please, report it in a new report
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/8ff2119a06df1fae0447b21507878fbd34149488 tdf#122717: fix handling of zero width/height lines It will be available in 7.0.6. 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.
Hello, I confirm that the 7.1 nighly build fixes the problem. A vertical line is displayed in vertical orientation, at the position and the size I expect.
Let's mark this one verified based on comment 20 and comment 22, thanks for fixing, Xisco!
*** Bug 132502 has been marked as a duplicate of this bug. ***
*** Bug 104601 has been marked as a duplicate of this bug. ***
*** Bug 140087 has been marked as a duplicate of this bug. ***