Download it now!
Bug 122717 - FILEOPEN Horizontal line in DOCX has wrong size/position
Summary: FILEOPEN Horizontal line in DOCX has wrong size/position
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 127364 (view as bug list)
Depends on:
Blocks: OOXML-Shapes
  Show dependency treegraph
Reported: 2019-01-14 22:17 UTC by Aron Budea
Modified: 2020-10-28 15:44 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Sample DOCX (20.57 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-01-14 22:17 UTC, Aron Budea

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 / Windows 7.
No issue in
=> 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.
author		Armin Le Grand <>	2018-06-28 19:48:59 +0200
committer	Armin Le Grand <>	2018-07-02 18:03:44 +0200

tdf106792 Get rid of SvxShapePolyPolygonBezier
Comment 1 raal 2019-01-15 05:36:37 UTC
Confirm. Version:
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 as discussed in