Problems with unittest testEffectExtentInline
rb.henschel at t-online.de
Thu Jun 10 13:12:32 UTC 2021
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 at t-online.de> 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
>> But I have trouble with unittest testEffectExtentInline . 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 66485 bytes
Desc: not available
More information about the LibreOffice