Hi Miklos, Miklos Vajna schrieb am 10.06.2021 um 09:30:
Hi Regina, On Wed, Jun 09, 2021 at 03:33:59PM +0200, Regina Henschel <rb.henschel@xxxxxxxxxxx> wrote:I'm currently working on https://gerrit.libreoffice.org/c/core/+/115668 WIP improve wrap margins in docx filters My current state is, that distances needed for shadow and glow, for rotation and for fat stroke/border are read from docx, and they are written to docx from docx and from odt. That works for "normal" cases besides +-1Twip rounding errors somewhere and border thickness for frames, which is not yet implemented. But I have trouble with unittest testEffectExtentInline [1]. The document in testEffectExtentInline would need a negative bottom margin (UI wrap distance from text). But that is not possible in LO, bug tdf#141880. The test does not fail in current LO, because it does not determine the actual values of the image, but simple writes out the values from InteropGrabBag. If the user changes the rotate angle to 90deg (and put it back to vertical 'top to base line') or sets the bottom margin to 1cm for example, the exported docx file has unsuitable effectExtent. That results currently in a wrong line height in Word.Would it help to empty the grab-bag when the user modifies the rotation (or modifies the object in any way)?
The problem is more general. What should happen, if the Word document contains settings, that cannot (yet) be represented in LibreOffice? The difference in the test document is so small that it is not visible. If the difference would be larger, the following text lines will be shifted down, in the attached file about 2mm. Such difference can produce layout changes e.g. in position of automatic page break.
If the values of the grab-Bag are set on export instead of the values actually used in LibreOffice, the layout of the exported document would be the same as the original document in Word. But the layout of the exported document would be different in Word than in LibreOffice.
If the document is saved with the actual values uses by LibreOffice, then the layout of the exported document is the same in Word and LibreOffice, but different from the original one.
So I think, to remove the properties from grab-bag would not help. There are differences anyway.
Word has no UI to modify effectExtent directly. So I wonder how the test document was created. Creating it newly in Word would not result in the effectExtent values currently in the test document.
The idea with grab-bag was to use that during export, and the UI to empty them grab-bag when the user modifies the object. In practice, I think only impress shapes drop the smartart grab-gag on text edit, nothing else implements such emptying.
Such removal would be far beyond my patch.I could make a new test document. The original problem was, that zero effectExtent values were written. That would be caught with a new test document the same. Or adding a tolerance? Because we use Twip and not EMU there is a loss of accuracy anyway. What do you think?
Kind regards Regina
Attachment:
ManualEffectExtent.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
