- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 08 Feb 2013 16:49:15 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
http://www.w3.org/2013/02/07-svg-minutes.html
And as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
07 Feb 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/02/07-svg-irc
Attendees
Present
+1.408.536.aaaa, +61.2.937.4.aabb, GoogleMeetingRoom,
+1.781.970.aacc, Vlad
Regrets
Chair
Cameron
Scribe
Cyril
Contents
* [3]Topics
1. [4]SVG in OpenType spec proposals
2. [5]next f2f
3. [6]Proposed combined Matrix interface
4. [7]Matrix continued
5. [8]Multiple strokes
6. [9]SVG requirements list culling continued
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 07 February 2013
<scribe> scribe: Cyril
SVG in OpenType spec proposals
<ed> scribeNick: Cyril
<heycam> Zakim: who is on the call?
heycam: as a bit of background, we met with Sairus a year ago
at Microsoft and we discussed in persons
... some issues regarding the SVG in OpenType proposal
... I recently started looking at it
... in the meantime Sairus has suggested some spec text
... and I thought a good way to engage and resolve differences
was to write down what we have in our implementation
... and start to converge both proposals
... I'm not looking for any decision today
... I don't want to publish
... now
... edwin who worked on the implementation as an intern
... wrote down the behavior that we have
... last week I turned the description more like a spec
... and sent it to the list last week
<heycam>
[11]http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html
[11] http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html
<heycam> That's Edwin's and my write up.
<heycam>
[12]http://lists.w3.org/Archives/Public/public-svgopentype/2012
Aug/att-0000/SVG_in_OpenType_WD_2012-08-07.pdf
[12]
http://lists.w3.org/Archives/Public/public-svgopentype/2012Aug/att-0000/SVG_in_OpenType_WD_2012-08-07.pdf
<heycam> That's Sairus' write up.
heycam: I think they are not terribly different
... there are a few main differences
... I've not listed them
... do you want to discuss them?
krit: the number of SVG documents is a good start
heycam: I think Robert said on the ML and gave some reasons to
support multiple documents
... in our proposal you have an index of byte ranges that
correspond to each document
... and you indicate which range of glyphs are in the document
<sairus> nick: sairus
heycam: I believe in Sairus' proposal there is a single
offset/length pair to indicate where the single compressed
document is
sairus: I sent a report
... the pros and cons of the multiple svg documents
... has been discussed
... and a new pro was subsetting glyphs
... I think the multiple svg documents approach has multiple
pros (multiple dictionnaries ...)
... emoji in one document
... latin in another document
... the issue of timeline has been brought against, not to go
... I don't know how you feel about the timeline stuff in the
proposal from last Friday
... If we go with multiple documents it is fine with me
heycam: the main advantage I can think of
... splitting avoids the overhead of having one document
running
... for all of the glyphs in the document
... you probably want to split the document to reduce the
number of glyphs active
sairus: I can imagine big fonts and relate problems
AlexD: you can also cache easily
... caching part of a document is different
cabanier: the proposal is not to have one document per glyph?
heycam: not explicitely, it would be good to have guidelines to
explain how to structure documents
cabanier: yes because resource sharing is a problem
heycam: resource sharing is not adressed in my document
... there would be no way to share across documents, we could
define extra tables with URI (blob or multi part)
... I'm not sure it's worth at this point
AlexD: there is no problem with the one document approach, but
it's more work to use existing font cache
krit: I'm not sure the font engine would be used for SVG
AlexD: I would hope they are used, because of performances
... we should be thinking of speed and performances
heycam: there is a difference between reusing existing font
cache mechanism and designing a new one
sairus: by subsettability I meant that you can create a font
with just 5 glyphs
... for embedding in another document
heycam: I remember us dicussing that last time, in one
document, subsetting changes the document order and so style
might be affected
... it's not trivial
cabanier: what kind of style would be affected ?
AlexD: nth child
cabanier: I thnk the font should be independent of the number
of child
heycam: the styling of any element shouldn't change if you
remove any element
cabanier: yes, maybe
... if you use the 5th letter, it's not going to be the 5th
child
heycam: but presumably you are writing styles because they make
sense with the document
AlexD: that should be strongly discouraged
heycam: the work to be done wouldn't be too bad
sairus: subsetting complexity is already there in truetype
... a subsetter has to follow dependencies in truetype
... guidelines for SVG may be needed, but you have to take
TrueType complexity into account
cabanier: I don't think there is an issue with the order
heycam: I would be happy with a warning to authors to avoid
styling documents that change with order
... and also warn them to do subsetting properly
cabanier: what happens if you open that svg file
heycam: you could set the viewport to view something
... you could structure your document to view the svg in some
way
cabanier: or use style= display none
heycam: display none on an ancestor of the glyph definition
... I woud want to behave just like use
... use elements are displayed even if display none is set on
the referenced ancestor
... one of the big differences btw the 2 proposals, is that you
have it compressed, we don't
... what happens when you serve a document, it may be
compressed
AlexD: WOFF is compressed
sairus: any place fonts can be embedded there are ways to
compress with more than WOFF or HTTP compression
AlexD: we should mandate compression if we allow it, it
shouldn't be optional
heycam: agree
... It might make it difficult to pass to the XML parser
... you have to allocate the uncompressed version in memory
AlexD: no you decompress it and stream it to your parser
heycam: I don't have any fundamental objections with having the
tables compressed
... I assumed it was simpler not to
nikos: one of the other differences is the SVG glpyh class
... this is a nice thing
heycam: yes this is the other major difference
nikos: it allows you to know if the glyph is present without
loading the file
sairus: it is a cache
... I defined it to know which glyphs were defined with SVG in
this font
... you could imagine clients that don't support animation
would appreciate to know it upfront
heycam: our table has index entries to say which documents
cover which glyphs
... it doesn't say if the glyph is there, if it is, it has to
be in this document
... so you'd have to open it
... the glyph range could be more than the glyphs in the
document
... there might be holes in the range
the table doesn't define the holes
scribe: say a single document, range 1 to 64000 but with only
one glyph in it
sairus: the issue is that it involves calling the svg renderer
... we should make it simple for clients to take the first step
... really making it easy, no parsing unless they have to
heycam: I feel the distinction animated/static and determining
if a glyph is there at all are two different things
... right now, you have to search the glyph id
... I can see the benefit of having the right range in the
table
... I think the sharing is a separate thing as well
sairus: we want to be precise in the index table entry
heycam: I think ti would be better with your proposal
ed: when you define you SVG glyph can you reference data coming
from the CFF or glyph tables
sairus: go across glyph technologies ?
... so far they've been seen as mutually exclusive
heycam: no proposal have this feature
sairus: I can see it would be useful, for instance style with
CSS normal glyphs
ed: I could see use cases were you want multi colored glyphs
without duplicating the glyph data
heycam: it would require special adressing
Cyril: fragment identifiers ?
sairus: it is probably not worth adding the complexity
heycam: I'm sure it would be possible to make it work
<Vlad> Would SVG renderer allow importing binary outline
descriptions into XML-based SVG document? IF not, I don't <yet>
see a use case for this references
<Cyril_> cabanier: is it written that you can't write reference
to external resources?
<Cyril_> heycam: yes
<Cyril_> sairus: could be an extension in the future, not
required for v1.0
<Cyril_> heycam: (reading vlad's comment)
<Cyril_> Vlad: you would need to import them ?
<Cyril_> Vlad: without being able to enforce it, I don't see
the use of the reference
<Cyril_> heycam: the advantages I could see, is avoiding to
duplicate
<Cyril_> ... it's basically an optimization
<Cyril_> ... you'd have to define how path animations would
work
<Cyril_> cabanier: hinting is another thing
ed: I don't think all browsers apply hinting if the outlines
are fetched for rendering (depending on scale)
heycam: I feel like it is a reasonnable way to support animated
and non animated with the same definition
... you render the document without the animation element
... I might have written a tiny example, how you could animate
a circle radius to 10 and back
... for the non animated version, you ignore the animation and
render the r attribute base value
cabanier: you limit yourself to the non animated case as a
snapshot
birtles: you could have a set that turns the glyph to something
different at the beginning
sairus: I think both main proposals have converged to having a
single glyph definitions and you render the animation or not
... just like when you print an animated svg document
heycam: people design graphics in this way for viewing animated
content in IE
... there is a way to switch on to some different graphics
Cyril: I don't know what we have decided with the snapshotTime
birtles: this requires to apply the animation
AlexD: yes, you need more than a static engine
... I don't think snapshotTime is a very good tool for that
heycam: if an app using the font wants to say render the font
statically with a snapshot time
... they'd be able to do that
<heycam> ScribeNick: heycam
shepazu: when I was reading the font spec
what file are the
fonts defined in?
are they defined in the file that is the font file?
or can they be external?
AlexD: they would be in the font file
shepazu: it seems almost arbitrary that they need to be in the
font file, rather than the document that is being rendered
what's the limitation that says we can't reference them
internally?
in which case how does this save us anything from SVG Fonts
as they are defined?
cabanier: it's backward compatible; the user doesn't know it's
SVG
the font just renders
shepazu: but isn't that also the case with what I said?
cabanier: this is not just for HTML, but everywhere
shepazu: one of the use cases I get mailed off list, is that
people like to be able to define the SVG font in the file
itself
<Cyril> heycam: the advantage of not having them in the
document is to not be able to modify them at runtime
<Cyril> shepazu: it should be explicit in the spec
<Cyril> AlexD: the big reason is to support complex scripts
<Cyril> ... there is no advantage for latin
<Cyril> ... svg fonts can be external documents
<Cyril> scribenick: Cyril
heycam: if there are particular reasons why we are choosing
this model, it should be clarified
Vlad: this is not really going to be part of the SVG spec
... this is going to be in the OpenTYpe spec
AlexD: it opens up the possibility of HTML to use SVG for text
ed: but you can already use SVG fonts with HTML
sairus: next point, I'd like to discuss is
... so far the Adobe proposal doesn't change the SVG spec
... we want to ease the burden of implementations
... there are some aspects of the SVG spec that need to be
changed in the Mozilla proposal
... the glyph id is it absolutely needed ?
... and the color by number schemes ?
heycam: we've started to add the new paint values inSVG because
they are useful in other context (markers)
... we have new keywords: context-fill and context-stroke
... you reference the text element that is using the glyph
... you can use them in the fill or stroke of the glyph
sairus: in the proposal there is a single fill or stroke
heycam: yes, no passing of arrays
sairus: I can have the base of a lower case i be rendered with
a color and the dot with another color
heycam: you could define a gplyh with some parts filled in
context fill and some other parts to be always red for instance
<shepazu> (what about passing in "parameters"?)
heycam: you can override with colors specified in the font
document
AlexD: what about gradients ?
heycam: context-fill uses the same gradient
AlexD: a gradient right now can be applied to a chunk of text
... I don't see how you could do that with the glyph based
gradient
heycam: we've made it work
... the rendering of the glyph is not passed to a font engine
... normal glyphs only
... svg glyphs we paint them ourselves
<heycam>
[13]http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html#value
-context-fill-stroke
[13]
http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html#value-context-fill-stroke
heycam: so the gradient is smoothly applied to the run of text
... have a look at example 3
cabanier: that's when the gradient is in the referencing
document, and it would be different when the gradient is in the
svg glyph document
sairus: we'd like fonts to come with various swatches of
predefined colors (extended to opacity ...) that go together
well
... and the tool would offer these color options
... each of them would have a name id
... so that the user interface could show them
... what would it take to do that?
heycam: without having thought about it too hard, using CSS
variables could be the way to do it
... how do you pass them in
... same thing as parameters
sairus: are you saying the CSS thing could coexist with the
context-fill and context-stroke ?
heycam: when you have text in the outer SVG document (SVG text)
you can fill and sttroke it. In HTML you can only fill, but
there are discussion to have stroking
... I feel that those 2 operations are special
... separate parameterized palette entries
Vlad: I support the use case that sairus presented
... we should make it stronger
... designers with specific colors in mind, wouldn't want these
colors to be modified by the outside
... just like they don't want the outlines to be modified
heycam: it is totally fine
... if you specify a fixed color value, that's it, can't be
overriden
... same thing for patterns
sairus: stroking can alter the look of the glyph
... OpenType doesn't mention stroking
... OpenType gives an alpha mask and you're free to color it
... I'm not particularly convinced that context-stroke is
useful
heycam: for me, filling and stroking are the basic primitives
that you can do to shapes
cabanier: but you won't be able to stroke an svg glyph
heycam: you will
... you will not stroke the outline
... you need to construct the document with stroke in it, if
you want it
sairus: I'd like to have a place for palette in the font spec
... I don't think it'll be implemented right now
... but it needs to be speced
... what would eb the values
heycam: that's what Leonard asked
... what we have is very web specifi
... we need to define what the context is outside of a web
context
sairus: you said SVG has color spaces ?
heycam: CMYK, spot colors ..
... in SVG 2, there is a new color syntax to refer to ICC
colors, LAB, ...
... I'm not sure all of that will be implemented in browsers
... you can have a fallback sRGB
cabanier: the browser would not have to render the spot color,
but a printer would
sairus: how would it look like
Cyril: you can use solidColor to make palettes
<heycam> [14]https://svgwg.org/svg2-draft/color.html
[14] https://svgwg.org/svg2-draft/color.html
<heycam> [15]https://svgwg.org/svg2-draft/pservers.html
[15] https://svgwg.org/svg2-draft/pservers.html
heycam: you can reference colors by name (gradient, patterns or
solid colors)
... I'm not sure that would be the best way to do it: defining
set of names controlled by the outside
... there is a proposal for parameters
... that could be better or some information in the table
header
sairus: that is one way SVG would be extended
... but not only for fonts, right?
heycam: we've added taht to the main SVG spec, because they are
useful in other situations
... markers to be style the same way as the objects they are
put on
sairus: what about glyph id
<heycam> ScribeNick: heycam
shepazu: I'm wondering about non-Web contexts
do we expect SVG glyphs to be used widely in non-Web
contexts?
and what does it mean for these context-* values in non-Web
content
there's a lot of stuff to implement SVG, even with the amount
that's specified in the SVG-in-OpenType proposal
are we going to cut that down?
<Cyril> heycam: we haven't really talked about what subset of
SVG is required
<Cyril> ... should we annotate glyphs with versions of the svg
spec
<Cyril> ... on the web we add new features and old browser do
some thing, maybe in font, it could be different handling, I
don't knonw
<Cyril> ScribeNick: Cyril
AlexD: are you expecting different engines than web engines ?
heycam: it doens't seem to make sense to not use some existing
libraries
Cyril: performances ?
heycam: you can still write your own ?
... Adobe is using webkit ?
cabanier: not decided yet
... it would be silly because SVG would be a lot of work
sairus: so far the only restriction of the type of SVG content
is secure animated mode
... I have a feeling it is best to stick to that
... not have a subset of svg defined
heycam: I would be similarly concerned with other groups
subsetting SVG
shepazu: ePub, and ODF really butchered SVG
... I wouldn't claim it to be really SVG
... if we do things right, we will be talking to hardware
manufacturers
... we should be open to extra characterization
... saying this element is not suitable for fonts
heycam: I'm not so concerned
... for instance foreignObject with HTML is this allowed in
fonts ?
AlexD: no
sairus: the SVG integration document should define that
heycam: we should look at the features in SVG and see if they
make sense in fonts
sairus: glyph id is the only remaining extension to the SVG
spec
heycam: in the Adobe proposal you propose to use the id
attribute in a particular format
... I think it's a bad idea
... another attribute would be better
... glyph id does not have effect on how things render
... it's only used to locate
... it could be added to the main SVG spec if it is a concern
sairus: OpenType and SVG processing should be separated
AlexD: using straight id, is you can use "use" elements
... composite glyphs could use use
... if you use glyph id you need to put both id and glyph id
sairus: the font tool will insure that hte ids are well formed
heycam: we can continue that one on the mailing list
Vlad: agree
... having both glyph char and glyph id is confusing
heycam: that is a separate issue
Vlad: all processing is based on glyph id, definition
additional things will be confusing
heycam: glyph char is unnecessary, only added as a convenience,
to avoid looking at the cmap
... I don't mind one way or the other
sairus: we can discuss color on the list too
heycam: final question, we don't want to continue with 2
documents
sairus: I do see 3 specs: defining the OpenType table (in OFF
spec), SVG extensions (in SVG 2 or separate document as a 1.1
extension), Mozilla recording what they implement
heycam: in our spec, there is a description of how to process
the SVG
... where should it go ?
... requirements on implementations behavior in case of error
sairus: if they are not only relevant to SVG in OpenType, they
should be in the SVG spec
... but if they are specific, they should be in OpenType
... glyph id should be mentionned in the OpenType spec but
defined in the SVG spec
heycam: maybe some wording from my spec should go into the
OpenType spec maybe
------ break -------
<birtles> scribenick: birtles
next f2f
heycam: csswg have settled on 5-7 June 2013
... in Tokyo
... so we want to be there 3-4, and make 5th the day for joint
topics
... so that was our plan, but it was contingent on CSSWG
firming up their dates
Cyril: if we need an extra day we could schedule things that
are not of interest to CSSWG members on Thurs
krit: everything is of interest to me
heycam: are 2.5 days enough?
krit: should be ok
Cyril: will there be a Web Animations f2f?
birtles: we could have one
shanestephens_: we could have one before then
RESOLUTION: The next SVG F2F will be in Tokyo from 3-5 June
2013 with 5 June being a combined day with the CSSWG
birtles: Mozilla Japan will host, but the day of the 5 June may
be at a different location
krit: what about the following f2f?
AlexD: you often get less done at TPAC
stakagi: note that the AC meeting is in Tokyo from 9-11 June
2013
AlexD: the graphical web conference may be in the Bay Area in
September
birtles: where is TPAC?
AlexD: Shenzhen, China
heycam: do people think that June, Sept and Nov is too much?
... I feel like it is
krit: what about a shared/split F2F?
AlexD: I think a lot of people here will be going to the
graphical web
... as opposed to TPAC
heycam: I think I'd prefer to go to TPAC
... for the interaction with other groups
AlexD: so maybe the graphical web should be decoupled from the
wg
... and just make it more of a web conference: focussed on
designers/developers
... so it might make sense to just to tpac
krit: some of us will have conflicts since we need to attend
css etc.
cabanier: I think we can find time
heycam: so is everyone ok to meet at tpac instead of the
graphical web?
all: yes
RESOLUTION: The F2F after Tokyo will be at TPAC in Shenzhen,
China
TPAC is 18-22 November
Proposed combined Matrix interface
<krit>
[16]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Matrix
[16] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Matrix
krit: this is a shrunken version of the proposal from Dean
... my questions are: rotate is not correct
... Dean proposed to have rotateX, rotateY, rotateZ
<krit>
[17]https://svgwg.org/svg2-draft/coords.html#InterfaceSVGMatrix
[17] https://svgwg.org/svg2-draft/coords.html#InterfaceSVGMatrix
krit: as separate arguments
... but I would prefer if they were not separate methods
... the current SVG matrix rotates just around the Z matrix
... because it's only 2D
... so it just have one argument
... Dean's proposal has three arguments
... the problem is how is this compatible with the current SVG
matrix?
<krit> rotate(x,y,z)
dino: SVGMatrix has just one argument (around the Z axis)
... but in this proposal has a function of the same name that
takes three arguments
heycam: you could overload it
dino: but normally with overloading you remove arguments from
the end, not add them at the beginning
Cyril: can you reorder them?
heycam: you don't really want z, x, y
... SVG uses just z
... in the three argument version you have x, y, z
dino: the other option is to use rotateAxisAngle
... instead of rotate(0, angle, 0)
... rotateAxisAngle(0, 1, 0, angle)
shanestephens_: if you have rotate with three arguments it's x,
y, z
dino: I much prefer the four-argument form
krit: then there's rotateFromVector(x, y)
heycam: which is already on SVGMatrix
krit: and it's 2d
... and it transforms the matrix from the centre into the
direction of the vector
heycam: it's like apply a rotation from this vector
Cyril: in some 3d languages you give a vector and then you give
an angle and rotate around the vector
krit: so in this case you give it a point, and it rotates it
there
dino: I call that look-at
krit: but the problem is we need to keep the SVG name
cabanier: does it need to be in the merged matrix too?
krit: we can make rotateFromVector work with 3D
... by adding an optional 3rd argument
... it should work
... but we can't rename it
heycam: the name makes it sound like you're doing something
*from* the vector
Cyril: and you also want rotate around vector
krit: it' not in SVG only in CSS
... I'd like to have it but it's not used a lot
... Dean's proposal is rotateAxisAngle
... maybe rotateAroundVector would make more sense?
... is that ok? instead of rotateAxisAngle?
dino: that's fine with me
birtles: why can't we rename again?
krit: because SVGMatrix would be an alias for this
heycam: not sure if it's exactly aliasing but yes, you might
use this in places where an SVGMatrix is expected
krit: rotate with 3 arguments is hard to use (for authors)
... so it might not make sense to have it at all
... and just keep rotate around the z axis
shanestephens_: I agree the three argument version is hard to
use
krit: but CSS transforms supports x and y (with just one
argument)
... we might want to have that as well to be compatible
dino: but not on this matrix interface
... if you're diving into matrix, you're doing something
complicated
krit: I added skewY and skewX from SVGMatrix
... but do we want them?
... I'd rather not add them to the interface
dmitry: I'd like to have rotate around a point
... like in SVG transform syntax
krit: we could add that
... but then do we do the same for scale?
... scale already has 3 arguments
heycam: so add another 3?
dmitry: make them optional and 0 by default
krit: then you have 6 arguments
dmitry: it's a technical toolset
... as a developer I would really like this
heycam: if we have rotate from vector, then that's another
shortcut
dmitry: if we have rotate from vector I really want rotate from
point
cabanier: maybe a new attribute on the matrix interface?
transformPoint?
krit: that's not what dmitry was asking for
... that's a global transform origin
... dmitry was asking for a per-operation transform origin
cabanier: but maybe that's what you want? to use the same
transform point?
heycam: it's like how transform origin is not as useful as it
could be already
... once you have a transform chain it's no longer useful
... in this case you'd have to reset the transform point
... I think it's pretty common to rotate/scale around a point
dmitry: I don't mind math but not excessive math
krit: do we want rotate with three additional arguments?
... scale is more complex, because you have 6 arguments
birtles: is it worth considering a 3DPoint interface for the
sake of code readability?
krit: I don't mind adding the three arguments
heycam: we already have scaleUniform and scaleNonUniform
... I think scaleUniform is more common
... for the common-case where you want to scale uniformly
around a point
... we can leave scaleUniform with a single scale factor and
add optional x/y/z arguments
krit: I don't think that's useful to scale by the same amount
in each dimension
heycam: I think it's common when you want to, e.g. zoom in, but
not deform the world
... when dmitry is doing a uniform scale he doesn't have to put
a zero in
... or 1 in the case of scale
... does it make sense to separate uniform and non-uniform
cabanier: yes
dmitry: I think it makes simple stuff simple and complicated
stuff possible
cabanier: I prefer have a transform point on the matrix, it
seems more natural
birtles: what about a point dictionary that you re-use
... then you can see { x: 0, etc.
heycam: we can make these take different arguments
... the numbers, a dictionary, a native point etc.
... it's possible, but not necessarily what we want to do
... just the float arguments would be fine
krit: the proposal from dean has radians for angles
... SVG doesn't say degrees or radians but it's assumed to be
degrees
... so for backwards-compatibility I suggest degrees
birtles: I agree
krit: next, the SVGMatrix interface uses floats
... Dean's proposal uses doubles
heycam: we should use doubles
AlexD: floats are for wimps
heycam: each time you return a float you have to extend it out
to a double
all: let's use doubles
krit: next, I added flipZ next to flipX and flipY
... just to be consistent
... not sure if it's really used
... inverse(), inverts the matrix but throws an exception if
it's not invertible
... and determinant() is the same
... there are mutable and immutable functions
... mutable operations need to reproduce the functionality but
with different names
... the current proposal does that by adding "By" for the
mutable versions
heycam: it's unfortunate that SVG uses a mix of nouns and verbs
when all of them are immutable
... some of the names sound like they are modifying the object
... why is there no mutable flipX, flipY etc.?
krit: because they're not important, what would you call them?
... I didn't find a better name but you might want to know if a
matrix is 2D or not so I added is2dMatrix()
heycam: what about is2D() ?
... since you're calling it in the context of a matrix
dmitry: can you also add a method to split a matrix into
translations etc.
krit: that was proposed
... but the problem is rotation
... how do you describe the rotation?
... you could use Euler
... but then you could lose information
... so an alternative is gimbal lock
... in CSS transforms we used quarternions
... but I don't think that's really useful for authors
dino: Euler angles still allow you to specify any angle in 3d
space
... the reason you use quarternions is for animating between
two points
... it takes the best path
dmitry: is it impossible to do the decomposition of the matrix
... could we add that method to the matrix?
krit: the Euler function?
dino: yes we could do that
heycam: is the problem that it's just one possible
decomposition amongst others
... why do we use this one
dino: because it's the most common one
heycam: what would be return value of decompose()
krit: quarternions would be four values to describe one angle
heycam: if I call decompose() I would expect to get <scale
amount>, <rotate amount>, <translate amount> etc., not "here is
a quarternion"
... how would we return those values?
... a dictionary?
... an array of numbers where position in the array determines
the meaning
krit: what do we want to return? not a quarternion?
... a quarternion just represents the rotation
dmitry: I want to get "the rotation is 45 degrees" etc.
[discussion about quarternions, matrices, quarternions,
matrices, Euler, mass confusion]
dino: why are we adding this function?
krit: I think you don't need to get these components
heycam: I think the point of this is there are things where you
do need these components
shanestephens_: I just implemented CSS decomposition in
javascript because it wasn't available
... to say decomposing gives you quarternions complicates the
issue
... it gives you the scale etc.
... so, do we want this function?
... and what format do we want it in?
... I want this function
dmitry: I and at least three others want it
shanestephens_: is anyone opposed to it except for on the basis
that it is a lot of work?
dino: I think if we do it, it should do exactly what CSS
transforms too
shanestephens_: I agree
dino: it's really only use for animations
... and in most cases when you write a tool to do the
animations, typically the user wants to change the scale
... the only time you want to decompose the matrix
... is when you don't know the steps that built up the matrix
... typically you want to know the steps that built up the
matrix and know where to apply the transformation
shanestephens_: I agree, but sometimes you're forced to work
with the matrix you're given
... I don't think it's a lot of work to do what CSS transforms
do since it's already implemented
dmitry: but often you want to work with content from another
author
... for example, a clock where you know which element the hand
is
... and you want to animate it, or measure the time etc.
dino: the only problem there is that the decomposition will
work most of the time but not all of the time
... if the matrix is unusual enough you might get an unexpected
result
... you want to go back 90 degrees but you might not go the
right way
... it might not solve all your problems
shanestephens_: but generally you can decompose and control the
decomposed result
dino: I think dmitry's case where you're just changing one
angle should be fine
... but once you're doing more than one thing
... you're more likely to run into something you didn't expect
... but I don't oppose putting it in
... but I want to be clear that it might not solve all cases
shanestephens_: it feels like when we have these algorithms
that are part of the web platform we should be exposing them to
js
krit: I'm ok with it
... the question is how to represent the result
... a dictionary?
heycam: another option would be an array of numbers
... where the order of numbers determines the meaning
... e.g. position 0 means scaleX
... but that's a bit harder to use
krit: I expect this will be used by people who know matrices
<scribe> ACTION: Dirk to work together with Cameron on a
representation of the decomposed values of a matrix [recorded
in [18]http://www.w3.org/2013/02/07-svg-minutes.html#action01]
<trackbot> Created ACTION-3456 - Work together with Cameron on
a representation of the decomposed values of a matrix [on Dirk
Schulze - due 2013-02-15].
<heycam> -- lunch break --
<heycam> ScribeNick: heycam
Matrix continued
krit: Dmitry pointed out that we also have SVGPoint in the SVG
DOM
the question is, this seems to be useful in general
we've used it on some CSS properties, to convert events from
one user space to another
do we want to provide a Point to other languages? So Point
instead of SVGPoint? which can also be transformed...
if yes, what are the pros?
Point is interesting when you want to transform it
if you want to transform it with this 4x4 Matrix, so the
point should have 4 components
heycam: 3 components?
with a 1 on the end
krit: if you transform a 4-valued Point with an arbitrary 4x4
matrix, all 4 of these coordinates could change
heycam: I would say we don't need the fourth component for a 3D
point
krit: we need the fourth component for intermediate
calculations
beside that, why would you need it? can we just drop it?
birtles: could you have a dictionary that has x, y, z plus
whatever you call the last one?
krit: w?
birtles: the z defaults to 0, the w to 1; as a dictionary it
wouldn't have methods, but something on the Matrix class could
take a dictionary and return a dictionary
so no need to define a new Point interface
when you've got a method that takes a point in, you pass in {
x: 1, y: 2 } and in 2D space you don't specify any more
krit: once you set this point, can you still read back the
fourth component?
birtles: yes the method could stick the "w" property on there
and authors could ignore it
krit: I'm not in favour of a dictionary
birtles: Matrix.transformPoint() could take a dictionary and
return a dictionary
... it's convenient to use that syntax
and you can still get ".x" from the return value
<birtles> e.g. var ret = matrix.transformPoint({ x: 23, y: 24
})
<birtles> console.log(ret.x)
dmitry: I like this; I don't like `new Point(23, 24)`
dino: I kind of like the idea of not needing a defined type
krit: SVGPoint has a transform method
what would we do with that?
ed: could just leave SVGPoint around
it's used for SVGAnimatedPoints
and it's live there
birtles: currentTranslate is also an SVGPoint
heycam: and that's live too
so we'll add a new transform method on Matrix? taking a
point?
krit: yes
I think we're deciding to use a dictionary
birtles: then you could also use that in some of the other
methods on that interface
scale() etc., instead of taking x, y, z you could take a
point
then with 2D transforms you wouldn't need to specify the last
few arguments
also when you read the code it's clearer which is x, y, z
krit: ok
dmitry: I like it [again]
krit: do we also want to have a flatten function, that converts
a 3D transform to a 2D transform?
birtles: what's the use case for that?
krit: to use it in canvas for example
you might want a 2d version of a canvas
krit: what would you do in canvas if you give a 3d matrix as
the ctm for canvas?
cabanier: I think canvas should ignore it
silently fail
cabanier: will you be able to set a CSS Transform with this
Matrix?
krit: yes
in CSS OM, in the future
dmitry: I like it
heycam: where is this Matrix living?
krit: in its own spec
I'd like to work on that spec
heycam: so what about Rect?
krit: I don't care about Rect
dmitry: Don't forget vectors
<scribe> ACTION: Cameron to investigate HTML global attributes.
[recorded in
[19]http://www.w3.org/2013/02/07-svg-minutes.html#action02]
<trackbot> Created ACTION-3457 - Investigate HTML global
attributes. [on Cameron McCormack - due 2013-02-15].
Multiple strokes
[some freeform whiteboarding about possibilities for multiple
strokes specified in properties]
stroke="red, white blue" stroke-position="-50%, 0, 50%" could
make toothpaste
like in ed's example from SVG Open
heycam: sometimes I think that 'stroke' should be a shorthand
for stroke-width, stroke-opacity, stroke-paint, etc.
<ed> my example from svgopen:
[20]http://xn--dahlstrm-t4a.net/svg/presentations/svgopen2012/p
resentation/
[20]
http://xn--dahlstrm-t4a.net/svg/presentations/svgopen2012/presentation/
SVG requirements list culling continued
[21]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Co
mmitments
[21]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
[$1\47] Clarify that svgz should be as usable everywhere svg
files can
heycam: might mean registering a new mime type for svgz
ed: not all browsers support opening svgz from the local file
system
heycam: is it enough to add a sentence saying svgz can be
opened from the file system?
ed: yes
<scribe> ACTION: Erik to do the "Clarify that svgz should be as
usable everywhere svg files can" SVG 2 requirement. [recorded
in [22]http://www.w3.org/2013/02/07-svg-minutes.html#action03]
<trackbot> Created ACTION-3458 - Do the "Clarify that svgz
should be as usable everywhere svg files can" SVG 2
requirement. [on Erik Dahlstrφm - due 2013-02-15].
RESOLUTION: We will keep the SVG 2 "Clarify that svgz should be
as usable everywhere svg files can" requirement.
[$1\47] Have a DOM method to convert a <text> element to
outline path data
heycam: it sounded like we went a bit off this idea of direct
access to the glyph data
and instead to use the Path object to do some operations on
glyph data
cabanier: it's too bad there are not platform apis to
consistently get outlines
RESOLUTION: We will defer the "Have a DOM method to convert a
<text> element to outline path data" SVG 2 requirement to the
Path object spec, but just allowing operations on glyph data
and not direct access to the data.
[$1\47] Have simpler interpolation between two paths
birtles: not having the same number of segments
I reckon it's really good to do, maybe not part of SVG 2?
we could look at that as part of Web Animations
and decide when to address that
<scribe> ACTION: Shane to investigate easier path animations.
[recorded in
[23]http://www.w3.org/2013/02/07-svg-minutes.html#action04]
<trackbot> Created ACTION-3459 - Investigate easier path
animations. [on Shane Stephens - due 2013-02-15].
RESOLUTION: We will defer the "Have simpler interpolation
between two paths" SVG 2 requirement to Web Animations,
possibly later.
[$1\47] Explicitly support Web Open Font Format (WOFF)
heycam: done
[$1\47] Add snapshot time for animated documents and may
specify how to get at the rendered image
heycam: seems like two separate things
birtles: it doesn't help for UAs that don't do animation
... better to define the document in such a way that it looks
the way it should without animations
Cyril: are there cases where you can't create content where if
the animation is not processed it wouldn't produce the same
output
AlexD: a cartoon.. frame 0 might be different/empty from what
you want
dino: maybe you don't want to show any frame of the cartoon,
maybe you want something different
people embed single frames into youtube videos, it gets used
as the poster
RESOLUTION: We will not do the "Add snapshot time for animated
documents and may specify how to get at the rendered image" SVG
2 requirement.
[$1\47] Adopt the requiredFonts attribute
heycam: I don't think this is good; you need to know that
specific glyphs are available
RESOLUTION: We will not do the "Adopt the requiredFonts
attribute" SVG 2 requirement.
[$1\47] Add the solidColor element and its properties
heycam: done
[$1\47] Follow what HTML does for RDFa and microdata
heycam: I'll think about that as part of global attributes
[$1\47] Add buffered-rendering
ed: that is done I think
[$1\47] Have the vector-effect property
ed: that is done too
[$1\47] Have the viewport-fill and viewport-fill-opacity for
zoom now should be background-color etc.
Cyril: I remember we discussed that background-color is not the
same thing as viewport-fill
heycam: nobody is excited about doing it
RESOLUTION: We will defer the "Have the viewport-fill and
viewport-fill-opacity for zoom now should be background-color
etc. " SVG 2 requirement.
[$1\47] Have constrained transformations based on SVG 1.2 Tiny
AlexD: I think they're useful
doesn't mean we should have them though
shanestephens_: we're going to look into having some form of
constrained transformation
based on some of the other requirements
I had an action to look into it
based on the results of that we can decide in June
[$1\47] Improve the bounding box text based on SVG Tiny 1.2
heycam: keep it, leave it to Doug
[$1\47] Include the improved text from SVG Tiny 1.2 on
characters and glyphs, text layout, text selection, text search
heycam: I will redo the whole chapter, will do it as part of
that
[$1\47] Have the HTML content editable feature
heycam: don't know if it's worth doing at this point
AlexD: think it's too big for SVG 2
Cyril: defer it
RESOLUTION: We will defer the "Have the HTML content editable
feature" SVG 2 requirement.
[$1\47] Have the transformBehavior feature in its spec or as
part of the merged transform spec
Cyril: we talked about this the other day
I think Shane will look at that too
[$1\47] Add the features of the SVG Tiny 1.2 animation element
but not the element itself
heycam: we've got iframe element
Cyril: but there's the timing too
birtles: time containers
Cyril: that's also related to the video element
<scribe> ACTION: Cyril to do the "Add the features of the SVG
Tiny 1.2 animation element but not the element itself" SVG 2
requirement. [recorded in
[24]http://www.w3.org/2013/02/07-svg-minutes.html#action05]
<trackbot> Created ACTION-3460 - Do the "Add the features of
the SVG Tiny 1.2 animation element but not the element itself"
SVG 2 requirement. [on Cyril Concolato - due 2013-02-15].
RESOLUTION: We will keep the "Add the features of the SVG Tiny
1.2 animation element but not the element itself" SVG 2
requirement.
[$1\47] Have synchronization support from somewhere in the web
platform
Cyril: this is Web Animations
RESOLUTION: We will defer the "Have synchronization support
from somewhere in the web platform" SVG 2 requirement to Web
Animations.
[$1\47] Have a solution for specifying focusability and
navigation order, and be consistent with HTML
heycam: Rich is looking into tabindex
RESOLUTION: We will keep the "Have a solution for specifying
focusability and navigation order, and be consistent with HTML"
SVG 2 requirement.
[$1\47] Have a mechanism for controlling focus indication,
consistent with CSS and HTML
Cyril: this was focusHighlight attribute from Tiny
ed: I don't think we even require any behaviour in Tiny
Cyril: we can leave it to Rich
RESOLUTION: We will keep the "Have a mechanism for controlling
focus indication, consistent with CSS and HTML " SVG 2
requirement.
[$1\47] Support an API to control focus consistent with HTML
krit: is this also Rich
heycam: yes
RESOLUTION: We will keep the "Support an API to control focus
consistent with HTML " SVG 2 requirement.
[$1\47] Have support for key events from DOM Level 3 Events
heycam: I don't think we need to do anything more than
reference this spec
so, keep it
RESOLUTION: We will keep the "Have support for key events from
DOM Level 3 Events " SVG 2 requirement.
[$1\47] Have the SVGRotate event from SVG Tiny 1.2
ed: I don't think it's very important
RESOLUTION: We will defer the "Have the SVGRotate event from
SVG Tiny 1.2 " SVG 2 requirement.
[$1\47] Support progress events using the HTML 5 method
heycam: this could apply to <image>
we'll already have this on <video> by using HTML's <video>
<scribe> ACTION: Cyril to look into whether Progress Events
should fire on <image>. [recorded in
[25]http://www.w3.org/2013/02/07-svg-minutes.html#action06]
<trackbot> Created ACTION-3461 - Look into whether Progress
Events should fire on <image>. [on Cyril Concolato - due
2013-02-15].
[$1\47] Adopt improved SVG Tiny 1.2 text on hit testing and
event processing
krit: I think we discussed this
heycam: I think that was isPointInFill
... if there is better wording about hit testing in Tiny we
should copy it over
RESOLUTION: We will keep the "Adopt improved SVG Tiny 1.2 text
on hit testing and event processing" SVG 2 requirement.
<scribe> ACTION: Erik to do the "Adopt improved SVG Tiny 1.2
text on hit testing and event processing" SVG 2 requirement.
[recorded in
[26]http://www.w3.org/2013/02/07-svg-minutes.html#action07]
<trackbot> Created ACTION-3462 - Do the "Adopt improved SVG
Tiny 1.2 text on hit testing and event processing" SVG 2
requirement. [on Erik Dahlstrφm - due 2013-02-15].
The next four are basically copying over better text from Tiny.
[$1\47] Adopt the improved wording on Reference Restrictions
[$1\47] Adopt the improved wording on Processing External
References
[$1\47] Adopt the text from SVG Tiny 1.2 on Indicating links
[$1\47] Merge the SVG 1.1 SE text and the SVG Tiny 1.2 text on
fragment identifiers link traversal and add media fragments
<scribe> ACTION: Erik to do the 104, 105, 106, 107 SVG 2
requirements. [recorded in
[27]http://www.w3.org/2013/02/07-svg-minutes.html#action08]
<trackbot> Created ACTION-3463 - Do the 104, 105, 106, 107 SVG
2 requirements. [on Erik Dahlstrφm - due 2013-02-15].
ACTION-3463: Not 107, Cyril will do that as part of
ACTION-3442.
<trackbot> Notes added to ACTION-3463 Do the 104, 105, 106, 107
SVG 2 requirements..
[$1\47] Define how inline scriptable content will be processed,
in compatible way to HTML5
heycam: I'll still do this
[$1\47] Merge SVG Tiny 1.2 improved text on the script element
heycam: same thing
[$1\47] Use the relevant parts from SVG Tiny 1.2 and align with
the HTML script element
heycam: also the same thing
[$1\47] Apply the changes from SVG Tiny 1.2 Animations chapter
birtles: yet to do, will do
... it's basically handling bad values in animations
[$1\47] Support xlink:href on the foreignObject element after
security verification
heycam: no, this will be iframe's job
ed: foreignObject is the defined extension point
for SVG
so will <iframe> be that in the future?
heycam: do you need href on <foreignObject>?
Cyril: if you want to include some HTML in your SVG, you have
to use foreignObject
if you want to reference it you use <iframe>
ed: it's not just HTML though
it's a custom plugin we don't know anything about
krit: you can use foreignObject for MathML too
ed: I'm fine with deferring it
RESOLUTION: We will defer the "Support xlink:href on the
foreignObject element after security verification " SVG 2
requirement.
[$1\47] Use the MicroDOM as input into the DOM improvement
designs
heycam: we've already got some DOM improvements in line
like px, etc.
ed: I think you can go quite far with the suggested
improvements we have so far
easy typed access is what I want to see, and that's what we
have now
krit: and then CSS OM will also improve this
ed: basically shorter/nicer than SVG 1.1 DOM
RESOLUTION: Nothing more to do for the " [$1\47] Use the
MicroDOM as input into the DOM improvement designs " SVG 2
requirement.
[$1\47] Have relaxed document error handling (with lacuna
values etc.) as defined in Tiny 1.2
heycam: I can take this one
<scribe> ACTION: Cameron to add relaxed document error handling
to SVG 2. [recorded in
[28]http://www.w3.org/2013/02/07-svg-minutes.html#action09]
<trackbot> Created ACTION-3464 - Add relaxed document error
handling to SVG 2. [on Cameron McCormack - due 2013-02-15].
RESOLUTION: We will keep the " [$1\47] Have relaxed document
error handling (with lacuna values etc.) as defined in Tiny 1.2
" SVG 2 requirement.
[$1\47] Add new paint values currentFillPaint,
currentStrokePaint
heycam: I think these are slightly different from context-fill,
context-stroke
these are instead like currentColor
Cyril: we can leave it with Chris
I remember seeing good examples
RESOLUTION: Deferred " [$1\47] Add new paint values
currentFillPaint, currentStrokePaint " depending on Chris'
action.
[$1\47] Clarify radial gradients with focal point on the circle
Cyril: this is already in the spec
[$1\47] Add an fr attribute to <radialGradient>
Cyril: also done
[$1\47] Use CSS3 definitions for text layout (whitespacing,
bidi, etc) that is not specific to SVG
heycam: I will stil do that
[$1\47] Use updated CSS3 specifications
heycam: I will help help do those
[$1\47] Provide a way to get glyph path data via some API
AlexD: this is a dupe
[$1\47] Move all events to Element, in accordance with the
similar move in HTML
heycam: I will still do this
[$1\47] Add a path rotation command
RESOLUTION: Defer the " [$1\47] Add a path rotation command "
requirement unless Cameron gets time.
[$1\47] Introduce evt as an alias to event in event handlers
heycam: I'll do that as part of the script reworking
[$1\47] Require object-fit and object-position
heycam: this is a dupe of 71
trackbot, close ACTION-3001
<trackbot> Closed ACTION-3001 Gather up issues regarding
object-fit and it's applied to SVG and email CSS Working Group.
[$1\47] Add text-overflow
heycam: done, Erik did it
[$1\47] Mandate support for SVG Tiny fonts
heycam: we can come back to it at a more useful time
[$1\47] Mandate the support for external style sheets, style
element and style attributes all with CSS syntax
RESOLUTION: We will keep the " [$1\47] Mandate the support for
external style sheets, style element and style attributes all
with CSS syntax " SVG 2 requirement.
[$1\47] Define how border and background apply to SVG
krit: to the <svg> root element maybe
inside SVG, I don't think there's a lot to define
RESOLUTION: We will keep the " [$1\47] Define how border and
background apply to SVG " SVG 2 requirement.
[$1\47] Define the outline property for use on SVG elements
heycam: Rich can look at this as part of the focus work
[$1\47] Clarify how pointer-events can hit the root svg or not
krit: this just needs some clarifications
RESOLUTION: We will keep the " [$1\47] Clarify how
pointer-events can hit the root svg or not " SVG 2 requirement.
[$1\47] Drop xlink prefix for href
AlexD: yes
heycam: Chris has the action, I can pick up the rest if need be
RESOLUTION: We will keep the " [$1\47] Drop xlink prefix for
href " SVG 2 requirement.
[$1\47] Remove the restriction of tref pointing to only an SVG
document fragment
heycam: I did that the other day
[$1\47] Support the feature of SMIL time containers
RESOLUTION: Defer " [$1\47] Support the feature of SMIL time
containers " to Web Animations.
[$1\47] Support animation triggers based on keyboard input,
pending a proposal on security issues
RESOLUTION: Defer " [$1\47] Support animation triggers based on
keyboard input, pending a proposal on security issues " to Web
Animations.
[$1\47] Support a means for having SMIL animations start before
their time container has fully loaded
birtles: that's in Web Animations too
Cyril: I think that's already integrated into the spec
[$1\47] have <discard> element to declaratively discard
elements from the document tree
<scribe> ACTION: Brian to add IDL for discard element.
[recorded in
[29]http://www.w3.org/2013/02/07-svg-minutes.html#action10]
<trackbot> Created ACTION-3465 - Add IDL for discard element.
[on Brian Birtles - due 2013-02-15].
[$1\47] Support the playbackOrder attribute to inform UA to not
display controls to seek backwards
Cyril: it's already in there too
Brian had a comment on it
birtles: what's this one?
Cyril: this tells you there are no forward references
birtles: I don't like it
Cyril: if noone implements it we'll remove it
[$1\47] Allow masks to use either alpha or luminance or both
birtles: I've done that
in CSS Masking anyway
[$1\47] Support <canvas> element in SVG 2
birtles: that's part of Takagi-san's action
[$1\47] Relax restriction on masks pointing to mask element
only
birtles: I thought we fixed that
ed: if you point to a <circle> directly from the mask property
krit: yes this is fixed
<scribe> [NEW] Control the order of painting and filling and
markers
heycam: that one is done
-- 15 minute break --
Summary of Action Items
[NEW] ACTION: Brian to add IDL for discard element. [recorded
in [30]http://www.w3.org/2013/02/07-svg-minutes.html#action10]
[NEW] ACTION: Cameron to add relaxed document error handling to
SVG 2. [recorded in
[31]http://www.w3.org/2013/02/07-svg-minutes.html#action09]
[NEW] ACTION: Cameron to investigate HTML global attributes.
[recorded in
[32]http://www.w3.org/2013/02/07-svg-minutes.html#action02]
[NEW] ACTION: Cyril to do the "Add the features of the SVG Tiny
1.2 animation element but not the element itself" SVG 2
requirement. [recorded in
[33]http://www.w3.org/2013/02/07-svg-minutes.html#action05]
[NEW] ACTION: Cyril to look into whether Progress Events should
fire on <image>. [recorded in
[34]http://www.w3.org/2013/02/07-svg-minutes.html#action06]
[NEW] ACTION: Dirk to work together with Cameron on a
representation of the decomposed values of a matrix [recorded
in [35]http://www.w3.org/2013/02/07-svg-minutes.html#action01]
[NEW] ACTION: Erik to do the "Adopt improved SVG Tiny 1.2 text
on hit testing and event processing" SVG 2 requirement.
[recorded in
[36]http://www.w3.org/2013/02/07-svg-minutes.html#action07]
[NEW] ACTION: Erik to do the "Clarify that svgz should be as
usable everywhere svg files can" SVG 2 requirement. [recorded
in [37]http://www.w3.org/2013/02/07-svg-minutes.html#action03]
[NEW] ACTION: Erik to do the 104, 105, 106, 107 SVG 2
requirements. [recorded in
[38]http://www.w3.org/2013/02/07-svg-minutes.html#action08]
[NEW] ACTION: Shane to investigate easier path animations.
[recorded in
[39]http://www.w3.org/2013/02/07-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
Received on Friday, 8 February 2013 05:49:58 UTC