Issue 124852 - Bad SVG import with particular files
Summary: Bad SVG import with particular files
Alias: None
Product: Draw
Classification: Application
Component: open-import (show other issues)
Version: 4.1.0
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.1
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2014-05-08 10:04 UTC by Ariel Constenla-Haile
Modified: 2014-07-17 00:43 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.1.1_release_blocker+

Draw document with two SVG flags (65.83 KB, application/
2014-05-08 10:04 UTC, Ariel Constenla-Haile
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Ariel Constenla-Haile 2014-05-08 10:04:03 UTC
Created attachment 83356 [details]
Draw document with two SVG flags

Download any flag from this collection:

For example:

and open them in Draw.
They just don't look like the export in the OpenClipart site, or when they are opened in Firefox or Inkscape.
Comment 1 Armin Le Grand 2014-06-25 12:22:51 UTC
Took a look. Problem is that groups with transforms and referenced ClipPaths are used. In this case (tf.svg):

<g transform="translate(128,128)" clip-path="url(#clipPathFlag)">
    <rect .../>

The ClipPath and transform is applied to the group context, but the ClipPath is *not* transformed in the group definition. This is by purpose (I checked SvgStyleAttributes::add_postProcess where I remember to have changed that for another fix, see svgstyleattributes.cxx:1116, see comment there). If I apply these, the import is correct (except the missing filtering stuff).

I remember to have seen somewhere in SVG spec that this is as it should be (which would mean that the files are wrong). Adding Regina to CC.

@Regina: In the example above, does transform need to be applied to the referenced clip-path or not? AFAIK the SVG spec says not to apply it, but then the example files would be wrong.
Comment 2 Regina Henschel 2014-07-02 18:42:41 UTC
@Armin: In the following example is given:

-- quote start --
In the element
<rect x="10" y="10" width="20" height="20" transform="scale(2)"/>
the x, y, width and height values are processed after the current coordinate system has been scaled uniformly by a factor of 2 by the ‘transform’ attribute. Attributes x, y, width and height (and any other attributes or properties) are treated as values in the new user coordinate system, not the previous user coordinate system. Thus, the above ‘rect’ element is functionally equivalent to:
<g transform="scale(2)">
  <rect x="10" y="10" width="20" height="20"/>
-- quote end --

Besides the above "and any other attributes or properties", I do not find any explicit statement about clipPath together with transform. But when I apply the way of the example above to the attached file, then

<g id="01" transform="translate(128,128)" clip-path="url(#clipPathFlag)">
    <rect id="mask"
        height="512" width="512" y="0" x="0"

should be functionally equivalent to the surrogate
<g id="01" transform="translate(128,128)">
  <g id="myclip" clip-path="url(#clipPathFlag)"> 
    <rect id="mask"
        height="512" width="512" y="0" x="0"

If I change the structure in the attached file to this surrogate, the image is shown as expected.

The browsers IE, Chrome, Seamonkey, and the applications Inkscape and Batik show the image the same way as my surrogate. Only my rather old (from 2003) CorelDraw 12 shows it, not equal, but similar to the current AOO rendering. To be compatible with modern browsers and applications, I would go with their rendering, even if there might be a comment in any older SVG spec, that indicates it different.
Comment 3 Armin Le Grand 2014-07-03 12:44:55 UTC
Hi Regina, thanks for investigating.

I found the same quote in the SVG specs, thanks for the proof that there is nothing else mentioned. I am still sure that I changed that by purpose in the past, sigh.

I did the same replacements you did in the example file and came to the same conclusions :-) I agree that the main argument is the compatibility with what othesr do, thus I agree that the semantic should be changed corresponding to the quote above.
Comment 4 Armin Le Grand 2014-07-03 15:23:30 UTC
I experimented and found the trick: It depends on the MaskContentUnits. When objectBoundingBox scale according to ObjectBounds, when userSpaceOnUse use the transformation if available. With that modification the test files look good. Also all my collected test files from many other tasks regarding SVG look good, some even seem to be improved.
Doing some more tests...
Comment 5 Armin Le Grand 2014-07-03 15:48:17 UTC
Experimented a lot with OpenClipart, looks good. Preparing commit...
Comment 6 SVN Robot 2014-07-03 16:00:14 UTC
"alg" committed SVN revision 1607682 into trunk:
i124852 Corrected mask and clip polygons for userSpaceOnUse
Comment 7 Armin Le Grand 2014-07-03 16:22:20 UTC
Committed, done. Also a safe fix, I see no reason against adding it to AOO411. Setting flag...
Comment 8 jsc 2014-07-04 06:17:35 UTC
grant showstopper flag
Comment 9 Armin Le Grand 2014-07-04 09:39:03 UTC
Added to AOO411, done
Comment 10 SVN Robot 2014-07-04 09:55:39 UTC
"alg" committed SVN revision 1607810 into branches/AOO410:
i124852 Corrected mask and clip polygons for userSpaceOnUse
Comment 11 Kay 2014-07-15 20:42:29 UTC
Verified fixed with -- AOO411m2(Build:9771)  -  Rev. 1608452
2014-07-07 15:22 - Linux i686
Comment 12 Rekha S 2014-07-17 00:43:23 UTC
Verified fixed on AOO 4.1.1 m2 revision : 1608452
on Windows 8 as well.
I'm able to see the downloaded flags correctly in Draw.