<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN Horizontal line in DOCX has wrong size/position" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122717#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN Horizontal line in DOCX has wrong size/position" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122717">bug 122717</a> from <a class="email" href="mailto:freedesktop@treblig.org" title="Dave Gilbert <freedesktop@treblig.org>"> Dave Gilbert</a> <pre>(In reply to Regina Henschel from <a href="show_bug.cgi?id=122717#c3">comment #3</a>) > I have used the attachment of the duplicate <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - FILEOPEN DOCX Vertical line becomes horizontal when documentis opened in LO 6.4" href="show_bug.cgi?id=127364">bug 127364</a> 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 <a class="bz_bug_link bz_status_VERIFIED bz_closed" title="VERIFIED FIXED - Error when saving a polygon with points converted to curve" href="show_bug.cgi?id=106792">bug 106792</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>