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 .../>
</g>

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.

@Armin: In http://www.w3.org/TR/SVG/coords.html#TransformAttribute 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"/>
</g>
-- 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"
        ry="57"
        height="512" width="512" y="0" x="0"
        fill="#00f"/>
</g>

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

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.

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.

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...

Experimented a lot with OpenClipart, looks good. Preparing commit...

"alg" committed SVN revision 1607682 into trunk:
i124852 Corrected mask and clip polygons for userSpaceOnUse

Committed, done. Also a safe fix, I see no reason against adding it to AOO411. Setting flag...

grant showstopper flag

Added to AOO411, done

"alg" committed SVN revision 1607810 into branches/AOO410:
i124852 Corrected mask and clip polygons for userSpaceOnUse

Verified fixed with -- AOO411m2(Build:9771)  -  Rev. 1608452
2014-07-07 15:22 - Linux i686

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.