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