Re: Comments on SVG Compositing

Hi Alex,

it would be nice to know why it is in SVG. Is there still a need for this
parameter? What workflows would be broken if 'clip-to-self: canvas' was
removed?

Personally, I think the PorterDuff blending modes are very confusing. Can't
we strip them from the spec and replace them with more descriptive one?

Rik

On Sat, Apr 9, 2011 at 2:35 AM, Alex Danilo <alex@abbra.com> wrote:

> 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
> model.
>
> Alex
>
> --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'?
> >
> >Yes.
> >
> >
> >>> 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.
> >
> >~TJ
> >
> >
> >
>
>