On Sat, 8 Dec 2018 at 20:25, Regina Henschel <rb.henschel@xxxxxxxxxxx> wrote:
Problem A
The current implementation has a method GetPoint, which returns a
tools::Point; and such has integer coordinates. This introduces
I would say you should change GetPoint() to return a basegfx::B2Point. You can't have two methods with the same name with different return types, and this is a place where it clearly should be returning a more accurate result.
Problem B
to createPolygonFromEllipseSegment to allow generating of
counter-clockwise arcs. Which way to go?
You should add a parameter here. Either a boolean or an enum param, something like 'enum class Direction { Clockwise, CounterClockwise }'
Problem C
the path is ill-structured and the first parameter point is consumed by
moveTo? Keep the direction or toggle it?
With ill-structured data, I would say that you should just 'not crash' and error out at the earlier opportunity. There is no need to try doing something sensible with such data unless necessary for some kind of compaibility.
Problem D
How to make a unit test for such patches
(https://gerrit.libreoffice.org/#/c/64704/1 is another one)? It would
need to compare a bad rendering with a correct one and it would need to
For this kind of thing, one approach is to query the output programmatically to see that it is correct. Other times we dump the output using dumpAsXml() and query the output using XPath.
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
