Bug 122717 - FILEOPEN DOCX: Horizontal line has wrong size/position and vertical line rendered horizontally
Summary: FILEOPEN DOCX: Horizontal line has wrong size/position and vertical line rend...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.3 target:7.0.6
Keywords: bibisected, bisected, regression
: 127364 141120 141239 (view as bug list)
Depends on:
Blocks: OOXML-Shapes Regress-elim-SvxShapePolyPolygonBezier
  Show dependency treegraph
 
Reported: 2019-01-14 22:17 UTC by Aron Budea
Modified: 2021-03-29 21:17 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOCX (20.57 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-01-14 22:17 UTC, Aron Budea
Details
PDF export from Word (79.06 KB, application/pdf)
2021-03-27 23:40 UTC, Aron Budea
Details
Comparison screenshot (7.2 vs. 6.1) (88.96 KB, image/png)
2021-03-27 23:41 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2019-01-14 22:17:41 UTC
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
Comment 1 raal 2019-01-15 05:36:37 UTC
Confirm. Version: 6.3.0.0.alpha0+
Build ID: e8bee017fb46
Comment 2 Xisco Faulí 2019-09-05 12:07:49 UTC
*** Bug 127364 has been marked as a duplicate of this bug. ***
Comment 3 Regina Henschel 2019-09-05 23:55:58 UTC
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.)
Comment 4 Buovjaga 2020-08-24 15:24:38 UTC
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
Comment 6 Timur 2021-03-19 13:34:29 UTC
Repro 7.2+. Not fixed with other meta bugs.
Comment 7 Timur 2021-03-20 08:09:13 UTC
*** Bug 141120 has been marked as a duplicate of this bug. ***
Comment 8 Dave Gilbert 2021-03-20 13:03:44 UTC
(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.
Comment 9 Timur 2021-03-25 06:22:15 UTC
*** Bug 141239 has been marked as a duplicate of this bug. ***
Comment 10 Xisco Faulí 2021-03-25 08:26:44 UTC
Similar to bug 118693, it might be that https://cgit.freedesktop.org/libreoffice/core/commit/?id=36bade04d3780bc54c51b46bb0b63e69789658a5 just uncovered a previous hack
Comment 11 Xisco Faulí 2021-03-25 15:09:24 UTC
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 ?
Comment 12 Xisco Faulí 2021-03-25 21:35:15 UTC
Proposed patch: https://gerrit.libreoffice.org/c/core/+/113102
Comment 13 Commit Notification 2021-03-26 08:10:42 UTC
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.
Comment 14 Xisco Faulí 2021-03-26 08:21:14 UTC
My commit should fixed the vertical vs horizontal problems. For other problems, please create a new ticket! Testing is appreciated.
Comment 15 Commit Notification 2021-03-26 10:15:45 UTC
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.
Comment 16 Dave Gilbert 2021-03-27 01:57:22 UTC
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.
Comment 17 Timur 2021-03-27 07:15:02 UTC Comment hidden (obsolete)
Comment 18 Xisco Faulí 2021-03-27 12:52:22 UTC
(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.
Comment 19 Timur 2021-03-27 14:36:07 UTC
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.
Comment 20 Aron Budea 2021-03-27 23:40:51 UTC
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.
Comment 21 Aron Budea 2021-03-27 23:41:34 UTC
Created attachment 170790 [details]
Comparison screenshot (7.2 vs. 6.1)
Comment 22 Xisco Faulí 2021-03-29 07:34:40 UTC
(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
Comment 23 Commit Notification 2021-03-29 09:01:24 UTC
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.
Comment 24 Yves57 2021-03-29 19:57:07 UTC
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.