W3C home > Mailing lists > Public > www-svg@w3.org > April 2011

Re: Comments on SVG Compositing

From: Alex Danilo <alex@abbra.com>
Date: Sat, 09 Apr 2011 19:35:33 +1000
Message-Id: <9BPDJL.RZOO9BE0394@abbra.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Rik Cabanier <cabanier@gmail.com>, www-svg <www-svg@w3.org>
Hi Tab,

	When I get time I'll explain it to you on this list.

	clip-to-self is to enable Java2D compatible rendering.
Nothing whatsoever to do with Photoshop or the Adobe imaging


--Original Message--:
>On Fri, Apr 8, 2011 at 4:41 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> I'm not familiar with the "clip-to-self" concept so it's better if someone
>> else responds to this.
>I believe clip-to-self:object (or comp-clip-to:src) is the default
>behavior in Photoshop.  I suspect that this is the most intuitive
>behavior for most people, so it would probably be good to just make
>that the default.
>>> >> I don't have strong graphics experience, so there may be something I'm
>>> >> missing here, but 'enable-background' and 'knock-out' appear to be
>>> >> *exactly* identical in operation, just applying to different things:
>>> >> 'knock-out' transforms "A op B" to "A op (A dst_out B)", while
>>> >> enable-background transforms "[group image] over [background]" to
>>> >> "[group image] over ([group image] dst_out [background]".  Can these
>>> >> two properties be unified in some way?
>>> >>
>>> > knock-out = how objects within the container blend with each other
>>> > enable-background = how objects within the container blend with the
>>> > background
>>> > The programming logic between the 2 modes is very different so I think
>>> > that
>>> > this is enough for a separate attribute.
>>> Your description makes them seem even more similar.  ^_^  From the POV
>>> of an author with relatively little graphics experience, there's no
>>> important difference between these two for me.  The fact that
>>> implementations might implement the two in different fashions is
>>> irrelevant to me, because I'm not an implementor.
>>> > If you unify them into 1 property, it would also result in many states:
>>> > knock-out (= 3 states) * enable-background (= 3 states) = 9 different
>>> > names
>>> > which is more confusing.
>>> I'm not sure I understand.  'knock-out' and 'enable-background' have
>>> only two states each.
>> They also have separate 'inherit' states.
>Ah, yeah, I naturally ignore that, since *all* properties have an
>'inherit' value (and 'initial', too).
>>> Further, the syntax seems like it can be very
>>> simple; something like:
>>> comp-over: none | [ group || [ background | rect(x,y,w,h)] ]
>>> ...with 'comp-over: group background;' being the default.
>> Does 'group' correspond with 'knockout = false'?
>>> The only thing that would let me justify this being split into two
>>> property would be if it seems like it's useful to have these cascade
>>> separately.  I don't have enough experience with using these to
>>> understand if that's something important or not.
>> Adobe applications have the ability to control the 2
>> properties independently including the 'inherit' state.
>> I believe this was done because they are conceptually different for
>> designers.
>> ie see these articles:
>> http://layersmagazine.com/the-joys-of-isolation-blending.html (enable-background
>> is the same property as isolate)
>> http://www.creativepro.com/article/illustrator-how-this-technique-a-real-knockout
>> In our apps, the default state of 'knockout' is 'inherit' while
>> 'enable-background'/'isolate' is 'true'/'false' by default.
>> (In our imaging model, the 2 values are simple booleans. The application is
>> expected to resolve the 'inherit' value before exporting to PDF)
>Hm, okay.  If that's a reasonable default, then it does make sense to
>keep them split.  (By the way, thanks for the links!  I now understand
>the use of knock-out really well - it lets you paint with transparent
>colors the same way you do with opaque, where you can fill a big area
>with color and then draw the details on top of it.)  I can definitely
>see how inheriting 'knock-out' by default is a good idea.  This also
>means that 'knock-out' should probably be an inherited property.
>In that case, try this on for size:
>1. Rename the property/values of clip-to-self in the way I suggested.
>Change the lacuna value to 'src', as this se
>2. Keep knock-out's current name and values.  Make it an inherited property.
>3. Rename 'enable-background' to 'comp-children-over', with values of
>"transparent | background | rect(x,y,w,h)".  This matches my mental
>model a bit better, where the property affects what I composite the
>children of the group over.
>It would also be *awesome* to use that post as an example for
>enable-background/comp-children-over, and put in some note about why
>knock-out is useful.
Received on Saturday, 9 April 2011 09:36:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC