Problems with unittest testEffectExtentInline

[Miklos Vajna]

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.

> 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).

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

> 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. :-)

Regards,

Miklos