W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Re: PDF Blending Algorithms (was RE: Minutes Sydney 2009 F2F day 2)

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 24 Feb 2009 10:09:01 +1100
Message-ID: <49A32C8D.3020007@cisra.canon.com.au>
To: Leonard Rosenthol <lrosenth@adobe.com>
CC: Erik Dahlstrom <ed@opera.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hi Leonard,

That'd be great thanks! It'll make things a bit easier for me ;)

I guess the working group can discuss at telcon on Thursday the idea of 
referencing ISO 32000-1. From my point of view I don't see any problems with 
adding the reference in though.

Regards,

Anthony

Leonard Rosenthol wrote:
> Be aware that Adobe is in the process of publishing a correction to the algorithms for ColorDodge and ColorBurn, as we discovered that the published versions were incorrect for edge cases.
> 
> I can send you the revised info if you want.
> 
> Leonard
> 
> -----Original Message-----
> From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Erik Dahlstrom
> Sent: Tuesday, February 17, 2009 2:11 AM
> To: public-svg-wg@w3.org
> Subject: Minutes Sydney 2009 F2F day 2
> 
> Minutes available here:
> 
>   http://www.w3.org/2009/02/16-svg-minutes.html
> 
> or as text here:
> 
>    [1]W3C
> 
>       [1] http://www.w3.org/
> 
>                                - DRAFT -
> 
>                    SVG Working Group Teleconference
> 
> 16 Feb 2009
> 
>    See also: [2]IRC log
> 
>       [2] http://www.w3.org/2009/02/16-svg-irc
> 
> Attendees
> 
>    Present
>    Regrets
>    Chair
>           SV_MEETING_CHAIR
> 
>    Scribe
>           jwatt, Cameron
> 
> Contents
> 
>      * [3]Topics
>          1. [4]Transforms module
>          2. [5]CSS Animations spec
>          3. [6]Compositing spec
>          4. [7]Comments from roc
>          5. [8]SVG 1.1 errata
>      * [9]Summary of Action Items
>      _________________________________________________________
> 
> 
> 
>    <trackbot> Date: 16 February 2009
> 
>    <ed__> jwatt: [10]http://www.opera.com/company/jobs/
> 
>      [10] http://www.opera.com/company/jobs/
> 
>    <ed__> not keyboard navigable in FF
> 
>    <jwatt> scribe: jwatt
> 
>    <scribe> scribenick: jwatt
> 
> Transforms module
> 
>    <ed__>
>    [11]http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html
> 
>      [11] http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html
> 
>    AG: I've been working on use cases and requirements
>    ... as per concerns raised at the tech plenary last year
> 
>    <anthony>
>    [12]http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html
> 
>      [12] http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html
> 
>    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
> 
>    <shepazu> rotate(<rotate-angle> <nx> <ny> <nz> [<cx> <cy> <cz>])
> 
>    CM: CL, what were you +1'ing?
> 
>    CL: what shepazu just said
> 
>    <heycam> Scribe: Cameron
> 
>    <heycam> ScribeNick: heycam
> 
>    JF: we introduced a transform-origin property
> 
>    DS: is this in css as well?
> 
>    JF: yes
>    ... it's essential for 3d transforms
>    ... without this property it's difficult to handle 3d
>    transformations
>    ... it's actually an extension and useful for 2d transforms
> 
>    <anthony>
>    [13]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
>    ansform-origin-property
> 
>      [13] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-origin-property
> 
>    JW: a vanishing point?
> 
>    JF: no
> 
>    JW: how is this diferent from premultiplying a 3d translate?
> 
>    JF: that's all it is
> 
>    ED: it's also in the css proposal
> 
>    JW: what's the advantage of having it separate?
> 
>    ED: you have to write more if you do it in the transform list
> 
>    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
> 
>    ED: but for the other ones, we're dropping the "3d" suffix to them?
> 
>    JF: i think we should carefully examine that
> 
>    AG: we'd need to investigate how feasible these changes are
> 
>    CM: how about backface-visibility which is in the css spec?
> 
>    [14]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#ba
>    ckface-visibility-property
> 
>      [14] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#backface-visibility-property
> 
>    JF: i think that property is useful for some use cases
>    ... currently we have no strong opinion about this
> 
>    CM: without it, you would need to animate and compute at what times
>    to hide the two faces
> 
>    ED: i agree it would be useful in some places to have this property
>    ... i don't think there's anything unsuitable for it being used in
>    svg too
> 
>    AG: should we have layeredGroup?
>    ... it's like a restricted form of z-index
> 
>    DS: what about 3d models, like rotating a cube?
> 
>    AG: layeredGroup would handle this case, as well as the
>    backface-visibility case
> 
>    ED: backface-visibility is a css property, but layeredGroup wouldn't
>    be
> 
>    <ChrisL> backface culling is common on real 3d systems, as the
>    amount of data to be sent down the pipe can often be halved. but
>    where is the back geometry coming from, in 2D?
> 
>    DS: so we may as well have backface-visibility, since we'll already
>    have it in css
> 
>    CM: should we be adding these as properties or attributes?
> 
>    DS: well if we're having these css ones, then we may as well have
>    these as properties too
>    ... and make 'transform' a property
> 
>    JW: then we really need to make the two (the svg and css
>    'transform') compatible
> 
>    [15]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
>    ansform-property
> 
>      [15] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-property
> 
>    they don't have TransformRef values
> 
>    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?
> 
>    CM: we'll do that mail on friday in that coordination session
> 
>    <scribe> ACTION: Anthony to draft an email to send to the CSS WG
>    summarising our thoughts about transforms [recorded in
>    [16]http://www.w3.org/2009/02/16-svg-minutes.html#action01]
> 
>    <trackbot> Created ACTION-2467 - Draft an email to send to the CSS
>    WG summarising our thoughts about transforms [on Anthony Grasso -
>    due 2009-02-24].
> 
> CSS Animations spec
> 
>    <ed__> [17]http://dev.w3.org/csswg/css3-animations/
> 
>      [17] http://dev.w3.org/csswg/css3-animations/
> 
>    DS: we'll discuss these later in the week, give us a chance to read
>    them
> 
>    ED: on thursday
> 
>    CM: so we should read both animations and transitions
> 
>    DS: also please read the vector effects, filters, layout reqs
>    documents for thursday
> 
> Compositing spec
> 
>    <anthony>
>    [18]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingP
>    rimer.html
> 
>      [18] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingPrimer.html
> 
>    <anthony>
>    [19]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
>    html
> 
>      [19] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
> 
>    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
> 
>    [20]http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au
> 
>      [20] http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au
> 
>    AG: benjamin's and my equations come up with slightly different
>    numbers
> 
>    CM: could you create a pdf file and check the colours to determine
>    which is correct?
>    ... did asv6 support these compositing features?
> 
>    CL: don't know, i think it did but i'm not sure
> 
>    CM: but you're ok with publishing with the equations as they are at
>    the moment?
> 
>    AG: yes
> 
>    ED: the equations are in the primer. does that mean they're not
>    normative?
> 
>    DS: i think the primer should be a shorter document that gives the
>    examples
> 
>    ED: especially in the case of the equations, then they should go in
>    the language spec
> 
>    CL: you can have non normative stuff in the language spec, but no
>    normative text in the primer
>    ... it should purely be expository, pretty examples, etc.
> 
>    AG: maybe about an hour or two's work
> 
>    <scribe> ACTION: Anthony to move the equations over to the language
>    spec [recorded in
>    [21]http://www.w3.org/2009/02/16-svg-minutes.html#action02]
> 
>    <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__> [22]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
> 
>      [22] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
> 
>    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
> 
>    ACTION-2362?
> 
>    <trackbot> ACTION-2362 -- Erik Dahlström to backport the zero length
>    path wording from 1.2T to this "Reword F.5 Tangents" erratum -- due
>    2008-12-04 -- CLOSED
> 
>    <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2362
> 
>      [23] http://www.w3.org/Graphics/SVG/WG/track/actions/2362
> 
>    <ed__>
>    [24]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth
> 
>      [24] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth
> 
>    ED: next on the list is sizing of the outermost svg
> 
>    ACTION-2370?
> 
>    <trackbot> ACTION-2370 -- Erik Dahlström to go through the e-mailing
>    thread for errata item "Sizing of the outermost svg" and update the
>    item discussion -- due 2008-12-08 -- CLOSED
> 
>    <trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/actions/2370
> 
>      [25] http://www.w3.org/Graphics/SVG/WG/track/actions/2370
> 
>    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
> 
>    JW: are we publishing a 2ed soon?
> 
>    CM: yes
>    ... incorporating just the errata
> 
>    <scribe> ACTION: jwatt to flesh out the intrinsic sizing erratum
>    with text backported from 1.2T [recorded in
>    [26]http://www.w3.org/2009/02/16-svg-minutes.html#action03]
> 
>    <trackbot> Created ACTION-2469 - Flesh out the intrinsic sizing
>    erratum with text backported from 1.2T [on Jonathan Watt - due
>    2009-02-24].
> 
>    <scribe> ACTION: jwatt to Review the spec for the consisten use of
>    glyph and em square/cell, and get rid of character cell [recorded in
>    [27]http://www.w3.org/2009/02/16-svg-minutes.html#action04]
> 
>    <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]
> 
>    <scribe> ACTION: Erik to send the mail announcing the errata and 1.1
>    second edition publication plans [recorded in
>    [28]http://www.w3.org/2009/02/16-svg-minutes.html#action05]
> 
>    <trackbot> Created ACTION-2471 - Send the mail announcing the errata
>    and 1.1 second edition publication plans [on Erik Dahlström - due
>    2009-02-24].
> 
>    <ed__>
>    [29]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomev
>    ent-interface
> 
>      [29] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomevent-interface
> 
>    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
> 
>    <trackbot> ACTION-2386 Investigate the "SVGZoomEvent - Interface"
>    errata item further notes added
> 
>    ACTION-2386?
> 
>    <trackbot> ACTION-2386 -- Jonathan Watt to investigate the
>    "SVGZoomEvent - Interface" errata item further -- due 2008-12-25 --
>    OPEN
> 
>    <trackbot> [30]http://www.w3.org/Graphics/SVG/WG/track/actions/2386
> 
>      [30] http://www.w3.org/Graphics/SVG/WG/track/actions/2386
> 
>    ED: final erratum is "currentTranslate-currentScale on nested SVG"
> 
>    [31]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttr
>    anslate-currentscale-nested-svg
> 
>      [31] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttranslate-currentscale-nested-svg
> 
>    DS: being able to zoom in on individual <svg> elements ...
> 
>    [doug draws]
> 
>    JW: i don't think currentScale/currentTransform are good anyway
>    ... you might want to keep the center centered, then zoom
>    ... or maybe zoom to a rectangle
> 
>    ED: you can use predefined <view> elements
> 
>    JW: if you click on the plus button in doug's example, you don't
>    want to just make currentScale larger, you need to also mess with
>    currentTranslate
> 
>    DS: right, but having both of them, plus a zoomToRect() method would
>    be handy
> 
>    AG: could add that to 2.0 Core
> 
>    ED: would it have to use currentTranslate/currentScale? could it use
>    viewBox instead?
>    ... you can modify viewBox with script already
> 
>    DS: so how does a viewBox work with regards to transforms and
>    regards to LOD?
> 
>    JW: it's part of the stack of transformation matrices
> 
>    DS: related is when linking to a #fragment, when the element is too
>    big to fit in the viewport
> 
>    ED: should we address that now, or later?
> 
>    DS: later. what do we do with this issue?
> 
>    <scribe> ACTION: Doug to fill in the currentTranslate/currentScale
>    erratum to explicitly make using those attributes on inner <svg>
>    elements undefined [recorded in
>    [32]http://www.w3.org/2009/02/16-svg-minutes.html#action06]
> 
>    <trackbot> Created ACTION-2472 - Fill in the
>    currentTranslate/currentScale erratum to explicitly make using those
>    attributes on inner <svg> elements undefined [on Doug Schepers - due
>    2009-02-24].
> 
>    close action-2368
> 
>    <trackbot> ACTION-2368 Propose wording for the change that addresses
>    the errata item Current Translate Current Scale on nested SVG closed
> 
>    CM: there are seven other actions for errata stuff
>    ... we'll go through them to decide whether to handle them now or
>    not
> 
>    ACTION-2067?
> 
>    <trackbot> ACTION-2067 -- Anthony Grasso to add Eriks proposed
>    wording to the Errata. Link to ACTION-2066 -- due 2008-06-19 -- OPEN
> 
>    <trackbot> [33]http://www.w3.org/Graphics/SVG/WG/track/actions/2067
> 
>      [33] http://www.w3.org/Graphics/SVG/WG/track/actions/2067
> 
>    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
> 
>    <trackbot> [34]http://www.w3.org/Graphics/SVG/WG/track/actions/2066
> 
>      [34] http://www.w3.org/Graphics/SVG/WG/track/actions/2066
> 
>    ED: i would be ok with postponing this for a bit
>    ... and just put it into the filter spec
>    ... the question is how often do you need to use enable-background
>    for content outside the viewport
> 
>    ACTION-2358?
> 
>    ACTION-2367?
> 
>    ACTION-2372?
> 
>    ACTION-2404?
> 
>    ACTION-2450?
> 
>    ACTION-2451?
> 
>    <trackbot> ACTION-2451 -- Erik Dahlström to modify the current
>    errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due
>    2009-02-16 -- OPEN
> 
>    <trackbot> [35]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
> 
>      [35] http://www.w3.org/Graphics/SVG/WG/track/actions/2451
> 
>    ACTION-2367?
> 
>    <trackbot> ACTION-2367 -- Erik Dahlström to propose an errata item
>    for rx and ry -- due 2008-12-08 -- OPEN
> 
>    <trackbot> [36]http://www.w3.org/Graphics/SVG/WG/track/actions/2367
> 
>      [36] http://www.w3.org/Graphics/SVG/WG/track/actions/2367
> 
>    ACTION-2372?
> 
>    ACTION-2372?
> 
>    <trackbot> ACTION-2372 -- Doug Schepers to propose revised wording
>    for the errata item "Capturing pointer-events with a zero opacity
>    mask" to clarify it with clip-path -- due 2008-12-11 -- OPEN
> 
>    <trackbot> [37]http://www.w3.org/Graphics/SVG/WG/track/actions/2372
> 
>      [37] http://www.w3.org/Graphics/SVG/WG/track/actions/2372
> 
>    ACTION-2404?
> 
>    <trackbot> ACTION-2404 -- Doug Schepers to add errata item for root
>    overflow -- due 2009-01-22 -- OPEN
> 
>    <trackbot> [38]http://www.w3.org/Graphics/SVG/WG/track/actions/2404
> 
>      [38] http://www.w3.org/Graphics/SVG/WG/track/actions/2404
> 
>    ACTION-2450?
> 
>    <trackbot> ACTION-2450 -- Cameron McCormack to make an errata item
>    that aligns the pace animation in 1.1 Full with that in 1.2 Tiny --
>    due 2009-02-16 -- OPEN
> 
>    <trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/actions/2450
> 
>      [39] http://www.w3.org/Graphics/SVG/WG/track/actions/2450
> 
>    ACTION-2451?
> 
>    <trackbot> ACTION-2451 -- Erik Dahlström to modify the current
>    errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due
>    2009-02-16 -- OPEN
> 
>    <trackbot> [40]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
> 
>      [40] http://www.w3.org/Graphics/SVG/WG/track/actions/2451
> 
>    ACTION-2358?
> 
>    <trackbot> ACTION-2358 -- Doug Schepers to propose wording for the
>    clip path pointer-events erratum and masking/compositing module
>    change -- due 2008-12-04 -- OPEN
> 
>    <trackbot> [41]http://www.w3.org/Graphics/SVG/WG/track/actions/2358
> 
>      [41] http://www.w3.org/Graphics/SVG/WG/track/actions/2358
> 
>    <ed__> ACTION-2367: Added testcase
>    [42]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.s
>    vg as a starting point
> 
>      [42] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg
> 
>    <trackbot> ACTION-2367 Propose an errata item for rx and ry notes
>    added
> 
>    <ed__> ACTION-2451: Added draft testcase
>    [43]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.sv
>    g
> 
>      [43] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.svg
> 
>    <trackbot> ACTION-2451 Modify the current errata item on
>    SVGTransform.matrix that addresses ISSUE-2210 notes added
> 
>    <shepazu> jwatt:
>    [44]http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html
> 
>      [44] http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html
> 
>    close ACTION-2450
> 
>    <trackbot> ACTION-2450 Make an errata item that aligns the pace
>    animation in 1.1 Full with that in 1.2 Tiny closed
> 
>    <shepazu> jwatt:
>    [45]http://lists.w3.org/Archives/Member/member-svg-editors/
> 
>      [45] http://lists.w3.org/Archives/Member/member-svg-editors/
> 
>    <ed__> trackbot, close ACTION-2451
> 
>    <trackbot> ACTION-2451 Modify the current errata item on
>    SVGTransform.matrix that addresses ISSUE-2210 closed
> 
> Summary of Action Items
> 
>    [NEW] ACTION: Anthony to draft an email to send to the CSS WG
>    summarising our thoughts about transforms [recorded in
>    [46]http://www.w3.org/2009/02/16-svg-minutes.html#action01]
>    [NEW] ACTION: Anthony to move the equations over to the language
>    spec [recorded in
>    [47]http://www.w3.org/2009/02/16-svg-minutes.html#action02]
>    [NEW] ACTION: Doug to fill in the currentTranslate/currentScale
>    erratum to explicitly make using those attributes on inner <svg>
>    elements undefined [recorded in
>    [48]http://www.w3.org/2009/02/16-svg-minutes.html#action06]
>    [NEW] ACTION: Erik to send the mail announcing the errata and 1.1
>    second edition publication plans [recorded in
>    [49]http://www.w3.org/2009/02/16-svg-minutes.html#action05]
>    [NEW] ACTION: jwatt to flesh out the intrinsic sizing erratum with
>    text backported from 1.2T [recorded in
>    [50]http://www.w3.org/2009/02/16-svg-minutes.html#action03]
>    [NEW] ACTION: jwatt to Review the spec for the consisten use of
>    glyph and em square/cell, and get rid of character cell [recorded in
>    [51]http://www.w3.org/2009/02/16-svg-minutes.html#action04]
> 
>    [End of minutes]
>      _________________________________________________________
> 
> 
>     Minutes formatted by David Booth's [52]scribe.perl version 1.133
>     ([53]CVS log)
>     $Date: 2009/02/17 07:05:54 $
>      _________________________________________________________
> 
>      [52] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>      [53] http://dev.w3.org/cvsweb/2002/scribe/
> 
> Scribe.perl diagnostic output
> 
>    [Delete this section before finalizing the minutes.]
> This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
> Check for newer version at [54]http://dev.w3.org/cvsweb/~checkout~/2002
> /scribe/
> 
>      [54] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
> 
> Guessing input format: RRSAgent_Text_Format (score 1.00)
> 
> Succeeded: s/we're saying//
> Succeeded: s/ think if we have scale3D et. al, we'd probably want the s
> ame for rotate/ think if we have rotate3D et. al, we'd probably want th
> e same naming for translate and scale, that is having the suffix 3D the
> re too/
> FAILED: s/spec a rec already?//
> Succeeded: s/whether it's possible to change our implementation/how fea
> sible these changes are/
> Succeeded: s/AG/JF/
> Succeeded: s/the own value/their own values/
> Succeeded: s/ED: i think that would make most sense/ED: i think that wo
> uld make most sense for authoring/
> Found Scribe: jwatt
> Inferring ScribeNick: jwatt
> Found ScribeNick: jwatt
> Found Scribe: Cameron
> Found ScribeNick: heycam
> Scribes: jwatt, Cameron
> ScribeNicks: jwatt, heycam
> 
> WARNING: No "Present: ... " found!
> Possibly Present: ACTION-2367 ACTION-2386 ACTION-2451 ACTION-2468 AG CL
>  CM ChrisL DS ED JF JW anthony chuckle ed__ heycam joined jun jwatt scr
> ibenick shepazu svg trackbot
> You can indicate people for the Present list like this:
>         <dbooth> Present: dbooth jonathan mary
>         <dbooth> Present+ amy
> 
> 
> WARNING: No meeting chair found!
> You should specify the meeting chair like this:
> <dbooth> Chair: dbooth
> 
> Found Date: 16 Feb 2009
> Guessing minutes URL: [55]http://www.w3.org/2009/02/16-svg-minutes.html
> People with action items: anthony doug erik jwatt
> 
>      [55] http://www.w3.org/2009/02/16-svg-minutes.html
> 
>    End of [56]scribe.perl diagnostic output]
> 
>      [56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
> 
> 
> 
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
> 
> 
> 
> 
> 
Received on Monday, 23 February 2009 23:09:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 February 2009 23:09:48 GMT