Issue 119115

Summary: svg: in d attribute the movement in zm has to start at the beginning of the previous subpath
Product: Draw Reporter: Regina Henschel <rb.henschel>
Component: codeAssignee: Armin Le Grand <Armin.Le.Grand>
Severity: Normal    
Priority: P3 CC: Armin.Le.Grand, issues
Version: recent-trunk   
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
svg file with square with subpath to generate a hole none

Description Regina Henschel 2012-03-23 17:26:57 UTC
Created attachment 77356 [details]
svg file with square with subpath to generate a hole

If a drawing consists of several subpaths, the m movement after the closing z has to be relative to the start of the subpath, which has been closed with z.
This is calculated wrong at the moment. Open the attached file in Seamoney or any other program with svg ability. Insert the svg-file into a Draw document and compare it to see the error.

Unfortunately the objects which are generated with the combine command in Draw are handled with the some error in the movement. That problem will be corrected for LO in LO 3.5.2.
Comment 1 Armin Le Grand 2012-03-24 12:15:56 UTC
ALG: Added myself to CC
Comment 2 Armin Le Grand 2012-03-24 12:16:10 UTC
ALG: Added myself to CC
Comment 3 Armin Le Grand 2012-03-26 16:27:13 UTC
ALG: Double to #119118# (is there no field for double in bugzilla?!?).
Comment 4 Regina Henschel 2012-03-26 16:44:29 UTC
If you will handle it together with i110118 that is OK for me. I thought issue 119118 for our own object (the svg:d attribute in a draw:path element) and this issue for the svg picture import.

"Duplicate" will be in the second drop-down-list, which appears, when you set Status to "resolved".
Comment 5 Armin Le Grand 2012-03-27 08:24:45 UTC
ALG: As far as I understood both have to do with svg:d and handling of relative occurrences (small letters) of 'z' which should set the current point to the start of the closed path. Please correct if there are different reasons for both. Correcting this in the conversion frm svg:d to basegfx::Polygon will fix both from my POV, correct?
Comment 6 Regina Henschel 2012-03-27 10:16:09 UTC
I don't know, that it can be fixed with the same part of the code. I'll set this issue to duplicate.

*** This issue has been marked as a duplicate of issue 119118 ***