SVG Working Group Teleconference -- 07 Feb 2013

<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> http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html

<heycam> That's Edwin's and my write up.

<heycam> 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> 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

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> 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

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 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: http://xn--dahlstrm-t4a.net/svg/presentations/svgopen2012/presentation/

SVG requirements list culling continued

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 --

- DRAFT -

SVG Working Group Teleconference

07 Feb 2013

Attendees

Contents

SVG in OpenType spec proposals

next f2f

Proposed combined Matrix interface

Matrix continued

Multiple strokes

SVG requirements list culling continued

Summary of Action Items

Scribe.perl diagnostic output