Problems with unittest testEffectExtentInline

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 11.06.2021 um 09:50:
> Hi Regina,
> 
> On Thu, Jun 10, 2021 at 03:12:32PM +0200, Regina Henschel <rb.henschel at t-online.de> wrote:
>> The problem is more general. What should happen, if the Word document
>> contains settings, that cannot (yet) be represented in LibreOffice?
> 
> That would be the idea of the grab-bag, to just save some of those
> settings and write them back to docx, without understanding them.
>

The purpose of my patch is to "understand" margins, so that we have a 
generic import which covers other extent reasons like glow too, and can 
properly export odt documents too.

>> 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.
> 
> It was added in core.git commit 9992338fbbf46bf381501df6c7763bf117d2ee25
> for tdf#79315. If you think the testcase is poor, it's possible to
> rework it, just please manually test the original bugreport after your
> changes (so the testcase still represents the original problem).

Thank you for searching the associated bug report for me.

With that document I get margins off by 635EMU whereas the size is 
correct. The current master has margins as original but size off by 635EMU.

> 
> Interestingly reading the word/document.xml of that test document, it
> does not look like it was hand-edited after saving in Word.

It seems to boil down to a principle accuracy problem. For angles we 
have an accuracy interval of 0.01deg = 600 'MSO Angle unit' and for 
length in Writer an accuracy interval of 1 Twip = 635 EMU. The solutions 
in my patch differ from current master in the way how the inaccuracy is 
distributed.

> 
>> 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?
> 
> If you find a poor test, then reworking the test document to better
> represent the original problem is a better solution. Adding tolerance
> sounds a bit hacky. :-)
The test is not 'poor' per se but triggers principle accuracy aspects. 
I'll we try it with a slightly changed document.

It's annoying, but it's still good that all these tests are being done. 
It forces you to rethink your own solution in each individual case.

Thank you for taking the time to discuss the issues with me.

Kind regards
Regina