See also: IRC log
<trackbot> Date: 07 February 2013
<scribe> scribe: Cyril
<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> http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html
<heycam> That's Edwin's and my write up.
<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> 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> https://svgwg.org/svg2-draft/color.html
<heycam> 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
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
<krit> 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> 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 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
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 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].
[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: http://xn--dahlstrm-t4a.net/svg/presentations/svgopen2012/presentation/
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
[79] 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 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.
[80] 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.
[81] 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 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.
[82] Explicitly support Web Open Font Format (WOFF)
heycam: done
[83] 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.
[84] 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.
[85] Add the solidColor element and its properties
heycam: done
[86] Follow what HTML does for RDFa and microdata
heycam: I'll think about that as part of global attributes
[87] Add buffered-rendering
ed: that is done I think
[88] Have the vector-effect property
ed: that is done too
[89] 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.
[90] 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
[91] Improve the bounding box text based on SVG Tiny 1.2
heycam: keep it, leave it to Doug
[92] 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
[93] 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.
[94] 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
[95] 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 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.
[96] 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.
[97] 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.
[98] 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.
[99] 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.
[100] 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.
[101] 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.
[102] 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 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].
[103] 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 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.
[104] Adopt the improved wording on Reference Restrictions
[105] Adopt the improved wording on Processing External References
[106] Adopt the text from SVG Tiny 1.2 on Indicating links
[107] 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 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..
[108] Define how inline scriptable content will be processed, in compatible way to HTML5
heycam: I'll still do this
[109] Merge SVG Tiny 1.2 improved text on the script element
heycam: same thing
[110] Use the relevant parts from SVG Tiny 1.2 and align with the HTML script element
heycam: also the same thing
[111] Apply the changes from SVG Tiny 1.2 Animations chapter
birtles: yet to do, will do
... it's basically handling bad values in animations
[112] 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.
[113] 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 " [113] Use the MicroDOM as input into the DOM improvement designs " SVG 2 requirement.
[114] 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 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 " [114] Have relaxed document error handling (with lacuna values etc.) as defined in Tiny 1.2 " SVG 2 requirement.
[115] 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 " [115] Add new paint values currentFillPaint, currentStrokePaint " depending on Chris' action.
[116] Clarify radial gradients with focal point on the circle
Cyril: this is already in the spec
[117] Add an fr attribute to <radialGradient>
Cyril: also done
[118] Use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG
heycam: I will stil do that
[119] Use updated CSS3 specifications
heycam: I will help help do those
[120] Provide a way to get glyph path data via some API
AlexD: this is a dupe
[121] Move all events to Element, in accordance with the similar move in HTML
heycam: I will still do this
[122] Add a path rotation command
RESOLUTION: Defer the " [122] Add a path rotation command " requirement unless Cameron gets time.
[123] Introduce evt as an alias to event in event handlers
heycam: I'll do that as part of the script reworking
[124] 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.
[125] Add text-overflow
heycam: done, Erik did it
[126] Mandate support for SVG Tiny fonts
heycam: we can come back to it at a more useful time
[127] Mandate the support for external style sheets, style element and style attributes all with CSS syntax
RESOLUTION: We will keep the " [127] Mandate the support for external style sheets, style element and style attributes all with CSS syntax " SVG 2 requirement.
[128] 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 " [128] Define how border and background apply to SVG " SVG 2 requirement.
[129] Define the outline property for use on SVG elements
heycam: Rich can look at this as part of the focus work
[130] Clarify how pointer-events can hit the root svg or not
krit: this just needs some clarifications
RESOLUTION: We will keep the " [130] Clarify how pointer-events can hit the root svg or not " SVG 2 requirement.
[131] 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 " [131] Drop xlink prefix for href " SVG 2 requirement.
[132] Remove the restriction of tref pointing to only an SVG document fragment
heycam: I did that the other day
[133] Support the feature of SMIL time containers
RESOLUTION: Defer " [133] Support the feature of SMIL time containers " to Web Animations.
[134] Support animation triggers based on keyboard input, pending a proposal on security issues
RESOLUTION: Defer " [134] Support animation triggers based on keyboard input, pending a proposal on security issues " to Web Animations.
[135] 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
[136] have <discard> element to declaratively discard elements from the document tree
<scribe> ACTION: Brian to add IDL for discard element. [recorded in 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].
[137] 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
[138] Allow masks to use either alpha or luminance or both
birtles: I've done that
… in CSS Masking anyway
[139] Support <canvas> element in SVG 2
birtles: that's part of Takagi-san's action
[140] 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 --
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/krit/sairus/ Succeeded: s/heycam/AlexD/ Succeeded: s/have too/have to/ Succeeded: s/define/reference/ Succeeded: s/invert/import/ Succeeded: s/ I don't think that's what all browsers do/ I don't think all browsers apply hinting if the outlines are fetched for rendering (depending on scale)/ Succeeded: s/contextFill/context-fill/g Succeeded: s/contextStroke/context-stroke/g Succeeded: s/as separate methods/as separate arguments/ Succeeded: s/rotate(angle, angle, angle)/rotate(0, angle, 0)/ Succeeded: s/invert(), /inverse(), / Succeeded: s/I d/D/ Succeeded: s/… what's this one/birtles: what's this one/ Found Scribe: Cyril Inferring ScribeNick: Cyril Found ScribeNick: Cyril Found ScribeNick: heycam Found ScribeNick: Cyril Found ScribeNick: heycam Found ScribeNick: Cyril Found ScribeNick: birtles Found ScribeNick: heycam ScribeNicks: Cyril, heycam, birtles Default Present: +1.408.536.aaaa, +61.2.937.4.aabb, GoogleMeetingRoom, +1.781.970.aacc, Vlad Present: +1.408.536.aaaa +61.2.937.4.aabb GoogleMeetingRoom +1.781.970.aacc Vlad Found Date: 07 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/07-svg-minutes.html People with action items: brian cameron cyril dirk erik shane[End of scribe.perl diagnostic output]