Issue 123465 - [SVG] marker-mid missing for empty closepath if first point equals last point
Summary: [SVG] marker-mid missing for empty closepath if first point equals last point
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: 4.1.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-11 17:22 UTC by Regina Henschel
Modified: 2017-05-20 10:35 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Collection of empty and non-empty closepaths (45.68 KB, application/zip)
2013-10-11 17:22 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2013-10-11 17:22:53 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.
Comment 1 Armin Le Grand 2013-10-16 11:54:45 UTC
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...
Comment 2 Regina Henschel 2013-10-16 12:44:51 UTC
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.
Comment 3 Regina Henschel 2013-10-16 12:52:17 UTC
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.
Comment 4 Regina Henschel 2013-10-19 18:13:34 UTC
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?
Comment 5 Armin Le Grand 2013-10-21 10:48:54 UTC
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...
Comment 6 Regina Henschel 2013-10-21 13:40:16 UTC
Binfilter was dropped. Shouldn't it be possible to replace the tools:Polygon classes totally?
Comment 7 Armin Le Grand 2013-10-21 13:45:20 UTC
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...
Comment 8 Armin Le Grand 2013-10-21 13:46:11 UTC
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)...
Comment 9 Armin Le Grand 2013-10-25 11:34:55 UTC
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...
Comment 10 Armin Le Grand 2013-10-28 10:13:33 UTC
ALG: Back to this one, current tru7nk available and checking...
Comment 11 Armin Le Grand 2013-10-28 11:04:23 UTC
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...
Comment 12 Armin Le Grand 2013-10-28 11:43:09 UTC
ALG: Comitted, done.
Comment 13 SVN Robot 2013-10-29 08:15:54 UTC
"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
Comment 14 Regina Henschel 2014-08-01 15:52:15 UTC
verified in AOO411m4(Build:9774)  -  Rev. 1614049 (=RC1)