https://bugs.documentfoundation.org/show_bug.cgi?id=151518
Bug ID: 151518
Summary: FILEOPEN DOCX Text is wrongly plaaced in some SmartArt
types
Product: LibreOffice
Version: 7.4.1.2 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: rb.hensc...@t-online.de
Created attachment 183032
--> https://bugs.documentfoundation.org/attachment.cgi?id=183032&action=edit
Example for the problem
Check option "SmartArt to LibreOffice shapes or reverse" in Tools > Options >
Load/Save > Microsoft Office.
Open attached document. It contains a SmartArt shape and a picture, how it
looks in Word. The red rectangles are semitransparent to allow to see the text
of the blue shapes in case it is behind the red rectangles.
The fix for bug 148321 has introduced, that the position of the text considers
the special way Microsoft Office calculates it, in case a vertical distance to
text is so large, that the text is outside the text area. That works fine for
shapes in PowerPoint. But it conflicts with text in SmartArt in Writer.
Reason is, that the calculation in TextBodyPropertiew::readjustTextDistances()
uses the text area rectangle of the SdrObjCustomShape. These values are used in
expressions with text distances. But in Writer text area rectangle is in Twips
whereas the text distances at import time are in Hmm. So the special
calculation is triggered, although in fact there is no such situation.
The problem is not visible with normal shapes in Word, because Word does not
allow to use so large distances. You can enter such values, but the overflowing
text is not displayed in Word.
SmartArts would not need this special corrections, because
TextBodyProperties::pushTextDistances() already results in correct text
location. Unfortunately I see no easy way to exclude SmartArt shapes in Writer
from using TextBodyPropertiew::readjustTextDistances().
Effected are those SmartArt types which use the text distances to shift the
text from its center position up or down. I have not inspected all types, but
see the problem with types "Target List", "Nested Target", "Stacked Venn" and
"Grouped List" so far.
This is not a regression from the fix for bug 148321 because before the fix the
text position was wrong too, albeit in a different way.
--
You are receiving this mail because:
You are the assignee for the bug.
