W3C home > Mailing lists > Public > www-svg@w3.org > March 2008

Re: Masks and Images

From: Mark E. Shoulson <mark@kli.org>
Date: Tue, 11 Mar 2008 09:54:21 -0400
Message-ID: <47D68F0D.50708@kli.org>
To: Erik Dahlström <ed@opera.com>
CC: www-svg@w3.org

Erik Dahlström wrote:
> On Mon, 10 Mar 2008 16:22:59 +0100, Mark E. Shoulson <mark@kli.org> 
> wrote:
>
>> Hi folks.
>>
>> I'm new here, but I've been playing around with an SVG project for a 
>> while and I have a pair of questions-slash-feature requests...
>>
>> (1) Currently, my SVG validates, except for the fact that I have 
>> "transform" attributes on "mask" elements.  I am told, "well, no 
>> problem, you can just put the transform on a group inside the mask," 
>> which is probably true, but if so, and thus if transforming 
>> everything in a mask is no problem, why isn't it allowed on the mask 
>> element itself in the first place?
>
> Are you proposing that 'transform' on <mask> should be a supplemental 
> transform, similar to gradientTransform[1] and patternTransform[2], 
> such that it doesn't apply to the x,y,width,height attributes that are 
> on the <mask> element?
>
> Or, do you suggest to add it similar to <clipPath>, that is have 
> 'transform' implied[3]?
The latter, if I am understanding correctly.  There is a "transform" 
attribute which is permitted on clipPaths and on groups and any number 
of other things, which for some reason is forbidden on masks, and I hope 
that can be fixed.  I am not proposing an entirely New and Different 
flavor of transformation like clipTransform etc.

BTW, I see that the bug report for this selfsame question came on the 
list right about the same time as my letter.  While it is true that the 
reporter of that bug is also working with me on the same project where 
we ran into this problem, it's just a coincidence that we both tried to 
address it (in different ways) on the same day. :)
>>
>> And yet I can't do that if the image I am including is another SVG.  
>> Because SVGs drag their own coordinate systems into the mix.  So in 
>> short, raster images are more easily *scaled* and dealt with in a 
>> *scale-independent* fashion than the supposedly scalable and 
>> scale-independent SVGs??  That somehow seems wrong.
>
> I would tend to agree with that.
Thank you.  I'm glad to hear it isn't just some misunderstanding I have 
of the whole situation.
> There's a thread[4] on svg-developers@yahoogroups.com about this problem.
Mm.  And trying to work around it with scripting, but not fixing the 
actual problem, which is a shortcoming in the actual SVG design.  I 
don't know if it would work in general anyway: do libraries like batik 
and rsvg honor scripting?  (I'm using rsvg a lot because nothing else, 
no browser, not even Opera, not even batik, seems to handle everything 
I'm doing properly).

I recognize that there is some issue here in that if the source SVG has 
not defined a viewBox then it isn't clear what to scale and how.  But on 
the other hand, there is SOMETHING that is rendered when you view the 
thing; scale THAT.  And when viewBoxes are defined, it seems to matter 
that they don't conform to the scale of the referencing SVG, which again 
misses the whole point: the referencer should be able to scale and 
position the referencee wrt the former's coordinate system, regardless 
of the latter's, just as it can with raster images.

~mark
Received on Tuesday, 11 March 2008 13:57:36 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT