Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


Hi all,

I'm working on tdf#121761 and tdf#121952. The current state is in https://gerrit.libreoffice.org/#/c/64817/. It works in principle, but there are still some problems.


Problem A
The current implementation has a method GetPoint, which returns a tools::Point; and such has integer coordinates. This introduces inaccuracy, if you need to use the result in further calculation.

Currently I use GetParameter (which results a double) directly and add the needed shift and scaling each time. I think, it would be better to have a method for getting a point in double coordinates. Do you agree?

The calculation inside GetPoint is in double and only at last step it gets a cast to integer, astonishing for y-coordinate to sal_Int32 and for x-coordinate to long. The structure of the calculation seems unnecessary complicated to me.

How can I get a method for double point parallel to the existing GetPoint? Do I need a new method name? Or is there a way to keep the current method name, but different result type?


Problem B
The commands X (ELLIPTICALQUADRANTX) and Y (ELLIPTICALQUADRANTY) draw an arc clockwise or counter-clockwise depending on the position of the current point and the target point. But the method createPolygonFromEllipseSegment from basegfx does only create arcs clockwise.

My current solution contains the same idea to generate a counter-clockwise arc four times. Not nice. I can put it into a local method for these special cases, I can add a new method createPolygonFromEllipseSegmentCounterClockWise or I can add a parameter to createPolygonFromEllipseSegment to allow generating of counter-clockwise arcs. Which way to go?


Problem C
The commands X and Y draw an arc from the "current" point. What to do, if a path starts with an X or Y command? The current solution makes a moveTo to the target point and continues then. Such continuation might be with additional target points for X or Y. The general flow following ODF is, that the direction toggles between x-direction and y-direction automatically after each point. (That is bug 121952). But what to do, if the path is ill-structured and the first parameter point is consumed by moveTo? Keep the direction or toggle it?

I cannot look how PowerPoint or Karbon handle this case, because both crash on such ill-structured path.


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 be independent from screen resolution. Does a template exist somewhere?

Kind regards
Regina





Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.