AG: I kind of put some basic
usage scenarios in there
... I'm not sure if anything more needs to be done
... want feedback

ED: there should be mention of
and links to the CSS transforms proposal

CM: change that requirement 3.1
to mention supporting SVG DOM access to these transforms
instead of a scripting feature set

DS: we should make sure to ask
the CSS WG and browser vendors what their use cases and
requirements are

AG: the scripting change should
be easy
... I've done a bit more work on the transforms spec itself
doing bits and pieces
... trimmed the specification down
... JF and I agreed to remove translateX/Y/Z and scaleX/Y/Z

JF: translateX/Y is part of the
CSS specification but that's just syntactic suger

AG: we proposed a translate3D
that takes three parameters

DS: why don't we just use
'translate' and extend it to allow it to take 3 parameters

AG: at the moment in our proposal
translate3D has optional 2 parameters

CM: the syntax in the spec at the
moment says it can have one or three

DS: rotate is different
... but scale and matrix...

AG: JF is right, it can be
smaller
... to answer CM's question, the reason the the CSS
specification is 4x4 is to allow perspective and 3D
transformations
... in our proposal we've separated out the syntax to have a
separate 3D and perspective transform
... in the spec you can specify one vanishing point per
object

[AG draws on whiteboard to demonstrate
separation]

CM: you're saying the 12
component version is more compatible with OpenVG?

<ChrisL> presumably opengl
can also use the 3x3. i doubt openvg is an incompatible
superset

AG: OpenVG uses 3x3, OpenGL uses
4x4

CM: is it because restricting the
matrix to have all zeros in the third row of the perspective
matrix means that when you multiply it by the 3D matrix it
reduces down to a 3x3 which matches the OpenVG interface?
... and that's because you can't specify a general 4x4 matrix,
and ...
... having general 3D effects isn't useful

AG: [yes]

DS: we can still do
animations?

AG: yes

DS: are we going to cut ourselves
off from future effects?

AG: not that I can think of

DS: are there two matrices or
one, and what will getCTM return?

ED: we would extend the SVGMatrix
interface to get at all the values of the matrix, so still the
same object we're return, but with more accessors

AG: so, as a note, the reason we
put SVGMatrix3D in there was to be compatible with SVG 1.1
matrices
... in answer to whether we'll miss out in stuff in future, the
answer is still no, but currently the model we've got makes
things a bit easier, because in CSS you can get | rotate
perspective translate perspective |
... (repeated perspective)

DS: I thought theirs was
separate

AG: they have both

DS: what's the use case

AG: I haven't seen any

DS: we should get them

ED: I think if we have rotate3D
et. al, we'd probably want the same naming for translate and
scale, that is having the suffix 3D there too

DS: but how would you do it, what
would the syntax be?

AG: you need a rotation
vector

CM: the restriction that you
can't specify general 4x4 means that you are compatible with
both OpenVG and OpenGL because 3x3 is just a subset of 4x4

DS: why do we need matrix3D?

ED: there is one reason: older
user agents won't misinterpret it

CM: maybe we want to introduce
forwards compatible parsing of transform lists so that
individual transforms that are not recognized are ignored
... not sure if you can have useful results by ignoring
them

AG: it's probably feasible, since
the old matrix has 9 values

CM: I think that's a bit
different from what I said
... still not sure if it's useful
... if the document needs to have perspective transforms to
look right, is it useful?

ED: it will probably look
incorrect either way

DS: if you use a matrix with 9
values in Firefox it throws away the entire transform

ED: Opera does the same
probably

DS: [tests] actually Opera
applies anything that comes before the matrix with 9 values,
but not anything after
... Safari does the same as Firefox
... Batik pops up an alert
... if implementations all behaved like Opera, you could fake
perspective with an initial skew and rotate, then undo the skew
and rotate in the matrix that does the real perspective
transform for newer user agents that support it
... extending 'matrix' or introducing matrix3D seems to make no
difference in what implementations do

ED: if we extend, then rotate3D
would be the only odd one out

<ChrisL> +1 to that

<ChrisL> assuming "that" gets
minutes (hint)

DS: we could extend 'rotate' and
make it depend on the number of parameters that are passed

AG: when you do translate, you
need to work in that user space, but with transform-origin, you
can put it in an object and say that it's the center of the
object

DS: it's in the outer coordinate
space

AG: it would allow percentages,
too, object bounding box coordinates

ED: one question, is
transform-origin in this spec exactly the same as in css
transforms?

JF: very useful for transform
origin, especially if we set the transform-origin as
50%,50%
... you can rotate or scale about the center point
... very convenient
... the initial value of this property is defined as 50%,50% in
css transforms
... but we are thinking whether we should use this intiial
value
... if we don't specify a transform-origin, it should rotate
about the origin
... maybe it should be 0,0

JW: is css transforms spec

s/spec a rec already?/

CM: no they're about to publish a
FPWD

DS: otherwise it changes how svg
transforms work currently

AG: you can specify keywords,
percentages and lengths in transform-origin
... but would the length be offsets from the origin or the bbox
of the object?
... is that too overloaded?

CM: i think that would be
confusing

<ChrisL> yes, thats too
overloaded. just changing the unit should not change what
parameter it is

AG: it seems a bit overloaded

DS: the 50%,50% initial value is
at odds with existing percentage syntax in svg
... that would be viewport relative

ED: but in some cases they are
relative to bboxes

DS: we could have something like
transformUnits="objectBoundingBox"
... transformOriginUnits

AG: then you'd need to use both
properties in pair

DS: the default is
"userSpaceOnUse", for lengths

AG: relative to the origin

DS: and "objectBoundingBox" would
make the lengths be relative to the bbox of the object
... the default should be userSpaceOnUse
... i don't mind this overloading

CM: why can't we have the
transformOriginUnits value inside the transform-origin?

DS: it would be harder to parse,
maybe more confusing for authors
... what if you want to animate the transform-origin?
... would you need to keep those transformOriginUnits keywords
in the animation too?
... we should have these userSpaceOnUse/objectBoundingBox
functionalities though

CM: you could have these keywords
repeated in the transform-origin to use different references
for the different axes

JW: css would have three values
for this units attribute/keyword: the equivalent of
objectBoundingBox, nearestContainingBlock and
initialContainingBlock

CM: which one does userSpaceOnUse
correspond to?

JW: probably
nearestContainingBlock

ED: for transform-origin, if you
had scale and rotate in the same transform, would the origin
apply to both of them together? or each individually?

CM: it gives a pre and post
translation for the whole transform
... in css transforms

ED: our one should say something
about that

CM: be nice to have matrices and
worked examples in the spec
... perspective-origin in the css spec

AG: in ours, we can just put the
perspective origin in the 'perspective' property itself (giving
three values)

ED: so you're changing all the
matrix3d() to just matrix() with 12 values?

JF: i think we should consider
this, examining the current implementation
... if it's ok, we're happy to change

DS: maybe it just wouldn't work
with css boxes
... so we really need separate rotateX, rotateY, rotateZ?

AG: the regular rotate() in svg
rotates around the z axis

CM: so rotateZ() is just the same
as rotate()

ED: so it would make it slightly
simpler than the one we're proposing, since we need to specify
the vector to rotate around?

JF: if you have individual
rotates, it's easier to do animation on these rotateX,
rotateY
... you could do animateTransform type="rotateX"

CM: so it's a similar sugar as
having both matrix() and translate(), e.g.
... and the css spec has these too

DS: i don't mind rotateX, Y,
etc.

AG: in our spec, rotateX, rotateY
and rotateZ can all take two optional center point
coordinates
... in the css spec they don't have that

DS: their 'transform-style'
property allows you to do the cube rotation example

CM: would we then prefer
layeredGroup over transform-style and backface-visibility, or
vice versa?

DS: we could have both, and talk
about how they interacts with layeredGroup

AG: layeredGroup would allow you
to specify the z-indexes of each child

CM: so that seems to be less
usable than transform-style, which will work out the right
z-order itself

JF: i agree
... but i'm not sure if this 'transform-style' with preserve-3d
works or not
... it will choose which to display based on the z
coordinate
... but sometimes objects are not parallel to the x/y
plane
... so it's difficult to define one specific z position of the
objects
... the objects might intersect

CM: maybe it would take the
center of the bounding box (bounding cube?) to determine the z
coordinate
... so layeredGroup would allow you to specify the exact
ordering of the objects in the z axis

JF: i think we need further
investigation of this

ED: should we try to publish what
we have?
... or should we coordinate more?

Compositing spec

AG: i think we need to put
clipping and masking in the spec, since that's what we
resolved
... but we could add it later, and publish this now
... it is publishable as it is
... the other day i sent an email out to benjamin who had
posted that question about the soft-light equations
... i went to the pdf spec and got the new equations for
color-dodge and color-burn, and soft-light
... but i didn't quite agree with his equation for soft-light,
how he derived it from the pdf spec (for the alpha case)
... so i sent my derivations of the equations
... i think we are ok to publish what we've got
... the compositing spec follows the adobe compositing
model

<trackbot> Created
ACTION-2468 - Move the equations over to the language spec [on
Anthony Grasso - due 2009-02-24].

ACTION-2468: For the compositing
spec, that is.

<trackbot> ACTION-2468 Move
the equations over to the language spec notes added

DS: explain what is compositing,
what you'd use it for
... almost like use cases and requirements

CL: it's a good place to explain
why certain decisions were made, so that implementors don't
think "oh that's stupid, i'll do it this more logical way"
without realising why it was done that

JW: definitely rationale should
be recorded

JF: is it useful to have the
version number "1.2" in the specification?

AG: just call it
"Compositing"

DS: same with "Filters"

RESOLUTION: Pending
moving the equations, we will publish the Compositing spec and
primer
... Add clipping and masking at some later point to the
Compositing spec

Comments from roc

JW: regarding suspendRedraw, what
we've said sounds reasonable
... he's still not sure why it is needed in browsers
though
... html+css says that nothing is rendered in the middle of a
script block

DS: what about when doing
scripted animation?

JW: you'd use setTimeout(), when
each invocation of the timer handler is finished, you'd get a
rendering
... so suspendRedraw and unsuspendRedraw in the same script
block isn't useful

ED: what happens in firefox if
you have say a mouse event triggers a listener, and the
function takes a long time to execute, would you have any
updates?

JW: currently not

ED: not 100% sure if that's what
we did before, in opera

JW: you might interrupt the
script for a repaint?

ED: i'm pretty sure that in opera
9.2 or so we would do a repaint if the script is taking too
long
... i think the newer strategy is to do what firefox is
doing
... i don't want to say for sure, but i think we're doing
something like that now

JW: so roc is wondering what the
use cases are for, to have suspend/unsuspend in a different
script invocations
... he doesn't see why svg should be different from html+css in
this regard
... re clipping of filters, we'll go ahead and make that
change

ED: i think we still need to
discuss the actual solution
... i'd rather wait for the WG to make a decision on it

AG: so that's calculating their
own values for clipping filters?

JW: so the width/height
attributes wouldn't determine the size of the offscreen buffer,
but they would still define the coordinate system for the
filters to work within
... also we would need to alter feFlood to fill only the filter
region

ED: i'd like to review JW's
proposed text before going ahead with it

JW: he also had questions about
LOD functionality

DS: the idea is that LOD has no
effect on transform, it only responds to the currentScale DOM
attribute

JW: what about a foreignObject
with an SVG inside that? the currentScale in the inner document
didn't change, but the outer one did?

DS: if you zoom in the outer one,
i would not expect to change the LOD of the inner one

ED: i think that would make most
sense for authoring

DS: i don't think it's reasonable
to expect complex document fragments like that to behave in
some complicated way
... i could see always looking at the outermost currentScale,
don't think it's the most useful way though

[doug draws on the board]

SVG 1.1 errata

ED: we have actions for all of
the draft errata
... nothing to report on the tangents one, but it's not defined
well enough in 1.2T either, so there's no wording to
backport
... i think we discussed a bit in the telcon about changing the
implementation requirements chapter for animateMotion with zero
length path segments
... currently the text is specific to things that render,
paths
... i still don't think we have a conclusion on ACTION-2362

ED: so i added those
discussion/comment links
... i think tiny 1.2 defines all that boris wanted
... do we need to port that back to 1.1 in an erratum?
... so the issue about intrinsic sizing and use of svg in
css
... so we have a whole section on intrinsic sizing in 1.2T

<trackbot> Created
ACTION-2470 - Review the spec for the consisten use of glyph
and em square/cell, and get rid of character cell [on Jonathan
Watt - due 2009-02-24].

[discussion about perhaps postponing this
erratum]

ED: after this F2F we could mail
the list to point out the errata that we have at "proposed",
and that we will fold these in to SVG 1.1 second edition
... and that we're not planning to fix other things with the
second edition
... but still get comments on those errata

[we decide to postpone that one, reassigned
the action to SVG Core 2.0]

JW: seems like the right thing to
me to drop zoomrectscreen
... it assumes that you implement zooming in the way that ASV
did it

DS: i think zooming still needs
more discussion with implementors

JW: it's quite underspecified at
the moment

DS: taking out, to me, gives the
impression that we don't want that feature at all

ED: we don't implement the
rectangular selection zooming. we could, but not all UAs will
want to do that.

JW: i think it should be the
rectangle where x and y is the position of the top-left
coordinate of the viewport in user space
... established by the target of that zoom.
... so you can position an element relative to what is the new
viewport

ED: when you do this kind of
zooming, what does it change? the viewBox? the
currentScale/currentTranslate?
... is it possible to get the same information some other
way?

JW: the viewport DOM
attribute

ED: there's currentView as
well

CM: maybe that's something
different, what the currently linked to <view> element
is?

JW: you want the zoom event to be
dispatched just after the currentScale etc. attributes change,
but just before a repaint
... does opera implement previousScale/previousTranslate?

ED: i don't think so

JW: i think all of the context
information is redundant, be would would keep the zoom
event
... i think mozilla's is the most complete implementation of
SVGZoomEvent
... adobe didn't implement those properties
... we just do {previous,new}{Scale,Translate}
... maybe we shouldn't remove it all just now
... but in SVG.next, it seems like it would simplify
implementations and the spec to remove them
... so remove zoomRectScreen?

ED: yes

JW: you can use viewport
instead

DS: i don't mind removing it. i
think how zooming is handled in svg needs more work,
though.

JW: we could add a note to say
that we will deprecate {previous,new}{Scale,Translate}

CM: i think we should remove
rather than deprecate

ED: we could say in the erratum
how to do this (caching those values)

RESOLUTION:
Dropping all context info and attributes from SVGZoomEvent, and
explain how you can get {previous,new}{Scale,Translate} by
other means, but still having the event

ED: so those three errata could
be combined

ACTION-2386: join these three
errata and drop the context info and other attributes from
SVGZoomEvent

ED: this is about extending the
background image outside the viewport
... this is about if you have filter content outside the
viewport, whether that is clipped
... you specify in enable-background a rectangle
... or you can just say "new". opera is clipping to the
viewport.

ACTION-2066?

<trackbot> ACTION-2066 --
Erik Dahlström to propose wording that clarifies the use of
background image outside of the viewPort bounds -- due
2008-06-19 -- OPEN