Apache OpenOffice (AOO) Bugzilla – Issue 123465
[SVG] marker-mid missing for empty closepath if first point equals last point
Last modified: 2017-05-20 10:35:40 UTC
Created attachment 81748 [details] Collection of empty and non-empty closepaths Follow-up to bug 123379 (In reply to Armin Le Grand from comment i123379#17) > ALG: Checked again, and looks good. Committing this version. If we need > further changes, no problem. In general I find it good too, but one nitpick: If the closepath is empty and initial point is equal to last point, then the mid-marker on the last point is missing. If the closepath is empty and the initial point does not equal the last point, then the mid-marker is drawn correctly.
ALG: Regina, which of the six beziers is wrong and in which aspect exactly? I still could not get IE to show the graphics, and we already found out that Inkscape, Safari and Mozilla have their caveats...
Wrong are HorizontalVertical_solid_empty_closepath.svg Bezier_empty_closepath.svg Not sure about HorizontalVertical_empty_closepath.svg because there the path start has a red marker and therefore I cannot see, whether there is an additional red marker for the end point. The files with "empty_closepath" in their name have the last point as explicit point set and therefore the z command, which connects back to the first point, results in a zero-length path. There have to be a marker-mid for the point and a marker-end for the end of the z command line. The comparison is between the files without "empty_closepath" in there name. The files with "empty_closepath" have one point more and this point has to get a marker, because the rule, that zero-length path do not prevent drawing markers.
In case of the Bézier curve, the difference is, that the position of the end point of the curve is left of the start in bezier.svg and is on the start point in Bezier_empty_closepath.svg. The position of the point should not make a difference whether it gets a marker or not.
I think, that the problem is in closeWithGeometryChange from b2dpolygontools.cxx. It removes multiple start/end points. I find no statement in SVG spec, that zero-length path segments have to be removed. So this method might not be correct for svg import, and since ODF "18.3.22 pathData" refers to SVG, not correct for draw:path too. What has been the reason to remove the multiple start/end points?
ALG: You are probably right with closeWithGeometryChange; it has historical reasons and is originally based on the transition from tools:Polygon classes to basegfx classes; the tools:Polygon class had no internal possibility to express that it is closed, it used the 1st == last point paradigm, making it impossible to have open polygons with 1st and last point being equal. closeWithGeometryChange is sued in the converters between these two polygon classes to solve this; mainly used in im/exporters and binfilter, short: in places where it was not possible to get away from tools:polygon yet. I already thought about that one as a possible reason; for SVG it might indeed be the best solution to just not do that. This might lead to one problem, though: - import a svg:d not closed, 1st and last points equal - break (to no longer have it as original SVG) and save as ODF: In the UNO API it needs to be converted to sequences of points which also do have no possibility to express a polygon with 1st == last point and not closed (maybe with the polygon type, need to check). Thus: This type of polygon might get lost...
Binfilter was dropped. Shouldn't it be possible to replace the tools:Polygon classes totally?
ALG: Another tipp (I just made up): to check how many markers (and where) were created, break the SVG and travel/check the objects with tab/shift-tab and cursor keys...
ALG: No, it's not only in binfilter (unfortunately), it's used throughout VCL and other modlues and very hard to get rid of it (sigh)...
ALG: Checked with replacing closeWithGeometryChange with setClosed(true). The examples look as expected. Checked with my usual stack of SVG files, also promising. To make sure, I will need a more current version, preparing...
ALG: Back to this one, current tru7nk available and checking...
ALG: Checked with the attached examples and with my internal stack of SVG test files, it works well. The logic also says that it is not needed to do this correction for SVG imports at all. Preparing commit...
ALG: Comitted, done.
"alg" committed SVN revision 1536316 into trunk: i123465 no longer correct svg:d imports svnbz message delay caused by perl problems after Bugzilla 4.4.1 update
verified in AOO411m4(Build:9774) - Rev. 1614049 (=RC1)