Re: Problems with unittest testEffectExtentInline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx> 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



_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux