Problems with unittest testEffectExtentInline

[Regina Henschel]

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 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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ManualEffectExtent.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 66485 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20210610/44d73821/attachment.docx>