16:07:55 <RRSAgent> RRSAgent has joined #svg
16:07:55 <RRSAgent> logging to http://www.w3.org/2011/07/27-svg-irc
16:07:57 <trackbot> RRSAgent, make logs public
16:07:57 <Zakim> Zakim has joined #svg
16:07:59 <trackbot> Zakim, this will be GA_SVGWG
16:07:59 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:08:00 <trackbot> Meeting: SVG Working Group Teleconference
16:08:00 <trackbot> Date: 27 July 2011
16:08:09 <shepazu> zakim, room for 4?
16:08:11 <Zakim> ok, shepazu; conference Team_(svg)16:08Z scheduled with code 26631 (CONF1) for 60 minutes until 1708Z; however, please note that capacity is now overbooked
16:08:40 <vhardy_> ScribeNick: vhardy
16:08:47 <shepazu> zakim, code?
16:08:47 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), shepazu
16:09:05 <vhardy_> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
16:09:07 <birtles> birtles has joined #svg
16:09:16 <Zakim> Team_(svg)16:08Z has now started
16:09:23 <Zakim> + +1.206.675.aaaa
16:10:38 <vhardy_> heycam: Topic Glyph Selection
16:10:59 <stearns_> stearns_ has joined #svg
16:11:11 <heycam> Zakim, who is on the call?
16:11:11 <Zakim> On the phone I see +1.206.675.aaaa
16:11:22 <heycam> Zakim, code?
16:11:22 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
16:11:25 <vhardy_> Topic: Glyph Selection
16:11:39 <ChrisL> ChrisL has joined #svg
16:11:56 <ChrisL> rrsagent, here
16:11:56 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T16-11-56
16:12:06 <ChrisL> rrsagent, this meeting spans midnight
16:12:11 <tabatkins_> tabatkins_ has joined #svg
16:12:34 <Zakim> + +33.9.53.77.aabb
16:12:54 <vhardy_> Present: heycam, brian, ed, cabanier, cyril, stearns_, tabatkins_, tbah, shepazu
16:13:16 <vhardy_> cabanier: this is an issue that came up a couple months ago like SVG does not let you select particular glyphs.
16:13:56 <dino> dino has joined #svg
16:14:00 <vhardy_> cabanier: my proposal is to mimic what PDF does. Instead of specifying characters, you could specify offsets in the font. It would not rely on the text layout engine. 
16:14:04 <Zakim> +ChrisL
16:14:28 <jenyu> jenyu has joined #svg
16:14:53 <vhardy_> heycam: talking about encoding may be misleading.
16:15:26 <vhardy_> cabanier: with identity encoding, the code is an index pointing to a glyph.
16:15:57 <vhardy_> cabanier: so this is very specific to the font you pick. If the font is not available, it does not work.
16:16:02 <dino_> dino_ has joined #svg
16:16:08 <shepazu> Zakim, mute tbah 
16:16:08 <Zakim> sorry, shepazu, I do not know which phone connection belongs to tbah
16:16:17 <ChrisL> its glyph encoding, not character encoding
16:16:19 <vhardy_> heycam: so you are talking about having glyph indices instead of text characters.
16:16:23 <shepazu> Zakim,  who's here?
16:16:23 <Zakim> On the phone I see +1.206.675.aaaa, +33.9.53.77.aabb, ChrisL
16:16:24 <Zakim> On IRC I see dino_, jenyu, dino, tabatkins_, ChrisL, stearns_, birtles, Zakim, RRSAgent, cyril, vhardy_, shepazu, thorton, cabanier, heycam, tbah, anne, jwatt, hober, karl,
16:16:27 <vhardy_> cabanier: yes, that gives you more access.
16:16:27 <Zakim> ... dholbert, ed, trackbot
16:16:35 <shepazu> Zakim, aabb is tbah 
16:16:35 <Zakim> +tbah; got it
16:16:36 <vhardy_> birtles: what about accessibility?
16:16:45 <shepazu> Zakim, mute tbah
16:16:45 <Zakim> tbah should now be muted
16:17:00 <vhardy_> cabanier: in the PDF precedent, there is a mapping between the glyphs and the unicode characters.
16:17:07 <ChrisL> yeah the accessibility folks are going to love this. there is no access t the text.
16:17:28 <vhardy_> heycam: so you specify glyph id to unicode character mapping.
16:17:45 <ChrisL> and if we put it in an attribute then the I18n folks will shout, to. So it needs to be element content
16:17:56 <vhardy_> birtles: so for a user agent, you would have to have a mapping table.
16:17:58 <vhardy_> cabanier: yes.
16:18:35 <vhardy_> birtles: there is some work that John Dagget on variation selectors. is that relevant here.
16:19:21 <vhardy_> vhardy: are you talking about IVSes?
16:19:47 <ChrisL> http://www.w3.org/Talks/2010/ChrisLilley-SVG-LaCantine/cover.svg requires firefox 4+
16:19:51 <vhardy_> birtles: yes, but I was also thinking of specific properties to chose ligatures.
16:20:06 <vhardy_> birtles: would that be enough?
16:20:22 <vhardy_> chril: this is experimental syntax in FF. 
16:21:27 <ChrisL> it uses vendor prefixes
16:21:31 <ChrisL> eg  .dlig {font-size: 60px ; -moz-font-feature-settings: "dlig=1,ss01=1,case=1"; }
16:22:31 <vhardy_> vhardy: the requirement is to provide absolute control over the glyph selection and their positioning.
16:22:37 <vhardy_> heycam: do you have a proposal?
16:22:49 <vhardy_> cabanier: not yet. Would like to offer the same feature level as PDF.
16:23:33 <shepazu> q+
16:24:07 <vhardy_> heycam: Example:
16:24:55 <vhardy_> .... <text x="10 20 30"><altGlyph xlink:href="#a">a</altGlyph>...</text>
16:25:31 <vhardy_> <altGlyphDef id="a"><glyphRef glyph-name="..." /> </altGlyphName>
16:26:23 <vhardy_> heycam: the altGlyph element allows you to select the specific glyph to use for a particular run of text. 
16:26:44 <vhardy_> cabanier: wouldn't the text engine still try to do ligatures?
16:26:56 <vhardy_> heycam: yes, without altGlyph. Not with altGlyph.
16:27:23 <vhardy_> shepazu: with the current mechanisms, you can disable ligatures if you want to.
16:28:14 <vhardy_> cyril: what about glyph substitution?
16:28:19 <ChrisL> 6.5 Ligatures: the font-variant-ligatures property
16:28:26 <vhardy_> heycam: If you select a glyph, there is no substitution.
16:28:28 <ChrisL> http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
16:28:40 <ChrisL> Value: 	normal | inherit | [ <common-lig-values> || <additional-lig-values> || <historical-lig-values> ] 
16:29:03 <vhardy_> shepazu: if you wanted a particular shape, you could use a combiniation of markup and styling to achieve the effect.
16:29:54 <vhardy_> heycam: in the use case I presented, you want no layout at all.
16:30:24 <ChrisL> 6.9 Defining font specific alternates: the @font-feature-values rule
16:30:29 <vhardy_> shepazu: I do not see a collection of what we want on the wiki page. Are we sure we have the requirements clear?
16:30:31 <ChrisL> http://dev.w3.org/csswg/css3-fonts/#font-feature-values
16:30:36 <vhardy_> cabanier, heycam: yes. 
16:31:00 <vhardy_> heycam: if you have a tool that has done the glyph selection and layout and you want to guarantee the output, you need a solution like this.
16:31:12 <vhardy_> cyril: why not use shapes in that case?
16:31:20 <vhardy_> cabanier: you would lose accessibility.
16:31:43 <vhardy_> shepazu: you could use a graphic and a <title>
16:33:24 <vhardy_> vhardy: you also need a solution like this if you have a significant chunk of text. Having all path is verbose.
16:33:50 <vhardy_> shepazu: another use case is groovy text with interlocking shapes.
16:34:13 <vhardy_> stearns: yes, there are fonts that have the right combinations of glyphs, and you could select those easily.
16:37:39 <TabAtkin1_> TabAtkin1_ has joined #svg
16:37:42 <vhardy_> shepazu: show an example of "Groovy text" with intertwined glyphs.
16:38:27 <vhardy_> (discussion about whether the altGlyph could also reference a shape.
16:39:39 <vhardy_> s/shape./shape)
16:41:07 <vhardy_> heycam: 3 main things:
16:41:15 <vhardy_> .. 1. how you reference a glyph in a font
16:41:30 <vhardy_> by id and have that disable glyph selection.
16:41:57 <vhardy_> .. 2. positioning 'characters' instead of glyphs in the <text> element's x attribute
16:42:28 <vhardy_> .. 3. ability to have an altGlyph reference a shape.
16:43:00 <vhardy_> shepazu: if we had capability #3, people would use it.
16:44:23 <vhardy_> (discussion on text path and shape path).
16:44:41 <vhardy_> shepazu: there has not been proposal to get shapes as part of a text layout.
16:46:46 <vhardy_> vhardy: to get back to cabanier's proposal, I think we have:
16:47:23 <vhardy_> ... 1. there is a mechanism for selecting specific glyph. It is clear for SVG fonts. The first issue is to clarify how to do that for other font formats, in particular opentype fonts.
16:47:44 <vhardy_> ... 2. there is a mechanism for positioning characters (x and y attributes) and that should be positioning glyphs.
16:48:13 <vhardy_> ... 3. If 1 and 2 are addressed, we need to see if the solution would be terse enough to be acceptable.
16:51:38 <vhardy_> shepazu: Here is an example for groovy text:
16:51:53 <vhardy_> <g x-advance=".." id="groovytext">
16:51:58 <vhardy_>    <path .../>
16:52:02 <vhardy_>     <path .../>
16:52:04 <vhardy_> </g>
16:52:20 <vhardy_> heycam: yes, it would make a solution simpler.
16:52:31 <plinss_> plinss_ has joined #svg
16:52:33 <vhardy_> shepazu: yes, and it would avoid the font coordinate orientation issue.
16:54:51 <vhardy_> (discussion about the text x/y positions and how they work with ligatures)
16:56:07 <vhardy_> heycam: for example if you have <text x="10 20 30">ffe<text>
16:56:32 <vhardy_> if the font has the ff ligature, the first glyph (for ff) will be at x=10 and the second glyph (for e) will be positioned at 20.
16:57:02 <vhardy_> if there is no ligature for ff, the first f is at 10, the second at 20 and e at 30.
16:57:50 <vhardy_> birtles: jdaggett says we should talk about glyph clusters and not glyphs.
16:58:09 <vhardy_> stearns shows a hindic example where the cluster is made of multiple glyphs.
17:01:50 <Zakim> -ChrisL
17:02:10 <ChrisL> sigh. I'm going to get dropped every 50 minutes
17:02:50 <Zakim> +ChrisL
17:03:37 <vhardy_> ACTION: cabanier to define how to use <glyphRef>'s glyphRef attribute to point to an openType glyph and make sure it works with the different openType format variations.
17:03:37 <trackbot> Created ACTION-3073 - Define how to use <glyphRef>'s glyphRef attribute to point to an openType glyph and make sure it works with the different openType format variations. [on Rik Cabanier - due 2011-08-03].
17:08:15 <vhardy_> ACTION-3073: Report on how this would work with the shaping process.
17:08:15 <trackbot> ACTION-3073 Define how to use <glyphRef>'s glyphRef attribute to point to an openType glyph and make sure it works with the different openType format variations. notes added
17:09:19 <vhardy_> (discussion on character and glyph positioning).
17:11:24 <vhardy_> heycam: when altGlyphs are used we should allow the author to skip extraneous x/y values that are not used because of ligatures.
17:14:24 <vhardy_> ACTION: cabanier to work with vhardy and text experts on x/y positioning and altGlyphDef and altGlyph.
17:14:24 <trackbot> Created ACTION-3074 - Work with vhardy and text experts on x/y positioning and altGlyphDef and altGlyph. [on Rik Cabanier - due 2011-08-03].
17:15:13 <cyril> cyril has joined #svg
17:15:14 <Zakim> -tbah
17:15:49 <vhardy_> vhardy: what is the support for altGlyph and altGlyphDef?
17:15:58 <vhardy_> ed: Opera and WebKit have some support for SVG fonts.
17:17:09 <ed> s/ some support for SVG fonts./ support altGlyph for SVG fonts, but not altGlyph for Opentype fonts AFAIK./
17:17:32 <tbah> Call ended....
17:17:57 <vhardy_> heycam: we should be able to extend the syntax if needed.
17:18:16 <vhardy_> birtle: we also need to keep accessibility in mind in the new solution.
17:18:34 <Zakim> ok, shepazu; conference Team_(svg)17:18Z scheduled with code 26631 (CONF1) for 60 minutes until 1818Z
17:18:42 <Zakim> - +1.206.675.aaaa
17:18:54 <Zakim> -ChrisL
17:18:56 <Zakim> Team_(svg)16:08Z has ended
17:18:57 <Zakim> Attendees were +1.206.675.aaaa, +33.9.53.77.aabb, ChrisL, tbah
17:19:13 <Zakim> Team_(svg)17:18Z has now started
17:19:20 <Zakim> +tbah
17:19:43 <Zakim> +ChrisL
17:19:53 <Zakim> + +1.206.675.aaaa
17:21:53 <vhardy_> ACTION: shepazu to create a proposal for "Groovy Text", i.e., a solution for easily provide the graphical rendering of a piece of text with SVG graphics.
17:21:53 <trackbot> Created ACTION-3075 - Create a proposal for "Groovy Text", i.e., a solution for easily provide the graphical rendering of a piece of text with SVG graphics. [on Doug Schepers - due 2011-08-03].
17:22:37 <dino> dino has joined #svg
17:23:50 <vhardy_> Topic: text warping
17:24:04 <vhardy_> heycam: tbah, can you summarize the issue.
17:24:25 <tbah> http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html
17:25:09 <vhardy_> tbah: this is following our last discussion on Israel's examples.
17:25:28 <anne> anne has joined #svg
17:25:29 <vhardy_> tbah: you can see the limitations with wide characters and text stretch.
17:25:46 <vhardy_> tbah: I have looked at the different ways that InkScape can distort paths.
17:25:57 <vhardy_> tbah: the most interesting are the ones at the bottom.
17:26:20 <vhardy_> tbah: the ones done as envelope deformations.
17:26:28 <ChrisL> using Inkscape's Envelope Deformation LPE
17:26:33 <vhardy_> tbah: it uses for paths, top, bottom, left and right.
17:26:50 <vhardy_> tbah: InkScape keeps the original path.
17:27:48 <vhardy_> tbah: it shows the kind of things you could do.
17:27:59 <vhardy_> tbah: it works nicely.
17:28:27 <vhardy_> tbah: the algorithm does not preserve vertical lines
17:28:48 <vhardy_> tbah: the person that wrote this code for InkScape could modify to do whatever we want.
17:29:02 <vhardy_> tbah: it would be nice to do that without converting to a path. 
17:29:23 <vhardy_> tbah: it would also be nice to use the base line of the text instead of the visual bounding box bottom edge
17:29:43 <vhardy_> heycam: question: none of the glyphs have descenders in the examples.
17:29:46 <ChrisL> base line and ascent as top and bottom paths
17:29:57 <vhardy_> tbah: if they had descenders, they would be shifted up.
17:30:04 <vhardy_> tbah: there is an example.
17:30:10 <thorton> thorton has joined #svg
17:30:39 <vhardy_> (example with descender has 'Sample Text: Office')
17:30:49 <vhardy_> shepazu: this satisfies some of the Groovy text examples.
17:30:59 <vhardy_> shepazu: how hard is this to implement.
17:31:11 <vhardy_> tbah: the implementation is complicated, but it is pretty fast.
17:31:19 <ChrisL> a path is converted to an SBasis (Symmetric power basis) polynomial representation, transformed, and then converted back to Bezier curves. This is done using the lib2geom library package
17:32:06 <vhardy_> tbah: it subdivides the path into small chunks and then transforms them.
17:32:19 <vhardy_> chrisl: it would be better to transform the control points and avoid subdividing.
17:32:50 <vhardy_> tbah: I have thought about that for straight lines, and it is not clear how you add control points, where you add them and how they get transformed.
17:32:58 <vhardy_> heycam: I think you need to subdivide.
17:33:14 <vhardy_> chrisl: I do not agree you need to subdivide. It is one way, that is not the only.
17:33:40 <ChrisL> NURBs
17:34:46 <ChrisL> I notice that lib2geom also has nurrbs support
17:35:04 <vhardy_> (discussion on the merits of converting to and back to NURBS or other representation and how this will create more Bezier curves in general, but may be better than subdividing upfront).
17:35:36 <vhardy_> tbah: lib2geom uses convertion to SBasis curves.
17:36:41 <vhardy_> tbah: InkScape uses these curves extensively.
17:37:07 <vhardy_> heycam: is it simpler to use text on a path and warping that v.s. 4 different paths on all sides.
17:37:21 <vhardy_> ... algorithmically simpler.
17:37:52 <vhardy_> tbah: I dont think it is necessarily simpler.
17:38:21 <ChrisL> lib2geom has an irc dump as documentation :)
17:38:37 <Zakim> - +1.206.675.aaaa
17:38:40 <Zakim> -tbah
17:38:43 <Zakim> -ChrisL
17:38:44 <Zakim> Team_(svg)17:18Z has ended
17:38:46 <Zakim> Attendees were tbah, ChrisL, +1.206.675.aaaa
17:48:57 <ChrisL> quote
17:48:59 <ChrisL> All of these operations are fast.  For example, multiplication of two
17:48:59 <ChrisL> beziers by converting to s-basis form, multiplying and converting back
17:48:59 <ChrisL> takes roughly the same time as performing the bezier multiplication
17:48:59 <ChrisL> directly, and furthermore, subdivision and degree reduction are
17:48:59 <ChrisL> straightforward in this form.
17:49:04 <ChrisL> unquote
17:49:12 <heycam> yeah
17:49:20 <heycam> I would love to understand how those s-basis curves work :)
17:49:26 <heycam> and the conversion between them and beziers
17:49:40 <ChrisL> \cite{SanchezReyes1997,SanchezReyes2000,SanchezReyes2001,SanchezReyes2003,SanchezReyes2004}.
17:50:10 <ChrisL> the same library uses SBasic curves to do the union and difference operations
17:50:29 <tbah> I would doubt this would use much CPU as compared to some of the filters.
17:50:36 <heycam> heh
17:50:45 <heycam> maybe we can get gpu accelerated path warping
17:54:01 <dino> dino has joined #svg
17:56:19 <tbah> The warped D in one of my examples has 33 nodes after warping compared to 30 before so converting
17:56:36 <tbah> to and from the s-basis form doesn't seem to add that many extra nodes.
17:57:27 <heycam> nice
17:57:28 <ChrisL> right. i would expect the node increase to be proportional to the degree f warping
17:57:55 <ChrisL> tha tis a bg difference froma  pre-subdivide or pre-tesellation approach
17:59:39 <heycam> yeah, I agree
18:03:37 <TabAtkins__> ScribeNick: TabAtkins__ 
18:03:49 <Zakim> Team_(svg)17:18Z has now started
18:03:56 <Zakim> + +1.206.675.aaaa
18:04:20 <Zakim> +tbah
18:04:56 <TabAtkins__> shepazu: What is the scope or place for this?  SVG2, or a special module, or what?
18:05:05 <TabAtkins__> tbah: Dunno.
18:05:16 <TabAtkins__> tbah: This started as a way of clarifying what to do with the "stretch" value.
18:05:34 <TabAtkins__> vhardy_: What was israel asking for?
18:05:47 <Zakim> +ChrisL
18:05:53 <TabAtkins__> ed: First he was just asking for "stretch" to be clarified.  As it went on, he moved to wanting a more expressive modle.
18:06:13 <TabAtkins__> vhardy_: One possibility is to just give access to the text geometry, and let you do crazy things with the geometry yourself.
18:06:29 <TabAtkins__> vhardy_: Java2d had something similar, where it gave you the geometry of the text outline.
18:06:37 <TabAtkins__> heycam: That's probably a good short step forward.
18:06:47 <ChrisL> rrsagent, here
18:06:47 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T18-06-47
18:06:49 <TabAtkins__> heycam: We may want to consider building in some kind of functionality, though.
18:07:25 <TabAtkins__> heycam: I think that when people to textpath, they probably want glyphs to be stretched properly.  Currently it's just often ugly.
18:07:31 <pdengler> pdengler has joined #svg
18:07:56 <jenyu> jenyu has joined #svg
18:08:07 <TabAtkins__> vhardy_: In Tav's example, look at, frex, the "ribbon" example - it often looks better than the "snake" option.
18:08:51 <TabAtkins__> vhardy_: So these are some very simply things we could offer (that would be a bit heavy-handed to force authors to do themselves in script) that would make it prettier, without going all-out.
18:10:34 <TabAtkins__> tbah: Note that, in the example, each top option is transforming the points directly, while the lower option splits each path segment into thirds before transforming the points.
18:11:18 <TabAtkins__> heycam: The "snake" option is only transitioning the controlpoints, right?
18:11:21 <TabAtkins__> tbah: Yes.
18:11:58 <TabAtkins__> heycam: I'm not sure what we want to get out of this discussion today.
18:12:15 <vhardy_> Converting Bezier curves to NURBS: http://www.mactech.com/articles/develop/issue_25/schneider.html
18:12:21 <TabAtkins__> heycam: it seems that people are in agreement that we want to expose the glyph shapes to script, so people can at least do arbitrary warpning in script.
18:12:42 <TabAtkins__> heycam: I have the feeling that I'd like us to do nicer text on a path than at the moment, but I'm not sure what option we'd choose for that.
18:13:00 <TabAtkins__> tbah: For now, I suggest that horizontal lines be warped to match the shape of the path, specified in the current spec.
18:14:06 <TabAtkins__> TabAtkins__: Current impls do "stretch" by transforming the glyph bounding box into a quad and doing a simple perspective transform, which is pretty ugly.
18:15:04 <TabAtkins__> tbah: Israel's suggestion means that horizontal lines are transformed such that their tangent is always parallel to the path.
18:15:30 <TabAtkins__> tbah: Vertical positions would be the same distance from the path as they are the baseline.
18:16:01 <TabAtkins__> heycam: Would that involve subdividing path segments?
18:16:13 <TabAtkins__> TabAtkins__: Yes, it would imply that horizontal lines become curved lines.
18:16:48 <TabAtkins__> vhardy_: [shows an example of how a perpendicular grid would be transformed, using those principles]
18:17:33 <TabAtkins__> heycam: Is that the same as the "office text"-in-a-circle example?
18:17:35 <TabAtkins__> vhardy_: Yes.
18:17:40 <TabAtkins__> heycam: Ok, that's the result that I'd like.
18:18:25 <TabAtkins__> heycam: I'm slightly reluctant to put in spec requirements for things beyond basic graphics algorithms without saying how to do it.
18:18:39 <TabAtkins__> vhardy_: Is Bob Hopegood still an IE in the group?
18:18:48 <TabAtkins__> ChrisL: No, but we could ask him to rejoin.
18:19:05 <TabAtkins__> ChrisL: Cam, why are you reluctant?
18:19:20 <TabAtkins__> heycam: Just reluctant to do so without explaining how to do it, so it's defined in the spec.
18:19:42 <ChrisL> I missed the "without saying how" part on the phone, hence my question
18:19:44 <TabAtkins__> vhardy_: I'd like either Israel, if he's up to it, or Bob, if he's interested in rejoining, to help draft this stuff.
18:20:06 <heycam> ChrisL, no problem
18:20:06 <TabAtkins__> shepazu: They don't even need to join, if they just help explain it.
18:20:23 <TabAtkins__> shepazu: We all agree thought that step 1 is exposing the path data via some API.
18:20:29 <TabAtkins__> heycam: I think that's reasonable to resolve on.
18:20:35 <TabAtkins__> s/thought/though/
18:21:59 <TabAtkins__> RESOLVED: We will provide a way to get glyph path data via some API.
18:22:20 <TabAtkins__> [some discussion about where this would live]
18:22:37 <TabAtkins__> heycam: We can decide whether this would apply to single glyphs, or if you get the total path from a run of text, or what.
18:23:36 <TabAtkins__> heycam: So I think there are a few different ways we could expose this information.
18:23:54 <TabAtkins__> heycam: Like something that just takes a font name and a character, or whatnot.
18:24:37 <TabAtkins__> ed: There may be different ways of rendering, so you'd want it on the element.  Frex, for simple text we may just hand the text over to the platform API, which may end up with a different shape.
18:24:55 <TabAtkins__> vhardy_: In Java, if you ask for the glyph outline you get the non-hinted outline.
18:25:03 <patd_> patd_ has joined #svg
18:25:11 <TabAtkins__> heycam: I'm happy to write a proposal for something simple.
18:25:51 <TabAtkins__> cabanier: In some fonts you're not allowed to get the outlines.
18:27:41 <TabAtkins__> heycam: I don't see any difference between exposing the bytes of the font and exposing the path.
18:30:29 <TabAtkins__> [unminuted discussion about legal issues]
18:31:16 <TabAtkins__> shepazu: Summary is, we shouldn't talk about legal issues in the spec.  We should expose some way of determining that a glyph is available or not (useful generally).  Implementations might choose to claim that glyphs aren't available for whatever reason.
18:31:53 <TabAtkins__> ACTION: heycam to come up with API proposal for exposing glyph path data.
18:31:53 <trackbot> Created ACTION-3076 - Come up with API proposal for exposing glyph path data. [on Cameron McCormack - due 2011-08-03].
18:32:23 <TabAtkins__> heycam: It sounds like we also want some options to talk to people who know something about path warping algorithms.
18:32:37 <shepazu> shepazu has joined #svg
18:32:40 <TabAtkins__> heycam: Like Bob or Israel, so they can help inform us as to whether we add that into the spec.
18:32:43 <patd_> patd_ has joined #svg
18:33:18 <TabAtkins__> ACTION: vhardy to reach out to Bob Hopgood for information about path warping for text.
18:33:19 <trackbot> Created ACTION-3077 - Reach out to Bob Hopgood for information about path warping for text. [on Vincent Hardy - due 2011-08-03].
18:33:34 <pdengler> pdengler has joined #svg
18:33:40 <TabAtkins__> heycam: For Israel, I got the impression that Israel doesn't particularly want to give away what he's doing, but it would be nice to ask anyway.
18:34:07 <TabAtkins__> vhardy_: We can ask - I think he has paths and does animation, but in these examples it's exported pre-computed.
18:34:36 <TabAtkins__> ACTION: heycam to contact Israel about path warping information.
18:34:36 <trackbot> Created ACTION-3078 - Contact Israel about path warping information. [on Cameron McCormack - due 2011-08-03].
18:34:43 <anne> anne has joined #svg
18:35:02 <TabAtkins__> ChrisL: What about the guy who does web2geom?
18:35:17 <TabAtkins__> heycam: Nathan Hurst
18:35:19 <heycam> s/web/lib/
18:35:37 <TabAtkins__> heycam: I can contact him to ask him... something...
18:35:54 <TabAtkins__> shepazu: Something important.
18:36:08 <TabAtkins__> heycam: Perhaps he can explain what he does in a more explainable matter.
18:36:12 <TabAtkins__> s/matter/manner/
18:36:37 <TabAtkins__> ACTION: heycan to contact Nathan Hurst about lib2geom for information about path warping.
18:36:37 <trackbot> Sorry, couldn't find user - heycan
18:36:44 <TabAtkins__> ACTION: heycam to contact Nathan Hurst about lib2geom for information about path warping.
18:36:44 <trackbot> Created ACTION-3079 - Contact Nathan Hurst about lib2geom for information about path warping. [on Cameron McCormack - due 2011-08-03].
18:37:23 <TabAtkins__> heycam: Tav, anything else?
18:37:26 <TabAtkins__> tbah: No, that's it.
18:37:34 <TabAtkins__> Topic: Event attributes in SVG2
18:37:47 <TabAtkins__> ed: I think SVG2 should align with what HTML5 does wrt event attributes.
18:38:01 <TabAtkins__> ed: Basically that would add all of the on* attributes to the svg attributes.
18:38:26 <TabAtkins__> ed: And for any new events, they'd automatically get an on[event-name] attribute added to all relevant elements.
18:38:49 <TabAtkins__> anne: The way HTML does it is that, for each element that's dispatched, there's a corresponding on* attribute.
18:38:56 <Zakim> -tbah
18:39:09 <TabAtkins__> anne: Currently they're exposed on window, document, and HTMLElement. Plus a few that are only exposed on specific objects, like XHR or WebSocket.
18:39:31 <TabAtkins__> anne: But, frex, things that are dispatched on <video> can be caught higher by using the on* attribute.
18:39:50 <TabAtkins__> anne: So I think SVG should follow the same path. Any attributes that are dispatched should be added to SVGElement.
18:40:01 <ChrisL> yes it would be better to pu them on Element and have HTMLElement SVGElement inherit
18:40:44 <TabAtkins__> heycam: SVG doesn't have many novel events that aren't already exposed generally.
18:40:59 <TabAtkins__> birtles: The SMIL events.
18:41:09 <TabAtkins__> ed: SVG has a 'rotate' event, too.
18:41:38 <TabAtkins__> [vhardy reviews the list of SVG events]
18:42:05 <ChrisL> on[a-zA-Z-]*
18:42:06 <ed> s/'rotate'/'SVGRotate'/
18:43:37 <TabAtkins__> heycam: Are there examples in HTML of element-based events being scoped?
18:43:54 <TabAtkins__> anne: No, anything that dispatches on elements are available on HTMLElement, document, and window.
18:44:28 <TabAtkins__> heycam: Maybe HTML could define a hook so that we can put these things on window, or we can just do it ourselves.
18:44:36 <TabAtkins__> anne: You can use the new "partial" thing in WebIDL.
18:45:05 <TabAtkins__> anne: There's some thought to define the hooks in DOMCore.
18:47:12 <TabAtkins__> <br type=lunch-prep duration=5min>
18:52:10 <TabAtkins__> heycam: We haven't moved to the on* being on Element yet; right now it's on HTMLElement.
18:52:20 <TabAtkins__> heycam: Should we wait for DOMCore to define them on Element, or put them on SVGElement.
18:52:43 <TabAtkins__> anne: I think Moz already puts them on Element, and they said that the HTML events should move to match them.
18:53:18 <TabAtkins__> anne: So I think if we move those we should move SVG events as well.
18:53:22 <TabAtkins__> vhardy_: What's the status of that move?
18:53:49 <TabAtkins__> anne: Nothing is moved so far, and I'm not sure DOMCore should define it; it would need to contain a long magic list of attributes that would be continually updated.
18:54:12 <TabAtkins__> anne: But I think DOMCore could define some hooks that make it easy for other specs to define their events on Element.
18:54:35 <TabAtkins__> vhardy_: What about the SVG-specific events?  Should we ask the HTMLWG to add them?
18:55:49 <TabAtkins__> anne: Sounds like a good idea.
18:56:08 <TabAtkins__> heycam: Are there event listener attributes defined in HTML that aren't HTML-specific?
18:56:43 <TabAtkins__> anne: Well, something like onscroll
18:56:53 <TabAtkins__> anne: They could fire in a document with no HTML elements in them.
18:57:12 <TabAtkins__> heycam: Okay, so sounds like everyone thinks this is a good idea (to have the events on Element).
18:57:17 <TabAtkins__> heycam: anne, any timescale?
18:57:23 <TabAtkins__> anne: Haven't looked into it yet.
18:57:40 <TabAtkins__> heycam: It's not an immediate concern, but.
18:57:46 <TabAtkins__> anne: Probably in the next six months or so.
18:58:09 <TabAtkins__> RESOLVED: SVG2 will move all events to Element, in accordance with the similar move in HTML.
18:58:34 <TabAtkins__> anne: If you could file a bug it would be easier to follow up on.
18:58:47 <TabAtkins__> ACTION: heycam to file a bug on DOMCore to remind Anne about the event move.
18:58:56 <trackbot> Created ACTION-3080 - File a bug on DOMCore to remind Anne about the event move. [on Cameron McCormack - due 2011-08-03].
18:59:11 <Zakim> -ChrisL
19:02:00 <pdengler> pdengler has joined #svg
19:04:12 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)17:18Z
19:04:15 <Zakim> Team_(svg)17:18Z has ended
19:04:17 <Zakim> Attendees were +1.206.675.aaaa, tbah, ChrisL
19:05:13 <pdengler> pdengler has joined #svg
19:05:45 <heycam> Topic: image-rendering property and why Tab is redefining it
19:05:56 <heycam> Scribe: Cameron
19:05:56 <TabAtkins__> http://dev.w3.org/csswg/css3-images/#image-rendering
19:05:58 <heycam> ScribeNick: heycam
19:06:12 <heycam> TA: the pixelate value was added a week ago
19:06:23 <heycam> ... I've specifically defined optimizeSpeed and optimizeQuality as simply being equivalent to auto
19:06:42 <heycam> ... if your specific goal is high quality grphics, you do need the ability to control speed & quality
19:06:51 <heycam> ... in general in CSS, you specificalyl don't want to give authors control of this
19:06:58 <heycam> ... you want the browser to do the best it can
19:07:10 <heycam> ... if you let them make the choice, they will base their decision on their own machine
19:07:27 <heycam> ... whenever we offer features that let you make a performance sensitive choice, they do it based on their computer
19:07:36 <heycam> ... so the new values I've added to image-rendering are specifically intent based
19:07:44 <heycam> ... "this image should preserve certain features when resized/scaled"
19:07:56 <heycam> ... browsers are then free to use whatever algorithm they want to match the intent
19:08:02 <heycam> ... auto can drop down to nearest neighbour
19:08:10 <heycam> ... but when you have the resources, use bicubic
19:08:40 <heycam> ... chrome resizes in bilinear, then after a timer if no further resizes are done, redoes it with lancosz
19:08:55 <heycam> ... the other two svg defined values just map to auto
19:09:22 <heycam> ... crispEdges would be used for pixel art or diagram with straight edges, something that would look bad if the edges were blurred
19:09:42 <heycam> ... in the simple case, you can use nearest neighbour, but alternatives could be used
19:09:54 <heycam> ... pixellate I added, which means just embiggen the pixels 
19:10:53 <heycam> CM: what's the difference?
19:11:10 <heycam> TA: pixellate would just do pixel scaling, crispEdges could use a different algorithm for pixel art scaling for example
19:11:29 <heycam> DS: you might have an image editing program where you want to see big square pixels
19:12:52 <heycam> CM: would we want to do something similar with the other properties, text-rendering etc.?
19:13:11 <heycam> VH: should we add values to image-rendering rather than replace them?
19:13:32 <heycam> TA: what intent is good to have for vector images?
19:13:42 <heycam> ... crispEdges and pixellate would be more useful for rasters
19:14:01 <heycam> ... if there are specific types of intents that we want for vector values, we could use those
19:14:13 <heycam> VH: I think that's a good point, but it's a separate problem
19:14:21 <heycam> ... you're talking abotu a case when referenceing a vector image
19:14:25 <heycam> ... image-rendering is already used in SVG
19:14:30 <heycam> TA: the way I'm using image-rendering is only for raster images
19:14:37 <heycam> ED: that's how it's defined in SVG too
19:15:08 <heycam> TA: in that case, if we can tell what the current of optimizeSpeed and optimizeQuality are intending, we could define them instead of mapping to auto, or mapping them to an existing intent based keyword
19:15:19 <heycam> VH: I can see your point of view, but I would also like the original definition of image-rendering
19:15:25 <heycam> ... as an author I would like to have the four sets of values
19:15:45 <heycam> ... somethings you would like this to be fast, so if you're on a faster computer, that's fine use a high quality algorithm
19:15:54 <heycam> ... I'm more focused on the user experience than visual quality
19:16:20 <heycam> PD: we came to the same conclusion about not supporting image-rendering
19:16:30 <heycam> ... you couldn't as an author determine what the end user's desire was
19:16:45 <heycam> ... at the same time I don't understand your two recommendations
19:16:52 <heycam> TA: the various pixel scaling algorithms are used by emulators
19:17:01 <heycam> JY: what would the test for that look like?
19:17:06 <heycam> TA: I'm not sure this property is testable
19:17:39 <heycam> ... the only MUST in there is for upscaling with pixellate
19:17:43 <heycam> ... the rest are SHOULDs
19:18:56 <heycam> VH: if I'm an author and I want an image that may want to be scaled, or printed for example
19:19:09 <heycam> ... for printing I'd probably want optimizeQuality, it may take time, but I'd want it to be printed high quality
19:19:55 <heycam> TA: currently, the only time browsers use low quality algorithms is if there really is not enough time for the HQ algorithms
19:20:02 <heycam> ... otherwise, it assumes as high quality as it can provide
19:20:20 <heycam> ... the rendering intent you want doesn't seem to be useful
19:20:41 <heycam> ... I think the browser will do the highest quality in the time it can
19:20:52 <heycam> VH: java2d lets you select particular algorihtms
19:21:10 <heycam> TA: webgl exposes some levels of performance information, so you can decide things yourself
19:21:26 <heycam> ... with webgl you really need the game to decide to scale back its work
19:21:32 <heycam> ... with images, in practice, I don't think there's a problem
19:21:51 <heycam> ... with one of the IE demos there were lots of scaled logos moving around, using bilinear was still too slow
19:22:00 <heycam> ... but we could choose to use nearest neighbour to make it fast enough
19:22:13 <heycam> ... so what we do now, fast when it can be, I think is what you always want
19:22:40 <heycam> ... if you have use cases where you really need it to be this way, browsers would make the wrong decision, I would like to see them
19:23:00 <heycam> VH: the one were you said it was too slow because it chose bilinear
19:23:05 <heycam> CM: I would say that's just a bug
19:23:12 <heycam> VH: I think we're making a choice of speed vs visual quality
19:23:29 <heycam> ... and you're saying we will degrade quality to increase speed
19:23:41 <heycam> ... they may prefer to have a slower animation
19:23:55 <heycam> TA: so it's deciding between animation jank and quality
19:24:06 <heycam> VH: what nags me a bit is saying we can decide what's best for the author
19:24:15 <heycam> TA: I think in the vast majority of cases we can and do make that decision correctly
19:24:26 <heycam> ... and I'm not sure the remaining cases are important enough that we need to give that sort of control to the author
19:24:41 <heycam> ... for example in the really high load flying images constant resizing, I think it's pretty clear you don't want janky animations
19:24:46 <heycam> ... they always look bad
19:25:01 <heycam> ... so I think the browser can make that decision and it will be right in the vast majority of cases
19:25:14 <heycam> ... in those tiny minority of cases where it really matters, it will much more often be misused
19:25:32 <heycam> ... and you would end up requiring an uglier experience
19:25:46 <heycam> VH: with optimizeSpeed, if you had the bandwidth you could use the higher quality
19:25:54 <heycam> ... it doesn't mean use the fast path all the time
19:25:57 <heycam> ... it's a tradeoff
19:26:17 <heycam> ... I think there's a tradeoff between visual quality and speed/performance, and that the current settings allow you to say where you stand on that balance
19:26:35 <heycam> ... if you run and find out that the most expensive interpolation method you still have a nice frame rate, even with optimizeSpeed you would keep that algorithm
19:26:40 <heycam> ED: the spec already says something like that
19:26:51 <heycam> ... if you can achieve the performance with HQ algorithms, just use that
19:27:03 <heycam> BB: you also want particular algorithms sometimes
19:27:13 <ed> s/the spec/the SVG spec/
19:27:13 <heycam> VH: so I like the additional settings, I'm not opposed to that
19:27:21 <heycam> ... this is just about the existing settings
19:27:45 <heycam> TA: optimizeSpeed seems to be in really emergency situations, when you have to make a choice between unarguably ugly with image rendering, or janky with animations, you have to decide
19:27:51 <heycam> ... in that case, I could see optimizeSpeed having some value
19:28:01 <heycam> ... in all other cases it would be equivalent to auto
19:28:23 <ed> http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
19:28:25 <heycam> CM: I think that's what the existing definitions say
19:28:45 <heycam> ... that's not to say that's how they're implemented, but that's the intention of the spec
19:29:00 <heycam> TA: ok, so I can take optimizeSpeed and reword it to make sure it's clear it means use nearest neighbour all the time, e.g.
19:29:12 <heycam> ... it means use the best you can, and if you can't get the best speed, use lower quality
19:29:22 <heycam> VH: what about optimizeQuality?
19:29:25 <heycam> TA: that's the same as auto
19:29:35 <heycam> VH: don't think so, currently it says "at least as good as bilinear"
19:29:56 <heycam> TA: I think that's a bad thing. animation jank is nearly always worse than lower quality.
19:31:44 <heycam> ... optimizeQuality preventing you from going below bilinear is a bug
19:31:55 <heycam> ... since framerate is a larger problem
19:32:18 <heycam> VH: I think there are cases, not in the context of animation, print would be one, and as an implementor you need to decide what alogirhmt you're going to use
19:32:40 <heycam> ... so you might want to use nearest neighbour for the sake of time, but the author may want a better quality
19:32:58 <heycam> TA: the way hardware is these days, you could use lancosz for printing without a time problem
19:33:29 <heycam> ... back in the day, sure, since that might take 2 seconds to scale the image. now it's 10ms or whatever, slow enough that animation suffers, but fast enough that you won't notice print stuff
19:33:53 <heycam> ... like patrick was saying, some of these seem like they were more useful several years ago, and now we have enough performance not to trade off as much
19:34:12 <heycam> ... in the future, we won't need to worry about optimizeSpeed either, because we will always be able to do HQ in time
19:36:12 <heycam> DJ: I tend to agree with Tab
19:36:28 <heycam> ... I think the new keywords are the more improtant ones, the ones that guarantee "worse looking" images
19:36:40 <heycam> VH: I'm ok with what you said, if you add optimizeSpeed
19:36:45 <heycam> ... I think it's easier to add values
19:36:50 <heycam> TA: the old ones would just be aliased to auto
19:37:00 <heycam> VH: oh, so alias optimizeQuality to auto
19:37:36 <heycam> ... and keep optimizeSpeed?
19:47:50 <Zakim> Zakim has left #svg
20:02:22 <plinss_> plinss_ has joined #svg
20:23:30 <thorton> thorton has joined #svg
20:26:53 <thorton> thorton has joined #svg
20:31:54 <thorton> thorton has joined #svg
20:33:06 <thorton> thorton has joined #svg
20:33:51 <thorton> thorton has joined #svg
20:36:14 <Zakim> Zakim has joined #svg
20:36:56 <birtles> birtles has joined #svg
20:41:28 <thorton> thorton has joined #svg
20:41:33 <thorton> thorton has joined #svg
20:42:05 <ed> scribeNick: ed
20:42:38 <jenyu> jenyu has joined #svg
20:42:59 <ed> Topic: SVG in Canvas
20:43:14 <ed> DS: currenlty you can use canvas in html, with the canvas element
20:43:43 <ed> ... there's a set of things for which canvas is better than svg, and vice versa
20:44:02 <ed> ... getPixelAtPoint
20:44:24 <ed> DJ: you have to getImageData and pull out pixels
20:45:15 <ed> TabAtkins__: in canvas you can get a pixel value, which isn't possible in svg
20:45:38 <ed> ... [highlevel description of what canvas is]
20:46:19 <ed> ... you can e.g do blur by manipulating pixels in the imagedata
20:46:35 <ed> ... you can draw video to it, and you can pull binary blobs from it
20:46:58 <ed> CM: that's like the toDataURI but without the uri, right?
20:47:05 <ed> TabAtkins__: yes
20:47:42 <ed> ... the WebGL context can do more things, like use shaders and so on
20:48:47 <ed> CP: hlsl could be abstracted out, canvas acts as a middle for svg, for html
20:49:20 <ed> vhardy_: you can draw svg to canvas, right?
20:49:32 <ed> TabAtkins__: yes, via image
20:49:45 <ed> ... drawImage and pass in an svg
20:50:05 <ed> anne: passing in an svg element is not in the spec
20:50:18 <ed> ... opera supports that
20:50:25 <ed> DS: that should be in the spec
20:50:44 <ed> CP: it works already via image element, which is specced
20:53:36 <ed> [a round of introduction, group welcomes Charles Pritchard to the session]
20:53:50 <ed> DS: i would like to use canvas in svg
20:54:08 <ed> ... to e.g expose the canvas via the svg:image element
20:54:28 <ed> DJ: wouldn't it be better to have a canvas element in svg instead?
20:54:36 <ed> ... you're duplicating an API
20:54:48 <ed> ... it's the canvas context thatäs the verbose api
20:55:05 <ed> ... you expose the getContext method on the image element, but that's a bit weird because you draw to it
20:55:24 <ed> ... if you use the exact same element and API then that makes it easier
20:55:45 <ed> anne: presumably the html group could have done the same, but didn't
20:55:56 <ed> CP: there's also the getCSSCanvas
20:56:05 <ed> ... works together with css
20:56:21 <ed> ... only one set of width and height ...
20:56:50 <ed> ... allows you to get scalable results
20:56:58 <ed> ... it's manual with canvas
20:57:08 <ed> ... but with getCSScanvascontext
20:57:13 <ed> ... it's slightly different
20:57:17 <ed> ... it's more managed
20:57:43 <ed> ... in webkit you can buffer the drawing commands and replay them later
20:57:55 <ed> ... you can use a set of bitmaps to get more scalable
20:58:08 <ed> ... they're not managing multiple bitmaps
20:58:13 <ed> ...works with css backgrounds
20:58:28 <ed> CM: not that familiar with the getCSSContext
20:58:46 <ed> TabAtkins__: mozilla can use moz-element to render any element into a background
20:59:06 <ed> ... webkit has something that allows you to pull out a canvas context from a background
20:59:20 <ed> DJ: getCSSContext was a hack we wish we didn't put in
20:59:36 <ed> ... we want to move to element()
21:00:09 <ed> DS: svg doesn't have backgrounds
21:00:15 <ed> TabAtkins__: svg has fills
21:00:20 <ed> DS: but it's not the same
21:00:30 <ed> ... the svg root could have a background
21:00:45 <ed> vhardy_: svg tiny does have viewport-fill
21:00:59 <ed> DS: maybe we could allow backgrounds in svg
21:01:10 <ed> ... and allow getting a canvas from the background
21:02:06 <ed> TabAtkins__: both produce the image as imagevalues, and you can fill something with a canvas
21:02:40 <ed> CM: so rect filled with some canvas content
21:02:54 <ed> vhardy_: for the paintservers?
21:03:13 <ed> TabAtkins__: via the element() syntax you could point to something like that
21:03:37 <ed> <circle fill="element(mycanvas)"/>
21:03:45 <ed> <canvas id="mycanvas">
21:04:29 <ed> vhardy_: how does this all work?
21:04:45 <ed> ... so not the getCSSContext, but the element() syntax
21:04:50 <ed> TabAtkins__: right
21:05:07 <ed> ... can refer to things outside of the document
21:05:13 <ed> vhardy_: by id?
21:05:18 <ed> TabAtkins__: yes
21:05:45 <ed> CP: is it the case now that you can use getCSSContext?
21:05:53 <ed> TabAtkins__: yes, but we want to move away from that
21:06:17 <ed> DS: so we could use a canvas to fill any shape in svg
21:06:38 <ed> vhardy_: the element syntax is implemented in firefox?
21:06:58 <ed> TabAtkins__: yes
21:07:37 <ed> ... not all parts we discussed here
21:07:53 <ed> ... need to add the syntax for the paintservers
21:08:09 <ed> DS: that's the kind of integration i'd like to see in svg
21:08:19 <ed> vhardy_: the other part is the canvas element in svg
21:08:34 <ed> ... width and height are different in svg than in html
21:08:47 <ed> DS: they perhaps need to be resolved to pixels differently
21:09:25 <ed> TabAtkins__: you need the width and height to be the pixel dimensions
21:09:43 <ed> CM: you could rescale if the zoomfactor changes
21:09:59 <ed> vhardy_: what do you do if you zoom an html page with canvas?
21:10:17 <ed> CP: you listen for the resize event and redraw the canvas
21:10:41 <ed> DS: in svg you could just use currentScale
21:11:01 <ed> vhardy_: you have to detect that the canvas size changes, and set it
21:11:17 <ed> CP: yeah, just do that and set a scale transform
21:11:55 <ed> DJ: you may have to look at device pixel ratio
21:12:18 <ed> CP: yes, for devices, but on desktop it usualyl doesn't cahnge
21:12:51 <ed> CM: what happens when the svg transforms scale something that has a canvas element below?
21:13:11 <ed> DJ: the coordinate system in svg is independent
21:13:33 <ed> ... you have to say how many pixels you want
21:13:58 <ed> CM: so the smallest size that looks nice at the transformed size
21:14:13 <ed> DJ: typically ppl means css pixels
21:14:24 <ed> CM: so authors should be in control?
21:14:42 <ed> DJ: well, you specifgy in user untis the size of the canvas element for layout in the svg
21:14:56 <ed> ... but you delay creating the backing bitmap 
21:15:46 <ed> CP: but what if several places uses the same canvas element, but with different scales?
21:16:07 <ed> ... do you have to use separate canvas elements to get it without pixelizing the result?
21:16:46 <ed> CM: if you were animating a transform of a <g> containing a <canvas>, would you have to recreate the bitmap?
21:16:58 <ed> TabAtkins__: or you have to start out big so that it's scaled ok
21:17:17 <ed> CM: you keep the bitmap buffer around
21:17:31 <ed> vhardy_: right, but you might want to repaint if the size changes
21:17:53 <ed> CM: so you only want to know if the transform changes
21:18:10 <ed> vhardy_: canvas should be a same as anything else you draw
21:18:13 <ChrisL> ChrisL has joined #svg
21:18:21 <ed> ... so rasterize so that it looks ok
21:18:29 <ChrisL> rrsagent, here
21:18:29 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T21-18-29
21:18:39 <ed> CM: you still need to redraw the canvas manually
21:19:37 <ed> DJ: if you pinchtozoom would you expect to recreate the canvas for each step?
21:19:52 <ed> vhardy_: just asking for a way to get notified when the scale changes
21:20:12 <ed> CP: css transitions has transitionend/start
21:20:29 <ed> DJ: by default when you draw something in svg you get optimal rendering
21:20:36 <ed> ... except for a raster image, which has to be scaled
21:20:48 <ed> ... wiuth canvas you can improve the visual output depending on scale
21:21:14 <ed> vhardy_: if you listen for zoom and resize events you could solve some of these things, similar to how it's done in html today
21:21:45 <ed> CP: requestAnimationFrame gives a hook where you can attach some handling
21:22:10 <ed> vhardy_: you could do that outside the repaint loop
21:22:31 <ed> ... i think i can withdraw my proposal, maybe we have enough with the zoom and resize events
21:23:17 <vhardy_> ed: I am interested in having Canvas in SVG.
21:23:47 <ed> DS: interesting to drill down into detail, but i'm just looking at gaging the interest in having the functionality
21:24:14 <ChrisL> I'm in favour of havinga  cavas element available in svg
21:24:28 <ChrisL> ... but have no special input beyond that
21:24:55 <ed> DJ: typically people don't run javascript int he middle of painting
21:25:12 <ed> ... it's the using of javascript that updates the rendering
21:26:12 <ed> ... bigger concern is if you have a loop of canvas in html drawing something svg with canvas (circular loop)
21:26:27 <ed> CP: that's just going to give a static bitmap
21:26:46 <ed> CC: what about export of svg rendered to the canvas?
21:27:09 <ed> TabAtkins__: most of the canvas drawing commands maps to svg
21:27:25 <ed> ... but when you're manipulating pixels directly then it's not really possible
21:27:37 <heycam> Present+ Charles Pritchard
21:27:45 <ed> vhardy_: can you hook up a new context to the canvas element?
21:28:30 <ed> DS: there's been lots of experimenting with wrapping canvas and svg
21:29:17 <ed> ... given a raster you can't go back to vectors
21:29:27 <ed> CP: recording commands is possible, but it's overhead
21:29:36 <ed> ... but you're going to want a dom tree anyway
21:30:11 <ed> ... svg is great for interop, and we use it for a few things
21:30:12 <shepazu> http://schepers.cc/w3c/svg/api/cog.svg
21:30:21 <ed> ... but you want something with great svg import/export
21:30:29 <ed> ... not script hacks
21:30:55 <ed> DS: svg's dom api sucks
21:31:05 <TabAtkins__> https://wiki.mozilla.org/SVG:Language:Regrets
21:31:52 <jwatt> hey, that's my secret page
21:32:16 <TabAtkins__> NOT SO SECRET ANYMORE
21:32:28 <jwatt> apparently
21:32:45 <dino> wow. I have many more regrets about SVG than jwatt.
21:32:56 <dino> i would not know where to start :)
21:33:24 <jwatt> there's only so many I had time to write down
21:33:29 <jwatt> :)
21:33:58 <TabAtkins__> https://docs.google.com/a/google.com/document/edit?id=1WYzbMkC_Q1pi6HyMNu4p6XevqXtGEHvmRjEZZemR6r8&hl=en&pli=1#
21:34:03 <ed> DS: one of the reasons ppl like to use canvas is because they want to make a cirlce or path, more intuitive than setting attributes, creating elements
21:34:27 <ed> CP: js libraries do provide you with that
21:35:07 <ed> vhardy_: you need svg and canvas for different use-cases
21:35:18 <ed> ... trying to merge the two is a good thing though
21:35:28 <ed> TabAtkins__: the svg dom is clumsy to work with
21:35:38 <ed> DS: and less intuitive than the canvas API
21:36:49 <ed> CM: right, so using DOM core methods that's too much work
21:36:58 <ed> CP: i like innerHTML
21:37:15 <ed> DS: there are script libs that allow you to do some things easier
21:37:59 <ed> ... but having a shared language for creating the shapes and so on is good
21:38:35 <ed> CM: you want to be able to use currentFill=blah, and fillRect and so on and that it generates svg
21:38:56 <ed> vhardy_: but it can be hard to make that preserve structure
21:39:30 <ed> DS: we need to look at both, but unify gradients
21:40:00 <ed> vhardy_: there were some proposals for svg2 dom
21:40:13 <ed> ... like inline json for example
21:40:24 <TabAtkins__> TabAtkins__: Some examples from a doc (unfortunately private) for a better drawing API for SVG:
21:40:27 <TabAtkins__> var font = root.font(”DroidSans”, [”DroidSans.ttf”, “DroidSans.swf”],
21:40:28 <TabAtkins__>                      {fontWeight: ‘bold’, fontStyle: ‘normal’});
21:40:28 <TabAtkins__> root.linearGradient(”myGradient”, “-blue-green”);
21:40:28 <TabAtkins__> var group = root.group();
21:40:30 <TabAtkins__> var rect = group.rect(20, 20, 300, 300, {fill: “id(#myGradient)”});
21:40:32 <TabAtkins__> var text = group.text(30, 40, “Hello World!”, 
21:40:35 <TabAtkins__>                       {fontFamily: “DroidSans”});
21:40:37 <TabAtkins__> group.translate(-5, -5)
21:40:40 <TabAtkins__>      .scale(1.5, 1.5)
21:40:42 <TabAtkins__>      .animate({x: 200, opacity: 0.2}, 2000);
21:41:08 <ed> DS: don't want to remove the ability to get good structued svg files, with the new api
21:41:34 <ed> CP: you probably want to use svg, and use drawImage instead
21:42:00 <ed> CM: robert was in favor of doing something like that
21:42:17 <ed> ... there are some immiate mode apis that allow you to do groups
21:42:27 <ed> ... we could have that
21:42:39 <ed> vhardy_: as in the example shown above from tab
21:43:01 <ed> CP: inkml is the only format i've seen that has a streaming mode and an archived mode
21:43:13 <ed> ... you can flatten the strucutre
21:43:14 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
21:43:24 <ed> ... pdf has streaming capabilites
21:43:32 <ed> ... but improving the flexibility is good
21:43:49 <ed> ... we want to preserve the vectors
21:44:18 <ed> DS: dropped in link, different from tabs exmaple
21:44:27 <vhardy_> vhardy: talking about variations, I like things like:
21:44:44 <ed> CM: are there any plans of improving DOM core to make it easier to create elements and attributes
21:44:53 <vhardy_> var rect = group.append({tag: 'rect', x: 10, y: 20, fill: 'blue'});
21:45:11 <ed> anne: haven't heard any suggestions yet
21:45:40 <ed> CM: so ppl aren't complaining?
21:45:40 <ed> anne: not enough
21:45:44 <ed> ... only suggesting i've heard is like "new HTMLElement"
21:46:00 <wi> wi has joined #svg
21:46:01 <ed> ... not a lot of requests on the mailinglists
21:46:09 <wi> hola
21:46:15 <ed> ... there's innerHTML
21:46:31 <ed> CM: shouldn't we try to improve the base platform?
21:46:39 <wi> alguien desea platicar?
21:46:53 <ed> anne: does jquery have the sort of thing you're asking about?
21:46:55 <ed> CM: yes
21:47:28 <ed> anne: wondering about hte vconvinence methods they have
21:47:55 <ed> TabAtkins__: jquery just wraps up innerhtml
21:48:09 <ed> anne: that's being specified
21:48:37 <ed> vhardy_: the proposed syntax is json, i prefer that syntax over innerhtml
21:48:52 <ed> CM: like taking a bag of arguments
21:50:02 <vhardy_> Summary of issues for SVG and Canvas integration:
21:50:15 <vhardy_> 1. <canvas> in SVG
21:50:16 <ed> DS: todataURI in svg is somethign i want, and getimagedata
21:50:22 <vhardy_> 2. SVG in 2D context's drawImage
21:50:32 <vhardy_> 3. CSS image values as SVG paint servers
21:50:38 <vhardy_> 4. SVG export from Canvas
21:50:46 <vhardy_> 5. SVG export to Canvas
21:51:03 <ed> CM: so just a convience function, to avoid having to paint svg to canvas and pulling pixels/datauri out from that
21:51:34 <ed> CP: if canvas is a requirement of SVG2 then you can do many of these thigns
21:51:47 <ed> DS: would like to see canvas as a firstclass element in svg
21:52:04 <ed> brian: so foreignObject?
21:52:56 <ed> anne: you could replace that with onlu <html> sort of like <svg> works in html5
21:53:45 <ed> vhardy_: let's go through the list above
21:54:30 <ed> 6. toDataURL
21:54:36 <ed> 7. getImageData
21:55:02 <wi> wi has left #svg
21:55:21 <ed> CM: so first point?
21:55:34 <ed> vhardy_: we need to resolve the width/height issue
21:55:46 <ed> CM: just doing the same as <image> should work
21:56:07 <ed> brian: so why do we need this without the foreignObject?
21:58:29 <ed> ISSUE: <canvas> element in SVG
21:58:30 <trackbot> Created ISSUE-2417 - <canvas> element in SVG ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2417/edit .
21:58:56 <ed> CM: next one, SVG in 2d context's drawImage
21:59:16 <ed> vhardy_: anne, drawImage doesn't mandate support for svg?
21:59:29 <ed> anne: right
21:59:41 <ed> DS: just needs to be mentioned in the spec
22:00:03 <ed> anne: you can pass in video, canvas and image elements in drawImage
22:00:24 <ed> vhardy_: we should request to be able to render an svg elements
22:00:43 <ed> TabAtkins__: there are some security concerns, like foreignObject
22:01:10 <ed> CP: to be able to draw an svg path directly to a canvas would be nice
22:01:28 <ed> anne: there are many things that can be external in svg, and that can taint the canvas
22:01:45 <ed> DS: the svg integration spec is meant to cover some of that
22:02:25 <ed> TabAtkins__: we could probably find a good way to do this, by disabling some things
22:02:42 <ed> vhardy_: if you could paint an svgsvgelemnent to a canvas
22:04:18 <ed> vhardy_: you could create a datauri of the subtree and pass that via the drawImage call, so it's a workaround
22:04:33 <ed> ... as an image.src
22:05:35 <ed> CP: taking a snapshot of an animated svg and creating a raster
22:06:13 <ed> s/6. toDataURL/6. toDataURL and toBlob/
22:07:07 <ed> ISSUE: SVG in 2D context's drawImage
22:07:07 <trackbot> Created ISSUE-2418 - SVG in 2D context's drawImage ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2418/edit .
22:08:47 <ed> CM: so point 4
22:08:54 <ed> vhardy_: many libs allow this
22:09:04 <ed> ... you can ask for the svg output
22:09:13 <ed> TabAtkins__: so let jslibs handle this
22:11:03 <cyril> cyril has joined #svg
22:11:09 <ed> 8. new API to construct svg trees
22:13:38 <ed> CM: so point 5
22:13:56 <ed> ... SVG export to canvas
22:14:38 <ed> DS: this would tak e some arbitrary svg and spit out the corresponding canvas javascript  commands to do that
22:15:09 <ed> vhardy_: could be done in a library
22:15:49 <ed> CP: if svg paths was supported in canvas that would be nice, and it's about 80 lines of js code to be able to handle that atm
22:17:22 <ed> ACTION: Tab to work with charles pritchard to propose a canvas function that uses svg paths 
22:17:23 <trackbot> Created ACTION-3081 - Work with charles pritchard to propose a canvas function that uses svg paths  [on Tab Atkins Jr. - due 2011-08-03].
22:17:56 <ed> CM: point 6: toDataURL and toBlob 
22:18:11 <ed> ... not sure if it meant to generate a png
22:18:18 <ed> DS: yes, that's what I meant
22:18:35 <ed> DJ: toDataURL takes a param for what you want back
22:18:49 <ed> DS: the one i'm most interested in is the rasters
22:19:17 <ed> CM: would have the same security concerns as drawing svg to a canvas
22:20:13 <ed> DS: there are ways around that
22:20:38 <ed> CP: 6 and 7 have the same concerns
22:21:33 <ed> vhardy_: anne, would it make sense to add capabilty to canvas to draw a string?
22:21:50 <ed> anne: what do you mean with string?
22:21:55 <ed> vhardy_: a serialized document
22:22:16 <ed> TabAtkins__: you could use a crippled security context
22:22:16 <ed> ... like for img elements
22:22:26 <ed> anne: it seems better to pass the element
22:23:42 <ed> vhardy_: i have a snippet of svg i want to draw in canvas
22:23:53 <ed> ... don't want ot have to base64 encode it
22:24:15 <ed> anne: two separate things, you could use innerHTML
22:24:35 <ed> ... vincent said it was not related to tainting?
22:25:02 <ed> CM: the only reaosn why your'e serailing is to be able t get it into the canvas
22:25:17 <ed> anne: if it's a separate file you could aslo use an iframe
22:28:06 <ed> CM: so have someone investigate how to get toDatauRL and pixels back
22:28:13 <ed> ... and the security concerns
22:29:04 <ed> anne: so for foreignObject that would taint the svg
22:31:00 <ed> ISSUE: Investigate how to get pixel data out of svg subtrees securely
22:31:00 <trackbot> Created ISSUE-2419 - Investigate how to get pixel data out of svg subtrees securely ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2419/edit .
22:31:19 <ed> ACTION: heycam to investigate ISSUE-2419
22:31:20 <trackbot> Created ACTION-3082 - Investigate ISSUE-2419 [on Cameron McCormack - due 2011-08-03].
22:32:48 <ed> CM: 8. New API to construct svg trees
22:34:32 <ed> CP: would be nice to have ArrayBuffer in svg and canvas API's, very efficient for gpus
22:34:53 <ed> ...avoids string serialinzg data
22:35:02 <ed> ... necessary for drawing fast
22:36:23 <ed> ACTION: doug to propose a new API for constructing svg trees
22:36:23 <trackbot> Created ACTION-3083 - Propose a new API for constructing svg trees [on Doug Schepers - due 2011-08-03].
22:36:43 <ed> --- 15 minute break
22:37:56 <anne> anne has joined #svg
22:39:54 <ChrisL> ChrisL has joined #svg
22:47:08 <ChrisL> rrsagent, here
22:47:08 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T22-47-08
22:49:50 <Zakim> Zakim has left #svg
22:53:29 <Zakim> Zakim has joined #svg
22:53:54 <ChrisL> zakim, remind me in 3 hours to go to sleep
22:53:54 <Zakim> ok, ChrisL
23:01:11 <anne> anne has joined #svg
23:08:52 <TabAtkins__> Topic: SVG Accessibility
23:08:59 <TabAtkins__> shepazu: Two aspects to this.
23:09:15 <TabAtkins__> shepazu: One, should we push for SVG being leverage for Canvas accessibility?
23:09:19 <vhardy> vhardy has joined #svg
23:09:23 <TabAtkins__> shepazu: Two, how can SVG be made more accessible?
23:09:31 <TabAtkins__> shepazu: I have a plan going forward for the latter.
23:10:13 <TabAtkins__> pritchard: In about 2009, people started asking for a11y in canvas.
23:10:31 <TabAtkins__> pritchard: In both SVG and Canvas, shapes are used; it's not text and a box model.
23:10:44 <TabAtkins__> pritchard: Richard Sch and I started looking into this.
23:11:01 <TabAtkins__> pritchard: I found several issues by trying to implement HTML forms in Canvas, and found many different things.
23:11:23 <TabAtkins__> pritchard: Then I started playing with shapes.  If I have a button shaped like a star, how can I tell the AT about that?
23:11:42 <TabAtkins__> pritchard: On the iphone, you can drag your finger around and it can find bounding boxes and read them to you.
23:11:50 <TabAtkins__> pritchard: But triangles? Not so much.
23:12:13 <TabAtkins__> pritchard: So with ARIA you can specify the "role" of something to an AT.
23:12:28 <TabAtkins__> pritchard: So, how does ARIA work with SVG and Canvas?
23:12:41 <TabAtkins__> pritchard: ARIA initially didn't take SVG into account.
23:12:52 <TabAtkins__> pritchard: Though they'll do more work with this in the future.
23:13:08 <TabAtkins__> pritchard: Canvas gets a lot of AT stuff for free with the hidden subtree; it can contain buttons, frex.
23:13:26 <TabAtkins__> pritchard: [explains the canvas subtree]
23:15:01 <TabAtkins__> pritchard: [explains the ability to draw focus rings based on whether a specified element in the subtree is focused]
23:15:35 <TabAtkins__> pritchard: So even if I'm drawing a custom focus ring, I need to tell the system where on my canvas is being focused (so the AT can help the user by zooming or highlighting or something there)
23:21:02 <TabAtkins__> pritchard: The best part about having focus here is that it's bound to an element, so you can some semantics out of that element.
23:21:27 <TabAtkins__> s/can/can get/
23:21:48 <TabAtkins__> shepazu: [draws a pie chart]
23:22:33 <TabAtkins__> s/pie chart/radial menu/
23:22:52 <TabAtkins__> shepazu: So in the canvas subtree it's just a list of links, which correspond to the regions in the radial menu of the Canvas.
23:23:42 <TabAtkins__> shepazu: So if you tab to the link, you'd either get the link's box or the entire canvas or something as the focused area, not the appropriate region of the menu.  That's what drawFocusRing is for here.
23:26:30 <TabAtkins__> heycam: In the pie chart it seems like each part is focusable, but if there's a <select> in the subtree, you're not really focusing the <option>s, but the <select> as a whole.
23:27:01 <TabAtkins__> pritchard: You can either link the focus-area to the appropriate <option>, or do something different like a list of links.
23:28:28 <TabAtkins__> pritchard: If you desire, though, you can take a list of links and use ARIA to mark it up as a select with options, semantically, and it's presented the same way to the AT.
23:29:12 <TabAtkins__> shepazu: While it hasn't been well-defined yet, it should also be possible to use ARIA with SVG well.  You could think of a lot of SVG as "really pretty divs".
23:30:53 <TabAtkins__> vhardy: Can you disable the UA's normal rendering here?
23:31:16 <TabAtkins__> TabAtkins__: You can pass a parameter to drawFocusRing to tell it not to visually do anything, so you can then just stroke the path afterwards.
23:32:19 <TabAtkins__> pritchard: [something about caret]
23:32:34 <TabAtkins__> [Doug is interested in exploring the idea of ARIA and carets]
23:32:55 <TabAtkins__> heycam: If you're doing a custom widget in windows, you can report the caret location, right?
23:33:03 <TabAtkins__> mattmay: Yes.
23:33:52 <TabAtkins__> heycam: So it seems like that's something you'd want to do with canvas as well, right?
23:34:24 <TabAtkins__> TabAtkins__: Text-editing has a ton more complexity than carets, so we generally just say you shouldn't do it yourself, and let <textarea> or @contenteditable handle it.
23:34:35 <TabAtkins__> pritchard: So we proposed setCaretPosition
23:34:52 <TabAtkins__> pritchard: And Ian suggested ScrollPathIntoView
23:35:41 <TabAtkins__> pritchard: The semantics are a little weird; you don't know that you're just emulating the functionality that moving the caret does natively (always keeping itself in view).
23:36:26 <TabAtkins__> shepazu: So, let's not drill down this far into Canvas a11y.
23:36:57 <TabAtkins__> pritchard: Another problem with canvas that SVG doesn't have is that, if you're searching through the DOM, you don't necessarily want to focus things.
23:37:38 <TabAtkins__> pritchard: So, for example, enumerating the selectable elements so you can move through them.  You need to know this *before* focusing them.
23:38:25 <TabAtkins__> pritchard: So this is where "why not just use SVG" really came in.  SVG gets this for free - you know the geometry of things before they're focused.
23:38:56 <TabAtkins__> pritchard: Canvas lacks the ability to talk about active regions ahead of time.
23:39:14 <TabAtkins__> pritchard: SVG has an opposite problem - it has a ton of paths, and we don't necessarily need all of them.
23:39:40 <TabAtkins__> heycam: Basically the set of things you want to report are the same as the set of focusable things?
23:39:43 <TabAtkins__> pritchard: Basically, yeah.
23:40:32 <TabAtkins__> shepazu: In Tiny 1.2 we introduced a @focusable attribute, which was meant to be for things like this.
23:42:19 <TabAtkins__> pritchard: [talk about using SVG and ARIA to create a checkbox and lable]
23:42:46 <TabAtkins__> mattmay: [talk about the difference between "virtual cursor" and "form" modes in ATs]
23:43:01 <TabAtkins__> ISSUE: Looks at @focusable in context of text and a11y
23:43:02 <trackbot> Created ISSUE-2420 - Looks at @focusable in context of text and a11y ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2420/edit .
23:44:00 <TabAtkins__> mattmay: You should be able to set @focusable on text elements, but most of the time users won't need to be reading that.
23:44:33 <TabAtkins__> heycam: The "virtual cursor" mode seems pretty valuable to work more on too.  In HTML you can just read through the DOM linearly, but in SVG you might want to read along the lines in a chart.
23:45:08 <TabAtkins__> pritchard: In ARIA you have aria-flow-to and aria-owns, which let you specify the AT tree different from the DOM tree.  aria-live lets you specify an area that is active and may change.
23:45:45 <TabAtkins__> pritchard: My main thing I found with SVG was that it's not quite as hierarchical as HTML.
23:45:56 <TabAtkins__> heycam: aria-flow-to sounds pretty interesting to use here too.
23:46:30 <TabAtkins__> mattmay: flow-to affects tab order, not reading order (order of the virtual cursor).
23:46:52 <TabAtkins__> shepazu: I think that peppering your doc with ARIA is a last resort, generally.  It's good when we need it, but better if we can make it work without it.
23:47:01 <TabAtkins__> shepazu: My "connectors" stuff was about that.
23:47:19 <TabAtkins__> pritchard: flow-to changes the reading order in some circumstances.
23:47:36 <TabAtkins__> shepazu: What other things does canvas have for a11y?
23:47:41 <TabAtkins__> pritchard: Juts ARIA stuff.
23:48:01 <TabAtkins__> pritchard: You may want to use things for various profiles.  OpenClipArt is all very presentational documents, frex.
23:50:02 <TabAtkins__> pritchard: We've also recently proposed setClickableRegion, which similarly lets you link a subtree element with a canvas region and lets AT know what's clickable.
23:50:49 <TabAtkins__> pritchard: [gives an example of how you might want a different path than the visual representation in SVG for focusing/activating AT behavior]
23:51:25 <homata> homata has joined #svg
23:51:58 <TabAtkins__> shepazu: Then I think Rich got into something weird with hit testing.
23:53:09 <plinss_> plinss_ has joined #svg
23:53:31 <TabAtkins__> pritchard: Rich thought we could combine setClickableRegion and hit-testing, such that the browser can automatically route clicks around.
23:53:59 <TabAtkins__> [explanation of how that could work potentially]
23:56:26 <TabAtkins__> heycam: I don't know if this works well with <select> - you'd need to map a region to an <option>, and then handle the <select> value changing yourself.
23:56:58 <TabAtkins__> pritchard: Yes.
23:57:44 <TabAtkins__> heycam: So you'd have to listen to mousedown on the particular element.
23:58:31 <TabAtkins__> shepazu: So I think on the surface it seems reasonable, though it verges into a retained mode.  You already have a retained mode with the fallback as well.
23:58:39 <TabAtkins__> shepazu: But where does this end?
23:58:59 <TabAtkins__> pritchard: It seems like this is the end.  Based on the OS AT APIs so far, these fill in all the information necessary.
00:00:03 <TabAtkins__> pritchard: We have focus position, caret position, and clickable regions.  That's as far as all the ATs go anyway.
00:01:08 <TabAtkins__> heycam: These seem more reasonable than the permathread suggests.
00:01:36 <TabAtkins__> pritchard: Well, one of the major objections was to simply keep it difficult to do these in Canvas, so authors instead go ahead and use "better" technologies like SVG.
00:02:04 <TabAtkins__> shepazu: The final part of the story imo is that two browser vendors have come forward and said "no".
00:02:21 <TabAtkins__> pritchard: We're working on this.  We've been talking with Apple, and with Jonas Sicking from Moz.
00:03:20 <TabAtkins__> pritchard: And MS has certain high AT standards in their products that make them potentially interested.
00:03:55 <TabAtkins__> pritchard: Also I've been working with Apple and Voiceover to fix their handling of Canvas.
00:04:16 <TabAtkins__> shepazu: So I think what you wanted in SVG was a method to bind an element to the path.
00:04:35 <TabAtkins__> shepazu: And my suggestion was, why not just have an SVG element (with ARIA) that simply carries the semantics.
00:05:25 <TabAtkins__> shepazu: The other is the above, but drawing the SVG shape into the canvas.
00:05:58 <TabAtkins__> shepazu: So why not use SVG?
00:06:11 <TabAtkins__> pritchard: Cost.  It's expensive to serialize paths.
00:06:59 <TabAtkins__> TabAtkins__: He suggested drawing with SVG instead, with a linkage to the represented element.
00:07:10 <TabAtkins__> pritchard: That works, but it doesn't fix canvas accessibliity.
00:07:19 <TabAtkins__> shepazu: No, it fixes platform image accessibility.
00:08:21 <plinss_> plinss_ has joined #svg
00:08:36 <TabAtkins__> shepazu: So if we draw SVG into a canvas we seem to lose a lot of the good retained-mode parts of SVG.  So what *would* it mean to combine these?
00:09:31 <TabAtkins__> shepazu: So if you animate the pie chart in canvas, don't you also have to update the clickable region?
00:10:02 <TabAtkins__> pritchard: Yes, but given the shape of the proposed APIs, you'd just reuse the path that you're using to draw anyway.
00:10:42 <TabAtkins__> ISSUE: Contact platform a11y api people about non-rectangular path regions.
00:10:42 <trackbot> Created ISSUE-2421 - Contact platform a11y api people about non-rectangular path regions. ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2421/edit .
00:10:58 <TabAtkins__> mattmay: Adobe likes non-rectangular paths.
00:12:00 <TabAtkins__> pritchard: If you put <canvas> into SVG, and you put a button into there, how do you use the subtree in SVG?
00:12:56 <TabAtkins__> shepazu: Increasingly, SVG is being used in HTML too.
00:18:15 <TabAtkins__> TabAtkins__: My opinion on the matters:  First, anything to do with text editting should, imo, never be done in Canvas.  There are massive complexities in text that the platform solves for you, and which most authors will not get right.
00:19:19 <TabAtkins__> Second, I see canvas as being very useful for (1) scripted images, (2) games, and (3) rendering of isolated controls (like fancy checkboxes).  When you start rendering entire forms or entire UIs in canvas, you're generally doing something wrong, and should instead be using what the platform provides (that is, do your overall UI in HTML).
00:19:48 <TabAtkins__> pritchard: Great internal policy, but in the web, there are already many cases where people use canvas for inappropriate things.
00:19:59 <TabAtkins__> pritchard: Also, some of these subjects are relevant directly to SVG.
00:20:28 <TabAtkins__> pritchard: SVG is widely currently used in static documents, but for interactive documents you probably want to plug into the AT APIs surrounding forms.
00:20:41 <TabAtkins__> pritchard: Like describing a region of a radial manu as a button.
00:20:58 <TabAtkins__> s/manu/menu/
00:21:19 <TabAtkins__> shepazu: I've done that with SVG and buttons already.
00:21:37 <TabAtkins__> pritchard: And we'll be reviewing more parts of ARIA/etc to see what's missing in SVG.
00:22:22 <TabAtkins__> shepazu: So you say you're making progress with the vendors; seems there's not too much for us to do?
00:22:46 <TabAtkins__> heycam: I thought a wide variety of diagrams and infographics would probably require a different set of ARIA semantics than what is already exposed based on HTML.
00:22:52 <TabAtkins__> shepazu: Yes, and that's what I want to talk about.
00:22:58 <TabAtkins__> shepazu: There's two things I plan to do in SVG2.
00:23:20 <TabAtkins__> shepazu: One is, make an ontology of infographics (document navigation paths, etc)
00:24:18 <TabAtkins__> shepazu: Assessment techniques one uses when looking at infographics, and annotate them.
00:24:39 <TabAtkins__> pritchard: And for things like pie charts, <table>s are a great retained version of data that could potentially work here with SVG.
00:25:09 <TabAtkins__> mattmay: SAS has a demo involving tactile feedback of interactive graphics.
00:25:39 <shepazu> http://schepers.cc/svg/accessibility/
00:27:50 <TabAtkins__> shepazu: This example shows how you could use SVG to create a tabular appearance, annotating with ARIA to make it exposed as a table.
00:28:11 <TabAtkins__> shepazu: (There's a problem that ARIA doesn't expose role=column.  WAI-ARIA rejected my feedback to add that earlier.)
00:29:03 <TabAtkins__> shepazu: One, setting up roles and attributes for infographics (for SVg, canvas, flash, etc.)
00:29:15 <TabAtkins__> shepazu: Two, start talking to AT vendors about expanding the platform APIs for a11y
00:29:40 <TabAtkins__> mattmay: I don't necessarily think that the native APIs really need to be fixed.  They're probably fine for what you need to do.
00:30:06 <TabAtkins__> mattmay: I think your best bet is to produce a clean DOM with good ARIA, and then file bugs yelling at them for not following the spec.
00:30:12 <TabAtkins__> shepazu: That's basically my plan anyway.
00:30:50 <TabAtkins__> heycam: For things like Excel, how are charts exposed to AT APIs?  They must do something already.
00:30:55 <TabAtkins__> mattmay: Dunno for sure.
00:31:09 <TabAtkins__> mattmay: All of that work is custom between Office.
00:31:21 <TabAtkins__> mattmay: It's not a model I'd want to follow.
00:32:41 <TabAtkins__> mattmay: But if you create a model that would support it, I'm sure they'd be glad to follow.
00:33:07 <shepazu> http://www.w3.org/TR/html-aapi/ 
00:33:37 <TabAtkins__> shepazu: The second thing I want to do in SVG2 is produce an analog of this guide for SVG.
00:34:20 <TabAtkins__> heycam: This is the default roles you get if you don't use ARIA.  We should definitely have this.
00:35:16 <TabAtkins__> shepazu: So those are the two things I want to do in SVG2 for a11y.
00:35:23 <TabAtkins__> shepazu: I've already started on the API mapping.
00:35:34 <TabAtkins__> shepazu: Do we feel we need any kind of resolution on the canvas api stuff?
00:36:06 <TabAtkins__> heycam: I think the kinds of things Charles proposed isn't really needed in SVG.
00:36:12 <TabAtkins__> pritchard: Right - you already have most of this.
00:36:30 <TabAtkins__> heycam: But if you have canvas in SVG, whatever gets decided for HTML would get handled just fine.
00:38:52 <TabAtkins__> heycam: I think we should maybe integrate editable text with canvas.
00:39:06 <TabAtkins__> pritchard: [something about shape-wrap]
00:40:28 <TabAtkins__> mattmay: There's precedent for creating an overlay/underlay of live areas.  Like PDF.
00:41:40 <TabAtkins__> mattmay: The idea is that you may have a @contenteditable rendered in SVg or Canvas or whatever.  Your subtree-equivalent control would just occupy the same space, but is hiddne.
00:41:53 <TabAtkins__> mattmay: So selecting the text or whatever would map down into the subtree.
00:42:05 <shepazu> here are some issues raised by Rich Schwerdtfeger on SVG accessibility http://www.w3.org/Graphics/SVG/WG/wiki/Accessibility_Issues
00:43:04 <plinss_> plinss_ has joined #svg
00:49:25 <heycam> RRSAgent, make minutes
00:49:25 <RRSAgent> I have made the request to generate http://www.w3.org/2011/07/27-svg-minutes.html heycam
00:54:29 <dino> dino has joined #svg
01:53:55 <Zakim> ChrisL, you asked to be reminded at this time to go to sleep
02:08:56 <jwatt> talking to ghosts, Zakim?
02:38:56 <Zakim> Zakim has left #svg
03:05:31 <jwatt> jwatt has joined #svg
03:24:54 <anne> anne has joined #svg
03:30:37 <alexmog_> alexmog_ has joined #svg
03:48:47 <alexmog_> alexmog_ has left #svg
03:53:08 <plinss_> plinss_ has joined #svg
03:57:53 <plinss_> plinss_ has joined #svg
04:32:04 <plinss_> plinss_ has joined #svg
05:29:42 <heycam> heycam has joined #svg
05:31:32 <TabAtkins__> TabAtkins__ has joined #svg
06:35:22 <jwatt> heycam?
06:36:42 <heycam> hi jwatt
06:36:50 <jwatt> hi
06:36:53 <jwatt> if I remove xhtml1-transitional+edit.dtd I get 
06:37:23 <jwatt> Recoverable error on line 114 of publish.xsl:
06:37:24 <jwatt>   FODC0002: java.io.FileNotFoundException:
06:37:26 <jwatt>   svg2/master/xhtml1-transitional+edit.dtd (No such file or directory)
06:37:55 <jwatt> when trying to run the "Build chapters" section
06:38:16 <jwatt> is fixing that just a case of changing the doctype declarations in all the chapters?
06:38:26 <jwatt> or is there something else I should know about?
06:38:38 <jwatt> or should I really keep that file?
06:38:57 <jwatt> seems like we should just use the html 5 doctype now, no?
06:39:03 <heycam> it would be good if it could be done without
06:39:13 <heycam> I don't remember the particular reason I included it to get things working
06:39:25 <jwatt> oh
06:39:27 <heycam> but yes, if we can just the HTML5 doctype, that would be great
06:39:27 <jwatt> hm
06:39:29 <jwatt> there was a reason
06:39:30 <heycam> if it doesn't break things
06:39:32 <jwatt> sucks :)
06:39:58 <heycam> perhaps it was that some files used HTML entities?
06:40:11 <heycam> (like &nbsp;) and saxon thus wanted to fetch the DTD to expand them?
06:40:32 <jwatt> would make sense
06:40:45 <jwatt> ok, I guess I just have to keep playing
06:40:46 <jwatt> thanks
06:40:50 <heycam> ok, no problem
06:41:00 <heycam> I will be awake for another half hour or so, if you have more questions before I head off
06:41:36 <jwatt> ok, thanks
06:41:58 <jwatt> dunno how much longer I can stay awake
06:42:03 <heycam> ok
06:42:13 <heycam> oh wow have you been up all night?
06:44:41 <jwatt> yeah
06:44:47 <jwatt> need. to. finish.
06:49:44 <heycam> :(
07:10:08 <jwatt> heycam: is svg.idlx only a build artifact?
07:10:14 <jwatt> or is it something we want to publish?
07:10:15 <heycam> yes
07:10:18 <heycam> no
07:10:20 <jwatt> cool
07:10:22 <jwatt> ta
07:13:29 <jwatt> ah, crap
07:13:35 <jwatt> it wants the .mod files in DTD too
07:14:49 <jwatt> need to get rid of svgdtd.html too I guess
07:15:16 <heycam> kill kill kill
07:16:23 <jwatt> master/publish.xml dies
07:16:25 <jwatt> err
07:16:30 <jwatt> just the svgdtd bit :)
07:17:11 <heycam> whew
07:28:14 <nhofsted> nhofsted has joined #svg
07:31:31 <jwatt> heycam: 
07:31:35 <jwatt> java -classpath /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/tools/saxonb/saxon9.jar net.sf.saxon.Transform -ext:on -dtd:off -expand:off -l:on /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/svg2/master/publish.xml /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/tools/publish.xsl chapters-to-build="index ..."
07:32:00 <jwatt> run from /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/svg2/
07:32:25 <jwatt> that puts its output in /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/publish/
07:32:28 <jwatt> what the heck?!
07:34:01 <heycam> hmm
07:34:18 <heycam> does it perhaps use the cwd to work out where to create the publish/ directory?
07:34:34 <heycam> (i.e. it wants to be run with .../master/ as the cwd?)
07:34:53 <jwatt> that's not what your perl version of build.pl does
07:35:03 <jwatt> oh
07:35:04 <jwatt> wait
07:35:08 <jwatt> hmm
07:35:12 <jwatt> yeah
07:35:19 <jwatt> it does run in master
07:35:35 <jwatt> so there must be something hardcoded somewhere in one of the files
07:35:58 <heycam> not impossible!
07:37:19 <jwatt> <output use-pe-publish-directory='true'/>
07:37:36 <jwatt> in publish.xml
07:38:15 <jwatt> hmm I recall reading about a second attribute somewhere
07:38:33 <heycam> lemme pull from the repo and take a look
07:38:47 <heycam> url again?
07:38:50 <jwatt> publish-directory=
07:38:52 <jwatt> sweet
07:38:55 <jwatt> (assuming it works)
07:39:04 <jwatt> it's not online
07:39:08 <heycam> ok
07:39:16 <jwatt> yet
07:44:26 <jwatt> got it
07:44:28 <jwatt> next!
07:46:49 <jwatt> so glad I did the porting of your script with you when I did!
07:48:12 <heycam> woo
07:49:51 <jwatt> very next line is busted :)
07:49:58 <jwatt> a pretty close next
07:55:33 <jwatt> heycam: my $chaptersNoIndex = join(' ', @all[1..$#all]);
07:55:45 <heycam> yeah...
07:55:51 <jwatt> that means all the items in the array except the first one?
07:55:55 <heycam> yep
07:55:57 <jwatt> ok
07:56:00 <heycam> in a string, joined with a space
07:56:00 <jwatt> that makes more sense
07:56:51 <jwatt> build.py gets all but the last one by mistake
07:56:52 <jwatt> oops
07:58:01 <heycam> :)
08:00:56 <jwatt> ok, I /think/ I'm pretty much through this
08:01:04 <jwatt> just a bit of cleanup and then a lot of testing
08:01:16 <heycam> yay
08:02:20 <jwatt> omg, I have a single-page.html!
08:02:28 <heycam> !!
08:03:45 <jwatt> right, now to take a real careful look at the diff between the rejigged system and the old system
08:12:03 <heycam> ok I better go to bed, gotta be up at 7:15 or so to be ready to walk to the meeting location with the others
08:12:36 <jwatt> heycam: 
08:12:40 <jwatt> +++ build/publish/types.html	2011-07-28 09:10:53.000000000 +0100
08:12:42 <jwatt> @@ -2,7 +2,7 @@
08:12:43 <jwatt>    Scalable Vector Graphics (SVG) 1.1 (Second Edition)
08:12:45 <jwatt>    Chapter 4: Basic Data Types and Interfaces
08:12:46 <jwatt>  
08:12:48 <jwatt> -  $Id: types.html,v 1.99 2011/07/22 05:00:21 cmccorma Exp $
08:12:49 <jwatt> +  $Id$
08:12:51 <jwatt>  
08:12:52 <jwatt>    Note: This document is generated from ../master/types.html.
08:12:54 <jwatt>    Run "make" from ../master/ to regenerate it.
08:12:56 <jwatt> if you're still about, any idea why that's happening?
08:13:18 <heycam> it'll be cvs keyword expansion, yeah?
08:13:28 <jwatt> ahhh
08:13:30 <heycam> i.e., such things don't exist in hg probably?
08:13:36 <jwatt> no idea
08:13:51 <jwatt> ok, I'll ignore that :)
08:13:53 <jwatt> thanks
08:14:25 <heycam> cool
08:14:30 <heycam> ok, talk to you tomorrow
08:16:05 <jwatt> sleep well!
08:16:17 <heycam> you too ;)
09:18:25 <jwatt> jwatt has joined #svg
10:59:16 <karl> karl has joined #svg
11:20:49 <jwatt> jwatt has joined #svg
12:24:55 <jwatt> jwatt has joined #svg
13:10:17 <nhofsted> nhofsted has left #svg
13:26:19 <jwatt> jwatt has joined #svg
14:08:52 <TabAtkins__> TabAtkins__ has joined #svg
15:48:27 <birtles> birtles has joined #svg
15:50:24 <ed> zakim, start telcon
15:50:38 <Zakim> Zakim has joined #svg
15:50:49 <ed> trackbot, start telcon
15:50:52 <trackbot> RRSAgent, make logs public
15:50:54 <trackbot> Zakim, this will be GA_SVGWG
15:50:54 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
15:50:55 <trackbot> Meeting: SVG Working Group Teleconference
15:50:55 <trackbot> Date: 28 July 2011
15:50:56 <shepazu> shepazu has joined #svg
15:51:11 <ed> Zakim, this meeting spans midnight
15:51:11 <Zakim> I don't understand 'this meeting spans midnight', ed
15:52:25 <shepazu> Zakim, room for 3?
15:52:28 <Zakim> ok, shepazu; conference Team_(svg)15:52Z scheduled with code 26633 (CONF3) for 60 minutes until 1652Z; however, please note that capacity is now overbooked
15:52:41 <cyril> cyril has joined #svg
15:52:51 <ed> RRSAgent, this meeting spans midnight
15:53:36 <Zakim> Team_(svg)15:52Z has now started
15:53:46 <Zakim> + +1.206.675.aaaa
15:54:14 <ed> meeting: SVG WG Seattle F2F
15:54:18 <cyril> RRSAgent, what is your time zone ?
15:54:18 <RRSAgent> I'm logging.  Sorry, nothing found for 'what is your time zone '
15:54:22 <ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
15:54:42 <ed> Chair: Erik
15:57:17 <heycam> Scribe: Cameron
15:57:20 <heycam> ScribeNick: heycam
15:57:27 <heycam> Topic: Starting SVG 2
15:57:57 <vhardy> vhardy has joined #svg
15:58:51 <jwatt> ah
15:58:53 <jwatt> err
15:59:21 <TabAtkins_> TabAtkins_ has joined #svg
15:59:47 <jwatt> should be on in roughly 60 seconds
16:02:29 <jwatt> it's not letting me in
16:02:37 <jwatt> have the telcon details changed?
16:03:05 <heycam> Zakim, code?
16:03:05 <Zakim> the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
16:03:54 <Zakim> +??P74
16:04:07 <jwatt> Zakim, ??P74 is me
16:04:07 <Zakim> +jwatt; got it
16:06:02 <Zakim> -jwatt
16:09:39 <jwatt> yeah
16:09:48 <jwatt> skype seems to be sick
16:09:59 <heycam> hmm, do you have a voip client?
16:10:06 <jwatt> I have skype
16:10:08 <jwatt> :p
16:10:13 <heycam> sorry, I mean a SIP client
16:10:37 <jwatt> no
16:11:04 <heycam> www.w3.org/2006/tools/wiki/Zakim-SIP
16:11:20 <heycam> I use code.google.com/p/telephone/ as the SIP client
16:11:31 <heycam> and created an account on ekiga.net to use with it, as suggested by that wiki page
16:12:03 <heycam> I find calling in to the Zakim SIP interface much better quality than using Skype, actually
16:12:35 <heycam> jwatt, while you work on getting that set up, we will discuss a different short topic
16:12:46 <heycam> Topic: <switch> in SVG 2
16:12:48 <jwatt> sure
16:12:53 <ed> http://lists.w3.org/Archives/Public/www-svg/2011Jun/0039.html
16:13:26 <heycam> ED: switch in SVG is not very useful as its' designed, because if you introduce new SVG elements in say SVG 3, the requiredFeatures attribute will not be seen on that elemnet, because it's not recognised as an SVG element
16:13:37 <heycam> ... which is something I found a bit weird, it's kind of not very cleverly designed in that sense
16:13:42 <heycam> ... so I had a few questions on what to do with that
16:13:54 <heycam> ... what we want to decide for switch in SVG 2, either deprecate it or fix it somehow
16:14:03 <heycam> ... in my example, I show a few different cases
16:14:09 <heycam> ... one would be a newly introduced element
16:14:22 <heycam> ... one woudl be a custom element, maybe that just one UA implements experimentally
16:14:32 <heycam> ... and because of the requiredFeatures just being in the null namespace, it's not recognised
16:14:35 <heycam> ... and it's not switchedo n
16:14:40 <heycam> s/o n/ on/
16:15:02 <heycam> ... in my case I wanted to use it on video elements, but since the video element from 1.2T is not recognised as an SVG element it didn't work
16:15:22 <heycam> ... you cannot currently have a 1.2T video element with switch, and then fallback to a foreignObject with html:video
16:15:26 <heycam> DS: you could nest it in a group
16:15:40 <heycam> ... it's a kludge, but I agree
16:16:22 <heycam> ED: another aspect is what to do with non-chosen subtrees
16:16:22 <heycam> ... currently we don't really say what's supposed to happen with those
16:16:22 <heycam> ... but in some cases we get behaviour just from ebing in the document
16:16:22 <heycam> ... audio elements might start playing
16:16:22 <heycam> ... which can be a problem
16:16:28 <heycam> DS: I thought we resolved at some point that "rendered" could mean that audio doesn't play
16:16:45 <heycam> ED: I think the larger question is what we want to do with the switch element
16:16:48 <Zakim> +??P2
16:16:54 <heycam> ... do we still want to keep it around, and if so, how should we fix it?
16:17:07 <heycam> VH: can you give an example of what you would do with a new element?
16:17:08 <jwatt> Zakim, ??P2 is me
16:17:08 <Zakim> +jwatt; got it
16:17:12 <heycam> ED: say SVG 2 introduces a new element foo
16:17:16 <heycam> ... and we add a new feature string for that
16:17:22 <heycam> ... so we put requiredFeatures="string" on taht element
16:17:36 <heycam> ... in UAs that don't support that new foo element, it won't actually pick up that requiredFeatures attribute
16:17:42 <heycam> ... it's seen as not have a requiredFeatures
16:17:51 <shepazu> shepazu has joined #svg
16:18:24 <heycam> CM: so it doesn't look for a DOM attribtue requiredFeatures, but because it doesn't implement SVGConditionalSomething?
16:18:49 <heycam> VH: so the processing model of switch currently is to find the first element in the switch, and if you understand that element and it passes the attributes, then you use it
16:19:04 <heycam> DS: it seems particularly ill designed
16:19:27 <heycam> VH: originally switch was introduced to help with progressive implementation of the spec
16:19:39 <heycam> ... so authors could do some animation in UAs that didn't implement animation yet
16:19:49 <heycam> CC: would it help to have requiredFeatures in an SVG namespace?
16:21:11 <jenyu> jenyu has joined #svg
16:21:33 <TabAtkins_> Zakim, mute jwatt
16:21:33 <Zakim> jwatt should now be muted
16:21:40 <heycam> Zakim, who is on the call?
16:21:40 <Zakim> On the phone I see +1.206.675.aaaa, jwatt (muted)
16:22:35 <heycam> ED: how do we want to proceed?
16:22:42 <heycam> DS: you could put it on a g
16:23:41 <heycam> BB: what about failing unknown elements?
16:24:55 <heycam> CM: you could just force it to look at that attribute in the null namespace, regardless of the namespace of the unknown element
16:25:36 <cyril> Zakim, unmute jwatt
16:25:36 <Zakim> jwatt should no longer be muted
16:25:48 <heycam> ISSUE: define switch to work with unknown elements and processing behaviour for audio elements etc
16:25:48 <trackbot> Created ISSUE-2422 - Define switch to work with unknown elements and processing behaviour for audio elements etc ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2422/edit .
16:26:00 <heycam> Topic: Starting on SVG 2
16:26:02 <shepazu> shepazu has joined #svg
16:26:33 <heycam> JW: basically I've been mucking around with a website we can use as a staging server to be able to get mercurial hooks
16:26:43 <heycam> ... I've given up on the w3c systeam to have the resources for that
16:26:58 <heycam> ... so I'm using this server as a staging thing which can do a bunch of checks, before passing it on to the w3c hg repo
16:27:08 <heycam> ... I started a wiki page
16:27:10 <jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
16:27:49 <heycam> DS: why was this necessary?
16:28:06 <heycam> JW: for the mercurial hooks section
16:29:49 <heycam> CM: [explains the hooks]
16:30:28 <heycam> JW: we could make it so that when successful changesets get pushed, that it pushes it to the w3c server automatically
16:30:37 <heycam> ED: how much of a problem would it be if we pushed to the w3c repo?
16:30:39 <heycam> JW: it would be a pain
16:30:45 <heycam> ... this is one of the things I was going to bring up
16:31:10 <heycam> ... if we want to deal with this system that allows checks and things, it might be a good idea to have a special key for svgwg.org so that it's the only person pushing to the official server once the changeset has passed the checks
16:31:18 <heycam> ... but you're right we don't want to have to merge
16:31:26 <heycam> ... if one person pushes in one place and others in the other
16:31:30 <heycam> DS: how hard was it to do those hooks?
16:31:40 <heycam> JW: to write them, I didn't really know anything about it before
16:31:46 <heycam> ... took me a few days to work out
16:31:56 <heycam> ... but it's easy now that I've looked at some examples
16:32:08 <heycam> DS: do you think this initial infrastructure would be difficult for the w3c team to install?
16:32:18 <heycam> JW: the thing they're not happy about is that hooks are basically scripts that run on the server
16:32:24 <heycam> ... and they don't trust anyone to be pushing random stuff
16:32:38 <heycam> ... not that people would be malicious, but if they make a mistake in their hook and it makes something bad on the server, or whatever
16:32:48 <heycam> ... so they would want to review the hooks every time we made a change to them
16:33:00 <heycam> ... at least in the early stages that might be frequent
16:33:23 <heycam> DS: so the idea is that we develop our system, get our hooks in place and then we could maybe deploy it on the w3c site?
16:33:27 <heycam> JW: yes, perfectly possible
16:33:37 <heycam> DS: long term, it seems having this weird redirection is ...
16:33:48 <heycam> ED: I think it would help to be able to expierment with checking systems for the spec itself
16:33:52 <heycam> ... I use that for my site, for example
16:33:59 <heycam> ... catching errors before allowing pushing to the server
16:34:01 <heycam> DS: ok, that's cool
16:34:18 <heycam> JW: one of the main things I want to sort out from the start is line ending changes getting pushed
16:34:59 <heycam> ... one of the things that hg has to stop trashing their diff and trashing hg blame/annotate, is an extension that lets you have a file with patterns in it, say files ending in .txt are text files
16:35:05 <heycam> ... and .whatever is binary files
16:35:13 <heycam> ... and also certain files that are fixed unix or windows line endings
16:35:34 <heycam> ... so you clone the repo, and when you check out the working copy on the machine, it autoamtically converts normal text files to those you have on your machine, so you can work in your normal text editor
16:35:45 <heycam> ... so you won't screw up the diff when committing due to the line ending differences
16:35:50 <jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
16:35:52 <heycam> ... some of you already have an hgrc file in your home directory
16:36:07 <heycam> ... if we're going to use this ul extension, it would be good to have all these lines in your config file
16:36:27 <heycam> ... that page tells you where to put your config file and what to put in it
16:36:28 <cyril> s/ul extension/eol extension/
16:36:41 <heycam> ... as far as users are concerned, that's all you need to do
16:37:10 <jwatt> http://mercurial.selenic.com/wiki/EolExtension
16:37:27 <heycam> ... that's the documentation if anyone wants to look it up to set particular line endings for some files
16:37:39 <heycam> ... so one of the hooks on the server checks for line ending changes and blocks the push if someone screws them up
16:38:02 <heycam> DS: I'm trying to compare my existing hgrc file with yours
16:38:11 <heycam> ... I'm wondering what the key parts to change are
16:38:18 <heycam> JW: the important parts are the [eol] section
16:38:37 <heycam> ... and in the [extensions] section, the "hgext.eol =" line, which is the line that enables the extension
16:38:47 <heycam> ... the extension comes bundled with hg, so there's nothing to install, it just enables it
16:38:51 <heycam> s/it just/that line just/
16:39:01 <heycam> DS: is 1 and True the same thing?
16:39:08 <heycam> JW: I imagine so
16:39:49 <heycam> ... tbh I would suggest adding all of these to your config file
16:40:51 <heycam> DS: so everyone who's planning on committing, let's add this config now
16:41:57 <vhardy> vhardy has joined #svg
16:43:10 <heycam> JW: so basically, in terms of the repo, I went ahead and imported the Second Edition files
16:43:19 <heycam> ... but I split things up a bit
16:43:31 <heycam> ... any files that are generated are no longer in the repository, they will just be created locally on your machine
16:43:42 <heycam> ... the .hgignore file that comes with the repo will make the build directory ignored
16:43:57 <heycam> ... and I split the tools directory out, since I discovered there's quite a bunch of tools down the cvs repo that were required
16:44:06 <heycam> ED: the generated files, that includes the publish directory?
16:44:18 <heycam> JW: I've made the builds create a directory build/publish/
16:44:27 <heycam> ... all files generated that aren't published go in build/
16:44:38 <heycam> ... and the stuff in build/publish/ would be zipped up, whatever
16:44:49 <heycam> ED: is it fine to have this kind of set up?
16:45:04 <heycam> ... currently it seems everything on the w3c site is on some kind of version control system
16:45:06 <heycam> ... everything that's public
16:45:15 <heycam> ... but can we have the publish/ directory something that is generated on the w3c server?
16:46:02 <heycam> JW: what I changed is that instead of having master/ and publish/ at the root, we have a . and a build/publish/
16:46:20 <heycam> ... and erik is asking whether the w3c servers will have a problem with build/publish/ not being in version control
16:46:24 <Zakim> -jwatt
16:47:26 <jwatt> Zakim, code
16:47:26 <Zakim> I don't understand 'code', jwatt
16:47:49 <jwatt> what's the code?
16:48:16 <heycam> Zakim, code?
16:48:16 <Zakim> the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
16:48:27 <Zakim> +??P2
16:48:57 <jwatt> Zakim, ??P2 is me
16:48:57 <Zakim> +jwatt; got it
16:49:47 <cyril_> cyril_ has joined #svg
16:50:53 <heycam> DS: would we not have somewhere to point the public to?
16:51:05 <heycam> JW: it would be easy to have a hook on svgwg.org to publish the generate spec there
16:51:11 <heycam> ... maybe that could be done on the w3c server
16:51:22 <heycam> DS: couldn't you check it in somewhere on the w3c server?
16:51:38 <heycam> ED: we could have a hook on the svgwg.org server, that syncs the build version or checks it in somewhere else
16:51:44 <heycam> DS: that would be a feature
16:52:16 <vhardy_> vhardy_ has joined #svg
16:54:02 <heycam> CM: it could be checked in to www.w3.org/Graphics/SVG/
16:54:07 <heycam> JW: or a separate repo on dvcs.w3.org
16:54:20 <heycam> DS: we should consider whether this infrastructure could be generalised to other WGs in the future
16:55:12 <heycam> JW: fwiw I just checked, on my machine the master directory is a quarter of the size compared to having the publish directory in there too
16:55:15 <heycam> DS: ok
16:55:33 <heycam> JW: for the moment, I've pushed these repos up to a sandbox on svgwg.org
16:55:41 <jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2/
16:55:49 <jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2-tools/
16:56:17 <heycam> JW: you could just check those two out side by side, then run make inside the svg2 directory
16:56:49 <heycam> ... starting with the tools repo
16:57:03 <heycam> ... first change is I added the hgeol file for the eol extension
16:57:56 <Zakim> -jwatt
16:58:35 <jwatt> it's saying the conference is restricted
16:58:52 <heycam> jwatt, do you want to try skyping in to one of us here directly?
16:59:02 <vhardy_> jwatt, what is your skype id?
16:59:03 <heycam> vhardy_ will place his laptop in the middle of the table
16:59:15 <jwatt> msg username
16:59:53 <Zakim> - +1.206.675.aaaa
16:59:54 <Zakim> Team_(svg)15:52Z has ended
16:59:55 <Zakim> Attendees were +1.206.675.aaaa, jwatt
17:00:06 <heycam> jwatt, vhardy_ will just try to set up a conference bridge here, might be better actually
17:00:13 <jwatt> ok
17:01:25 <vhardy_> jwatt, can you call  408-536-9900 (code: 5108463, pwd: 20112011)
17:01:51 <jwatt> calling
17:03:38 <vhardy_> there is a UK number +44 208 606 1105
17:04:54 <jwatt> no
17:05:00 <jwatt> it's reading options
17:05:08 <jwatt> this isn't working
17:05:27 <jwatt> vhardy: I think it's empty
17:05:28 <vhardy> what isn't?
17:05:34 <jwatt> the meeting
17:05:39 <jwatt> it seems to thing I'm in
17:05:52 <jwatt> but is reeling of a list of numbered options
17:06:18 <vhardy> you should not get the options.
17:06:32 <vhardy> Let me try to restart the conf and then you can dial in again. ok?
17:06:42 <jwatt> ok
17:07:45 <vhardy> you can dial in now.
17:07:59 <jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a
17:08:04 <jwatt> see comment at top in the meantime
17:10:08 <heycam> JW: I copied 4 directories from CVS and a few files and put them in the tools repo
17:10:17 <heycam> ... I just want to check to see if it's ok
17:10:32 <heycam> ... I annotated it r=WG as if we have approved it
17:10:45 <jwatt> argh, it's interupted me to read more options
17:11:28 <heycam> JW: the hooks are actually managed in the repo itself
17:11:31 <jwatt> https://svgwg.org/hg/svg-repo-hooks/file/tip
17:11:35 <heycam> ... the hooks are there
17:11:42 <heycam> ... everyone who has access to the server can access those hooks
17:11:50 <heycam> ... so all the hooks are in the hooks.ui file
17:12:07 <heycam> ... and hg is told which ones of those to actually use in the hgrc file there
17:13:00 <heycam> ... let's look at the svg2 repo
17:13:25 <heycam> ... the comment at https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a indicates which directories and files are gone compared to the 1.1F2 repo in CVS
17:13:37 <heycam> ... I was also wondering if there was a few other files we could get rid of
17:13:49 <heycam> ... one of those is master/copyright-notice.html
17:14:07 <heycam> CM: that's a vestige, you're fine to remove that
17:14:13 <heycam> JW: the other one was master/indexlist.html
17:14:21 <heycam> ... which is mentioned in publish.xml but doesn't seem to get used
17:14:52 <heycam> ... I'll take that out too
17:15:00 <heycam> ... also master/names.html
17:15:04 <heycam> CM: don't know why that's there
17:15:09 <heycam> JW: ok, those were my main questions
17:15:11 <anne> anne has joined #svg
17:15:25 <heycam> ... one thing I would note is that the relaxng directory I haven't added yet
17:15:35 <heycam> ... it seems to have 1.2T stuff and 2.0 stuff according to a comments
17:15:39 <heycam> s/comments/comment/
17:15:43 <heycam> ... we can always add it in later
17:15:59 <thorton> thorton has joined #svg
17:16:08 <heycam> CM: I think we should wait until murata-san has done the rng for 1.1F2, and start from there
17:16:17 <heycam> JW: the third commit was just me fixing build scripts and things
17:16:31 <heycam> ... and any other files so that make would work with the tools directory where it is now
17:16:38 <heycam> ... if you check them out side by side, you should be able to build
17:16:53 <heycam> ... so don't pull those repos, I'll create new ones without those files we mentioend
17:17:05 <heycam> ... should I then push them into svgwg.org/hg/svg2/?
17:18:57 <heycam> CM: please mail the WG list once the repos are set up in their final position, and list instructions for us to build the spec
17:26:09 <heycam> shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide
17:26:23 <anne> anne has joined #svg
17:28:15 <heycam> CM: how we will review patches? attach them to bugs?
17:28:20 <jwatt> https://svgwg.org/hg/svg-repo-hooks/file/tip/hgrc
17:28:22 <heycam> JW: not sure, we do have a bugzilla instance
17:28:30 <shepazu> s/hook/höök/
17:28:32 <heycam> ... don't know how useful the review will be in the end
17:29:22 <TabAtkins_> TabAtkins_ has joined #svg
17:30:34 <heycam> [we review the hooks listed in the hgrc file]
17:34:22 <ed> --- 15 min break ---
17:39:17 <thorton> thorton has joined #svg
17:39:41 <tbah> tbah has joined #svg
17:52:00 <ed> ok, so we moved some topics around today
17:52:11 <vhardy> ScribeNick: vhardy
17:52:18 <vhardy> Topic: path extensions
17:52:22 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Path_data_turtle_graphics_proposal
17:52:51 <vhardy> heycam: some things are hard to do.
17:53:01 <vhardy> ... one is to have a part segment at a particular angle.
17:53:13 <vhardy> ... turtle graphics type commands would be a lot easier.
17:54:05 <vhardy> ... it would solve a usability problem. It would also make animation easier.
17:54:33 <vhardy> heycam shows a segment as in http://www.w3.org/Graphics/SVG/WG/wiki/File:A2.svg
17:55:11 <vhardy> .... it is not easy to animate that segment properly to rotate around the elbow.
17:55:24 <vhardy> ... with the proposed value, animating the single rotation value would be sufficient
17:55:40 <vhardy> ... shepazu wanted to talk about a simpler arc command.
17:56:04 <vhardy> .... my proposal and a simpler arc command would make doing things like pie charts a lot easier.
17:56:13 <vhardy> ... in the wiki page there are two different proposals.
17:56:31 <vhardy> ... the first proposal adds new path commands (r and R)
17:56:54 <vhardy> R would set an absolute degree value.
17:57:11 <vhardy> r would set a relative rotation
17:57:39 <vhardy> f would be a straight line from the current point using the current rotation angle, for a given length (see wiki).
17:57:45 <vhardy> f would always be relative
17:58:13 <vhardy> .... with this proposal, can only do straight line segments.
17:58:55 <vhardy> ... Second proposal is to not introduce an f and modify existing path commands to say that they may be subject to the rotation angle.
18:00:06 <vhardy> e.g., M 0, 0 h 10 r 45 ~ 10
18:00:36 <plinss_> plinss_ has joined #svg
18:02:08 <vhardy> (discussion on what r45 L 100 200 would mean)
18:03:55 <vhardy> shepazu: adding an implicit rotation in the path command that influences the following commands can be confusing.
18:05:06 <vhardy> heycam: the default rotation is the tangent to the curve at the current point.
18:06:20 <vhardy> shepazu: what if we had syntax like r 15, 10 (rotate 45, length 10)
18:08:18 <vhardy> (going over the second example)
18:08:46 <vhardy> shapazu: there was a discussion about extending the path syntax v.s., doing a super path.
18:09:06 <vhardy> heycam: I think there it is better to extend the path syntax.
18:09:48 <vhardy> (discussion about similarity to adding paint servers to SVG with the image values)
18:11:09 <vhardy> vhardy: I think the feature is very valid.
18:11:23 <vhardy> shepazu: let's take a pie chart use case.
18:15:33 <vhardy> (discussion about pie segments, showing different people have various ways of thinking about them).
18:16:52 <vhardy> cyril: there was improvements for SVG 1.2.
18:17:06 <vhardy> shepazu: may be we should not touch the path syntax at this point.
18:17:56 <TabAtkins_> TabAtkins_: <path><segment transform='...' d='...' /><segment .../></path>
18:18:12 <vhardy> heycam: the behavior for syntax error is precisely defined, so this is not introducing a new risk.
18:18:28 <vhardy> shepazu: then you have things that are poorly drawn.
18:18:36 <vhardy> heycam: it would be the same with other solutions.
18:18:52 <vhardy> shepazu: but you could switch to an alternate content.
18:18:56 <vhardy> heycam: with this too.
18:18:58 <cyril> cyril has joined #svg
18:19:14 <vhardy> shepazu: you are right, we are going to extend SVG, so we are going that have this in multiple areas.
18:19:14 <cyril> CC: I was talking about: http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html
18:19:51 <vhardy> shepazu: I was thinking about adding a <shape> element.
18:20:25 <vhardy> heycam: should we think about having a new way to extend the path syntax and not change the <path> element.
18:21:10 <vhardy> shepazu: I am uneasy about it, but I do not have a good alternate solution.
18:21:25 <vhardy> tab: I think we can add to the syntax and not create problems we would not have otherwise.
18:21:36 <vhardy> tab: that argument applies to anything you could add.
18:21:44 <vhardy> tab: <shape> wont help that issue.
18:22:00 <vhardy> shepazu: I think we may get an adverse reaction to changes to <path>
18:22:34 <vhardy> heycam: may be the expectation was there that we would not change the path syntax.
18:23:44 <vhardy> vhardy: what about having an API for the feature?
18:23:55 <vhardy> heycam: it would not help for the declarative animation use case.
18:24:07 <vhardy> shepazu: I think the use case is valid.
18:25:36 <vhardy> (discussion about the ~ proposal).
18:26:22 <vhardy> cyril: could it be that after the rotation command, then it affects everything that comes after it. No need for a ~
18:26:49 <vhardy> (general agreement that this is better)
18:29:03 <vhardy> vhardy: how do you get back to the current tangent if you have modified it?
18:29:11 <vhardy> heycam: not currently possible in the proposal.
18:29:18 <vhardy> (discussion on how to address that).
18:36:12 <vhardy> ACTION: heycam create a proposal where the R/r commands impact the following commands (until the next r/R command occurence) and add a way to set the rotation to the current tangent on the path.
18:36:12 <trackbot> Created ACTION-3084 - Create a proposal where the R/r commands impact the following commands (until the next r/R command occurence) and add a way to set the rotation to the current tangent on the path. [on Cameron McCormack - due 2011-08-04].
18:36:46 <vhardy> cyril: it would be good to have a list of changes we want to path.
18:37:07 <vhardy> cyril: last year, we presented use cases at SVG Open. e.g., the ability to compose path, concatenate, reverse.
18:38:18 <vhardy> cyril: I will send a link to the paper.
18:40:23 <cyril> perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
18:40:28 <cyril> http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
18:41:48 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
18:42:03 <heycam> cyril, you can add dot points to that "Path improvements" section there?
18:44:11 <vhardy> Topic: Catmul curves
18:44:25 <shepazu> http://schepers.cc/getting-to-the-point
18:44:48 <vhardy> shepazu: look at the pictures
18:45:34 <vhardy> shepazu: if you mouse over the line, you see the actual Bezier curve control points. It is not intuitive.
18:45:42 <vhardy> shepazu: this is a lot of control points.
18:47:15 <vhardy> shepazu: you can see that if you add the proposal, the path is a lot simpler.
18:47:42 <vhardy> shepazu: I could use 'P' instead of 'R'
18:49:07 <vhardy> ... if you look at the Update 3 example, you can see a comparison of spiro curve and catmull-rom curve.
18:49:54 <vhardy> ... the catmul version just has a few more segments, but you have more control too. And I added line to segments.
18:50:08 <vhardy> heycam: are Spiro curves much more complicated.
18:50:46 <vhardy> shepazu: if you mouse over the curve, you see the spiro curve control points.
18:51:14 <vhardy> shepazu: spiro curves make very nice curves, slightly unpredictable. 
18:51:54 <vhardy> shepazu: the key essensece of catmull rom, all the points are on the curve. 
18:52:16 <vhardy> shepazu: there is also a tangent parameter which I ommited.
18:52:26 <heycam> ScribeNick: heycam
18:52:27 <heycam> Scribe: Cameron
18:52:43 <heycam> shepazu: I think it makes it harder to use with the tension parameter
18:52:45 <heycam> s/tangent/tension/
18:52:49 <heycam> s/ommited/omitted/
18:53:35 <heycam> ... I think authors would rather not think about that, and just want some smooth path through the points
18:53:51 <vhardy> ScribeNick: vhardy
18:54:19 <vhardy> shepazu: the tightest tension parameter makes line segments, the losest one make swoops.
18:55:23 <vhardy> shepazu: if you look at the "Awesomeness of SVG path Element" figure, you see how there is no line segment. If you want line segments
18:55:45 <vhardy> ... you can splt the Catmull-Rom command and add line commands.
18:56:06 <vhardy> ed: if you just want the points, why not add to polyline?
18:56:19 <vhardy> shepazu: because you may want to mix it with other path segments.
18:56:40 <vhardy> shepazu: I was currious if you needed extra parameters for each of the points.
18:56:59 <vhardy> shepazu: you might if you wanted to control the tightness per point. You would need three numbers per point.
18:57:11 <vhardy> ed: the syntax is easier to modify on polyline.
18:57:35 <vhardy> shepazu: this is really easy if you just want to use Catmull-Rom.
18:57:49 <vhardy> heycam: people have wanted 'point on a path' for a while.
18:58:00 <vhardy> heycam: my only concern is the default tension.
18:58:01 <ed> s/the syntax is easier/the syntax and SVG DOM is a bit easier/
18:58:22 <vhardy> shepazu: I chose a default tension, but we could wait for implementation feedback.
18:58:45 <vhardy> heycam: I am wondering if different kinds of paths would benefit from different tension parameters.
18:59:19 <vhardy> vhardy: I agree. I think it is fine to have a default for the tension, but we should have a way to control it.
18:59:22 <vhardy> (some agree).
19:00:15 <vhardy> tab: you could specify a tension in a command.
19:00:36 <vhardy> shepazu: you could have something like 
19:01:18 <ChrisL> ChrisL has joined #svg
19:01:36 <ChrisL> rrsagent,this eeting spans midnight
19:01:36 <RRSAgent> I'm logging. I don't understand 'this eeting spans midnight', ChrisL.  Try /msg RRSAgent help
19:01:47 <vhardy> ... P <tension> <list of points>
19:01:49 <ChrisL> rrsagent, this meeting spans midnight
19:01:55 <ChrisL> rrsagent, here
19:01:55 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T19-01-55
19:01:56 <vhardy> vhardy: but then it is not per point.
19:02:17 <vhardy> shepazu: if someone wants to implement it and provide suggestion for syntax, that would be fine.
19:02:46 <vhardy> heycam: none of the existing path commands have optional arguments, so we do not have a syntax for that, like a slash /
19:03:02 <vhardy> tab: I think we could go by fine with a default tension.
19:03:49 <vhardy> shepazu: you could have P t (x, y)+
19:03:57 <vhardy> vhardy: that is still for the whole curve.
19:04:04 <vhardy> shepazu: I think that is the most common case.
19:04:37 <anne> anne has joined #svg
19:04:43 <vhardy> shepazu: if you want to vary the tensions, you create different curves but you still have the issue at the connecting points where there is a different tension before and after.
19:05:42 <vhardy> shepazu: having an initial tension may be a [0, 1] parameter instead of the actual range in the Catmull Rom formulas.
19:07:51 <vhardy> RESOLUTION: we will add a Catmull Rom syntax to the path syntax with a tension parameter to control the whole curve (not per-point control).
19:08:20 <vhardy> ACTION: shepazu to make a Catmull Rom editor that takes variable tension parameters.
19:08:20 <trackbot> Created ACTION-3085 - Make a Catmull Rom editor that takes variable tension parameters. [on Doug Schepers - due 2011-08-04].
19:09:33 <ChrisL> zakim, code?
19:09:33 <Zakim> the conference code is hidden, ChrisL
19:10:03 <vhardy> shepazu: for the tension at the junction between P curves, we could have an optional end tension for the last point on the curve.
19:10:32 <vhardy> shepazu: P t (x, y)+ (t2)
19:10:52 <cyril> s/(t2)/(t2)?/
19:12:45 <Zakim> ok, shepazu; conference Team_(svg)19:12Z scheduled with code 26633 (CONF3) for 60 minutes until 2012Z
19:12:53 <vhardy> Capturing previous resolution.
19:13:13 <Zakim> Team_(svg)19:12Z has now started
19:13:20 <Zakim> + +1.206.675.aaaa
19:13:29 <vhardy> RESOLUTION: we will add a path rotation command.
19:13:43 <Zakim> +ChrisL
19:13:47 <ChrisL> q+
19:15:04 <vhardy> chrisl: how is this going to work in existing SVG 1.1 content.
19:15:19 <vhardy> chris: why not add a new element with these commands instead.
19:15:30 <vhardy> chrisl: what is the advantage of appending to the path command.
19:15:39 <vhardy> chrisl: I want to make sure that we considered this?
19:16:01 <vhardy> heycam: we had a discussion about this. 
19:16:22 <vhardy> ... if you want a reasonnable behavior on all implementation, you would use a <switch>/requiredFeature.
19:16:33 <vhardy> chrisl: I just wanted to make sure this was a concious decision.
19:16:40 <shepazu> q+
19:16:41 <vhardy> heycam: yes, it was a conscious decision.
19:17:29 <vhardy> heycam: a new element means that you get a marginal difference in the loss of functionality in ua that do not support the new behavior. And it would be confusing to authors to use different elements for different path commands.
19:18:10 <vhardy> chrisl: another element might still be easier/better. Have you considered it? We could also add NURBS.
19:18:54 <vhardy> chrisl: similarly for perspective transform, we would have something odd if some part of the curve can be subject to it (NURBS) and others not (Beziers).
19:19:19 <vhardy> shepazu: I had similar objections. We need to be ready to justify it.
19:19:35 <vhardy> shepazu: anything we add should be normalizable to SVG 1.1 syntax.
19:20:10 <vhardy> shepazu: we could provide utilities or algorightms for the conversion.
19:20:16 <vhardy> heycam: I think that is a good idea.
19:20:18 <jenyu> jenyu has joined #svg
19:20:53 <vhardy> chrisl: yes, and authoring tools could also offer that as an option and include a switch between the new and old syntax.
19:21:15 <vhardy> cyril: we did not talk about the verbosity aspect. Path commands are compact. Adding elements is move verbose.
19:22:06 <vhardy> heycam: I think there is still room for new path commands and the things you were suggesting.
19:22:47 <vhardy> chrisl: we need both the spec. and scripts providing the equivalence between the syntaxes (additions and old path syntax).
19:22:57 <vhardy> heycam: we have agreed to work on the SVG graphics API.
19:23:33 <vhardy> heycam: we did not discuss the switch for these new features.
19:23:38 <cyril> s/move verbose/more verbose/
19:24:06 <vhardy> shepazu summarizes the earlier discussion on <switch>
19:24:33 <vhardy> ed: there was no resolution on that issue.
19:26:00 <vhardy> cyril: the behavior of <audio> on switch is defined in SVGT 1.2 and we should port it to SVG 2.0.
19:26:29 <vhardy> heycam: what does display:none do for audio and video in HTML5?
19:26:37 <vhardy> anne: nothing. No effect.
19:27:08 <vhardy> tab: if you dont want it to play, you don't put it in the document.
19:28:26 <vhardy> (discussion on audio and video in HTML5).
19:30:12 <vhardy> LUNCH BREAK
19:31:58 <shepazu> action: shepazu to suggest audio-volume control properties to CSS WG
19:31:58 <trackbot> Created ACTION-3086 - Suggest audio-volume control properties to CSS WG [on Doug Schepers - due 2011-08-04].
19:32:40 <ed> http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty
19:32:53 <ed> ACTION-3086: http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty
19:32:53 <trackbot> ACTION-3086 Suggest audio-volume control properties to CSS WG notes added
19:33:08 <Zakim> -ChrisL
19:33:10 <ed> 1 hour
19:36:28 <Zakim> - +1.206.675.aaaa
19:36:29 <Zakim> Team_(svg)19:12Z has ended
19:36:30 <Zakim> Attendees were +1.206.675.aaaa, ChrisL
19:36:41 <shepazu> http://schepers.cc/svg/path/dotty.svg
19:38:54 <TabAtkins_> TabAtkins_ has joined #svg
19:46:53 <ed> http://www.imdb.com/title/tt0137523/quotes?qt=qt0479254 ?
20:06:40 <TabAtkins_> TabAtkins_ has joined #svg
20:47:07 <birtles> ScribeNick: birtles
20:47:30 <shepazu> Zakim, room for 3?
20:47:31 <Zakim> ok, shepazu; conference Team_(svg)20:47Z scheduled with code 26631 (CONF1) for 60 minutes until 2147Z
20:47:41 <anne> anne has joined #svg
20:47:54 <Zakim> Team_(svg)20:47Z has now started
20:48:01 <Zakim> + +1.206.675.aaaa
20:48:15 <birtles> Topic: Easier integration of HTML into SVG
20:48:19 <Zakim> +ChrisL
20:48:49 <birtles> TA: If we could abandon XML it would be really easy
20:48:59 <birtles> VH: I've done a write-up covering both directions
20:49:01 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
20:50:10 <anne> doug
20:50:40 <birtles> VH: The reason I bring this up is author convenience
20:50:44 <birtles> ... to match expectations
20:50:56 <birtles> ... I believe the issues we have can be fairly easily overcome
20:50:57 <ChrisL> q+
20:51:10 <birtles> ... this is pretty well implemented currently wrt to foreignObject
20:51:20 <birtles> ... the only the thing foreignObject does is provide an initial viewport
20:51:56 <birtles> ... in the last e.g. if you specify the containing block/viewport then that's all you need to apply the box model
20:52:06 <birtles> ... for the opposite direction (SVG in HTML)
20:52:35 <birtles> ... it's useful, e.g. to put a circle in a cell
20:52:42 <birtles> ... but it doesn't appear in the middle
20:53:05 <birtles> ... the gist of this here is to say if you have an SVG element that's not in an <svg> then it should follow regular HTML formatting, the box model
20:53:30 <birtles> ... in this example, if I had x/y it would be handled differently
20:53:46 <jenyu> jenyu has joined #svg
20:53:50 <birtles> ... if you have an SVG element which is not <svg> then it becomes part of the box model
20:53:53 <ChrisL> q?
20:54:11 <birtles> CM: rather than adding a new attribute on div can be just use left/height etc.?
20:54:27 <birtles> VH: I don't think you can because they will reference the nearest containing block
20:54:35 <birtles> CM: you want to values to be in SVG co-ordinate space
20:54:43 <birtles> ... so you can just interpret them as SVG would
20:55:08 <birtles> CL: that's why we have foreignObject
20:55:17 <birtles> ... to deal with that mapping
20:55:24 <birtles> AK: I think you need to keep it
20:55:30 <birtles> VH: I think you need to keep the handshake
20:55:53 <birtles> CL: It's defining two--the SVG space and the CSS canvas and mapping the two together
20:56:06 <birtles> VH: The first case, my proposal is to provide a shorthand for what foreignObject does
20:56:10 <birtles> ... it's just a matter of syntax
20:56:48 <cyril> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
20:56:51 <birtles> AK: If you want to introduce a new attribute you'd have to extend HTML as well
20:57:17 <ed> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#foreignobject
20:57:19 <birtles> VH: My real question is, I think it would be nice to have a shorthand
20:57:37 <birtles> ... it seems unnatural to me to have this kind of overhead
20:57:45 <birtles> ... I think it's very natural to want to integrate text into your graphics
20:57:50 <birtles> .... you should be able to do that simply
20:58:04 <birtles> CL: foreignObject also makes the content display
20:59:08 <ChrisL> because svg says that foreign namespace stuff mixed in is okay and does not display
20:59:09 <birtles> CM: it the past mixing SVG and HTML was a kind of extension feature but now its commonplace
20:59:20 <birtles> VH: The naming now seems inappropriate "foreign" object
21:00:06 <birtles> AK: you could add an "html" element in SVG
21:00:55 <birtles> CM: if you're going to do that, then you may as well drop the requirement for a container element
21:01:07 <birtles> TA: the reason we require the <svg> root in HTML is because of namespaces
21:01:18 <birtles> ... I suspect the same problem occurs in reverse
21:01:44 <birtles> CM: e.g. <font>
21:02:04 <birtles> AK: In the e.g. (in the doc) the <div> would end up in the SVG namespace
21:03:09 <ChrisL> so it sounds like te current html5 spec does it the right way and the namespaces come out the right way.
21:03:41 <ChrisL> if we added an html element in the svg namespace, as an alias of foreignObject, it would not work in html5
21:03:48 <birtles> AK: to escape from HTML you need <svg> or <math>, to escape <svg> you need <foreignObject>
21:04:09 <birtles> ... the problem is you need to establish a bounding box in SVG
21:04:20 <birtles> CM: so it's not a parser problem
21:04:24 <birtles> TA: it shouldn't be
21:04:32 <birtles> DS: Can html add x/y/width/height to the root?
21:04:50 <birtles> ... or use CSS to establish the viewport of the html
21:05:06 <birtles> VH: so instead of the containing-block attribute you use CSS
21:05:52 <birtles> ... so it's a new property for establishing the viewport, not just left/top
21:06:06 <birtles> ... you need to define which viewport you're going to define your element into
21:06:21 <birtles> ... you need the rectangular viewport you're going to put it into
21:07:00 <ChrisL> anne: if you had two divs following each other they would make two canvases
21:07:31 <birtles> CM: just use the top/left/width/height props to specify the SVG coordinate space for rendering the HTML
21:07:43 <birtles> ... and that's also the width/height of the CSS box
21:07:54 <birtles> ... need to consider interaction with max-width/height
21:08:02 <birtles> TA: I think you should be styling the box directly
21:09:01 <birtles> VH: one thing is to size the box, but foreignObject also defines which box you're going to layout into
21:09:43 <birtles> TA: we can just define how the absolute positioning model means in SVG
21:09:48 <birtles> ... what is the reference box there
21:10:09 <birtles> VH: even the static positioning, if I just have a div what does 100% mean?
21:10:24 <birtles> TA: we can assume it's absolutely positioned
21:10:44 <birtles> VH: the computed value of the position property would be static
21:11:10 <birtles> TA: svg|* > html|* { pos: abs }
21:11:41 <birtles> AK/CM: I don't think we need to force it to be absolute
21:11:49 <birtles> AK: but we have to define how width/height works
21:12:06 <birtles> VH: if you look for a CSS block in SVG it's only the <svg> element
21:12:30 <birtles> s/block/box/
21:13:05 <ChrisL> I think the problems introduced by removing fO are worse than the current situation
21:13:13 <birtles> AK: CSS requires a root element
21:13:22 <birtles> ... so it's difficult if e.g. you have two paragraphs
21:13:35 <birtles> CM: so you'd have to specify the behaviour
21:13:42 <birtles> AK: it's not been specified yet
21:14:54 <birtles> CL: I think it's a bad idea, I understand the motivation but I think it introduces more problems
21:15:12 <birtles> ... SVG has a lot of mention of the containing element, rootmost element etc.
21:15:25 <birtles> ... if you remove that you lose the definition of units and introduce all sorts of other problems
21:15:47 <birtles> ... yeah you have to type fO etc. but it all works
21:15:52 <birtles> ... both of these changes require the html parsing to change
21:15:56 <birtles> ... would introduce CSS problems
21:16:09 <birtles> ... I don't think it would work
21:16:39 <birtles> CM: we wouldn't half solve the problem, we'd have look at all the implications and tricky cases
21:16:48 <birtles> ... we just have to look at it carefully
21:17:25 <birtles> DS: what we have now works, but if we introduce different syntax there'll be a transition period where it won't work
21:17:39 <birtles> ... but people with SVG-capable browsers are generally only the latest version and getting updates
21:17:45 <birtles> s/only/on/
21:18:17 <birtles> ... if we're going to do this we should do it soon
21:18:35 <birtles> ... especially before new releases of IE (after version 8)
21:18:42 <birtles> ... 8
21:19:06 <birtles> VH: from a user's point of view
21:19:21 <birtles> ... if you want to do any business graphics, every time you want to do a paragraph of text you have to wrap it in fO
21:19:28 <birtles> ... and compare that with a single line of text
21:19:33 <birtles> ... which you can just drop in
21:20:16 <birtles> ... functionality-wise it's odd that we don't have this yet
21:20:26 <birtles> CM: it makes the platform look less cohesive that you have to do that
21:20:34 <birtles> ... presuming that parser changes are OK
21:20:52 <birtles> TA: switching over to using html directly should cause no problems
21:21:01 <birtles> ... it's symmetrical with what we do with svg in html
21:21:34 <birtles> ... people have been doing that for a long time
21:21:56 <birtles> DS: it wasn't that common, there were just a few obscure platforms
21:22:28 <birtles> TA: We can ask about that parser change from the point of the HTML parser
21:22:45 <birtles> AK: The proposal is to embed any html element
21:23:01 <birtles> TA: embedding svg/math in html is easy, we can control the size of it using things in those elements
21:23:09 <birtles> ... in the reverse situation we don't have that information
21:23:19 <birtles> ... because x/y aren't valid html attributes
21:23:53 <birtles> ... in the SVG case at the min. we'd need the HTML root to take x/y
21:24:24 <birtles> ... if you're within the SVG model you need to use the SVG positioning model for coherence
21:24:57 <birtles> ... We have 3 possibilities
21:25:01 <birtles> ... 1) keep fO
21:25:12 <birtles> ... 2) add x/y to html root or to all elements
21:25:20 <birtles> ... (we already have width/height)
21:25:43 <birtles> RC: we have CSS transforms
21:25:52 <ChrisL> yes, we already have width ad height *and they mean different things*
21:26:02 <birtles> TA: 3) cast SVG model in terms that CSS can manipulate
21:26:32 <birtles> VY: is the last one already in discussion for the purpose of animation
21:26:39 <birtles> TA: yes, that's in discussion
21:26:54 <birtles> VH: it might be interesting to investigate option (3) further
21:27:00 <birtles> DS: we can map that fairly easily
21:27:17 <birtles> TA: or just have x/y be CSS properties that would only be valid within the SVG positioning model
21:27:24 <birtles> ... like using grid properties within a grid
21:29:12 <birtles> ACTION: Erik to put on the FXTF agenda, discussion about HTML positioning in SVG and contact dbaron
21:29:12 <trackbot> Created ACTION-3087 - Put on the FXTF agenda, discussion about HTML positioning in SVG and contact dbaron [on Erik Dahlström - due 2011-08-04].
21:29:53 <birtles> ACTION: Vincent to illustrate the three options put forward by Tab in the SVG/HTML integration proposal
21:29:54 <trackbot> Created ACTION-3088 - Illustrate the three options put forward by Tab in the SVG/HTML integration proposal [on Vincent Hardy - due 2011-08-04].
21:30:19 <birtles> Moving onto the second part, SVG in HTML
21:30:45 <birtles> AK: the second part doesn't work with the parser
21:30:54 <birtles> TA: we tried to do it and it makes the parser too difficult
21:31:11 <birtles> VH: why was that
21:31:30 <birtles> TA: it has to do with keeping namespaces working correctly
21:31:37 <birtles> ... particularly wrt to XHTML/HTML compat
21:31:57 <birtles> ... that's why you need an svg/math root
21:32:30 <birtles> AK: we'd need to rev the html parser every time an SVG element is added
21:33:33 <birtles> DS: so a bare <svg> in HTML would do what?
21:33:44 <birtles> (some discussion about what the defaults are)
21:34:28 <birtles> DS: there are 3 cases where people want to make SVG content
21:34:40 <birtles> ... 1) where you want it to be fixed width/height
21:35:00 <birtles> ... 2) as with (1) but with stuff outside the viewport (still fixed size)
21:35:16 <birtles> ... 3) everything automatically scales to fit the content
21:35:26 <birtles> ... I think you get the most benefit from (3)
21:35:41 <birtles> ... auto-scaling SVG is the most beneficial SVG
21:35:54 <birtles> ... if you want it to be fixed width/height there are ways of doing that
21:36:02 <birtles> CM: but we don't have automatic viewport
21:36:18 <birtles> DS: If we just have "<svg>" that should be mean auto-scaling viewport
21:36:51 <birtles> ... i.e. = <svg vb="bounding box">
21:37:01 <ChrisL> tat is what we have already. if uou omit the viewbox then you get autoscaling
21:38:28 <birtles> CL: if you don't have a viewport and add content everything will scale down
21:39:19 <birtles> CM: I think what implementations do is compute 100% to a pixel size based on the size of the containing block of the SVG
21:39:34 <birtles> ... and then that number of pixels becomes the implicit viewBox width/height and starting at 0,0
21:39:59 <ChrisL> if that is the case, then current implementations dont give us doug's third case 9even thoygh that was the original intent)
21:40:06 <birtles> DS: my proposal is that a bare "<svg>" (no attr) takes the bbox of the content in +ve coordinate space
21:40:07 <ChrisL> s/9e/(e
21:40:38 <ChrisL> so you would only get first quadrant displaying?
21:40:59 <birtles> ... and auto-scale that
21:41:27 <birtles> (DS draws a circle with origin 0,0 and shows that only the lower-right quadrant would be shown)
21:41:36 <birtles> VY: that is problematic for text
21:41:54 <birtles> ... where if you don't specify 'y' it won't be visible
21:42:06 <birtles> DS: that's something the authors just have to figure out
21:42:33 <birtles> s/VY/JY/
21:43:24 <birtles> DS: then an alternative is just take the bounding-box
21:43:43 <birtles> CL: I don't think you don't need to restrict it to the positive quadrant
21:43:53 <birtles> DS: ok
21:43:54 <Zakim> -ChrisL
21:44:14 <ChrisL> zakim, code?
21:44:14 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ChrisL
21:44:17 <birtles> DS: so we take the bounding box of all the content
21:44:30 <Zakim> +ChrisL
21:45:02 <birtles> (DS draws a square with "TEXT" positioned at 0,0, i.e. above the top edge of the rect)
21:45:47 <birtles> CC: You're proposing different behaviour for the same syntax
21:45:56 <birtles> CM: I think the existing behaviour is useful
21:46:03 <birtles> DS: In those cases use the attributes
21:46:16 <birtles> CM: So you're keying the distinction off the presence/absence of the attributes
21:46:23 <cyril> CC: You're proposing to break compatibility
21:46:25 <birtles> DS: Yes
21:46:46 <birtles> ... and most content is produced by authoring tools that produce those attributes
21:46:58 <birtles> ... so I don't think we'd break compatbility
21:47:13 <birtles> ... this proposal matches authors' expectations
21:47:58 <birtles> ... I think this is the most intuitive behaviour
21:48:19 <ChrisL> that sounds god to me
21:48:25 <ChrisL> s/god/good/
21:49:00 <shepazu> 0:)
21:49:03 <birtles> VH: yes, in my proposal I was assuming this behaviour
21:49:11 <birtles> CC: I think it changes the way implementation works
21:49:27 <birtles> ... previously you would prepare the buffer beforehand
21:49:49 <birtles> ED: you already have that with the overflow property
21:50:27 <birtles> VH: I think it's unfortunate that the parser issues prevent us from including SVG elements directly
21:51:24 <birtles> ... so Doug you're talking about keeping a wrapper <svg> element but making it simpler
21:51:27 <birtles> DS: Yes
21:51:31 <birtles> ... it avoids the parser problem
21:51:43 <birtles> ... ensures we have only one SVG root
21:52:06 <birtles> ... which simplifies it
21:52:15 <birtles> ... if you have two circles (as per the document)
21:52:27 <birtles> ED: yeah what coordinate space do you use if you reference a gradient
21:52:59 <birtles> DS: If people don't realise that every time that include an SVG element they're creating a new viewbox you'll run into perf problems
21:53:23 <birtles> ... generally people don't want to use a single <circle> but something more complex
21:53:34 <birtles> ... so the cost of adding an <svg> root is not so great
21:53:39 <ChrisL> i agree
21:54:08 <ChrisL> <svg bboxtype="stroke">
21:54:13 <birtles> DS: we're going to have different bounding boxes (e.g. the current defn doesn't include stroke width)
21:54:38 <ChrisL> current bbox is purely geometric. it exclides stroke, markers and filters
21:55:18 <birtles> ... and the new bbox that includes everything would be the one we use for the autoScaling behaviour
21:55:30 <vhardy> s/exclide/exclude
21:57:19 <birtles> ... there are two options
21:57:32 <birtles> ... one simply sets the viewBox to include the content
21:57:53 <birtles> ... the other also then stretches the <svg> containing block to take as much room as is available
21:58:24 <birtles> ... in either case we want some simple behaviour for a bare "<svg>"
22:00:17 <birtles> VH: I agree it's less common to want to include a single SVG element in HTML than the other way around
22:00:47 <birtles> ... the new scaling behaviour is nice but not strictly necessary
22:01:28 <birtles> ... I withdraw my proposal to allow SVG elements in HTML without an svg root
22:01:35 <birtles> ... for the reasons we discussed
22:02:23 <birtles> (discussion about how the CSS overflow property got split into overflow-x/y)
22:06:51 <homata> homata has joined #svg
22:08:33 <birtles_> birtles_ has joined #svg
22:08:40 <birtles_> ACTION: Jen to propose auto viewBox sizing and SVG container box sizing for bare <svg> in HTML
22:08:40 <trackbot> Sorry, couldn't find user - Jen
22:08:51 <birtles_> ScribeNick: birtles_
22:09:26 <ChrisL> trackbot, status
22:09:36 <birtles> ACTION: Jennifer to propose auto viewBox sizing and SVG container box sizing for bare <svg> in HTML
22:09:37 <trackbot> Created ACTION-3089 - Propose auto viewBox sizing and SVG container box sizing for bare <svg> in HTML [on Jennifer Yu - due 2011-08-04].
22:09:49 <birtles> ScribeNick: birtles
22:10:06 <Zakim> -ChrisL
22:10:08 <ed> --- 15 minute break ---
22:15:06 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)20:47Z
22:15:10 <Zakim> Team_(svg)20:47Z has ended
22:15:11 <Zakim> Attendees were +1.206.675.aaaa, ChrisL
22:27:58 <shepazu> shepazu has joined #svg
22:29:01 <birtles_> birtles_ has joined #svg
22:30:25 <birtles_> birtles_ has joined #svg
22:33:28 <birtles> birtles has joined #svg
22:34:45 <cyril> Topic: Text layout
22:34:51 <cyril> Scribe: Cyril Concolato
22:34:55 <cyril> ScribeNick: cyril
22:34:57 <ChrisL> zakim, room for 3?
22:34:58 <Zakim> ok, ChrisL; conference Team_(svg)22:34Z scheduled with code 26633 (CONF3) for 60 minutes until 2334Z
22:35:15 <cyril> CM: text layout, positioning, anchoring, bidi ...
22:35:16 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout
22:35:30 <Zakim> Team_(svg)22:34Z has now started
22:35:37 <Zakim> +ChrisL
22:37:53 <Zakim> + +1.206.675.aaaa
22:38:35 <cyril> CM: going through my text layout proposal
22:38:56 <cyril> ... there are examples on the wiki, but no image, didn't have time to make snapshots
22:39:22 <cyril> ... the primary problem is that the x/y attributes on text elements are used for 2 purposes
22:39:29 <cyril> ... 1) as an anchor position
22:39:37 <cyril> ... 2) to position glyphs
22:39:47 <cyril> ... sometimes they can be in conflict
22:40:24 <cyril> ... for <text x="10 20 30">abc</text> if you have text-anchor=start and ltr text there is no conflict
22:40:36 <birtles_> birtles_ has joined #svg
22:41:27 <cyril> ... but if you have bidi text like <text x="10">ABCabc</text> with ABC rtl and abc ltr, what is the x for ?
22:41:59 <cyril> ... is it for the A or for the whole text chunk ?
22:42:21 <cyril> ... probably you don't want to do anchoring and positioning
22:42:35 <cyril> ... and if we separate we would not have this conflict
22:43:49 <cyril> VH: should we consider a solution for text and a solution for glyph
22:44:22 <cyril> CM: I think for glyph positioning we can use the previous proposal but for text positioning we cannot break the existing
22:44:46 <cyril> ... when it is ambiguous we could disable anchoring
22:45:11 <cyril> VM: if there is one value that is anchoring and multiple values is glyph positioning ?
22:45:13 <cyril> CM: yes
22:45:20 <cyril> VH: then what is the anchor ?
22:45:41 <cyril> CM: my proposal is that there is no shifting to do anchoring
22:46:03 <cyril> ED: you could do a middle thing to have each character centered 
22:46:11 <cyril> CM: it is not a use case I have considered 
22:46:36 <ed> s/middle thing/text-anchor=middle/
22:47:28 <cyril> BB: what happens when you're positioning text chunks instead of glyphs/characters
22:47:35 <vhardy> http://www.w3.org/TR/SVG/text.html#TextChunk
22:48:13 <cyril> CM: ligatures still work across chunks
22:49:52 <ChrisL> ok so basically the string of characters is laid out to a sequence of glyphs, including bidi reordering, then the eft or right edge of *that* is used for text anchoring
22:49:57 <ChrisL> cm: yes
22:50:07 <ChrisL> in that case i think this is a good proposal
22:50:11 <cyril> s/eft/left/
22:50:46 <ed> "Ligatures only occur when a set of characters which might map to a ligature are all in the same text chunk."
22:51:06 <cyril> CL: what happens if you have  tspans ?
22:51:18 <cyril> ... with two different colors ?
22:51:29 <ChrisL> ... and ligature formation
22:51:39 <cyril> ED: tspans would define a new text chunk
22:52:17 <cyril> CM: only if it has an x on the tspan
22:52:30 <ed> s/x/x or y attribute/
22:52:57 <cyril> CM: I don't really consider that in my proposal
22:53:29 <cyril> VH: the first issue and proposed solution is chunk, anchor and bidi
22:53:36 <cyril> ... is there anything else ?
22:53:50 <cyril> CM: that's the rationale I gave for the whole thing
22:54:26 <cyril> ... to distinguish between positioning and anchoring you use the number of values in x/y
22:54:39 <cyril> ED: what happens when you have 1 value in x and multiple values in y
22:55:17 <ed> s/ in y/ in a tspan child/
22:55:25 <cyril> <text><tspan x="10 20"> ab
22:55:45 <cyril> in this case there is no anchoring in my proposal
22:56:12 <cyril> CM: one problem with multi-line text  with text and tspans
22:56:23 <cyril> ... you wouldn't want bidi across those things 
22:58:43 <cyril> ... BB: could you illustrate the 2 cases with discontinuity: rtl/ltr
22:58:55 <cyril> s/... BB:/BB:/
23:01:02 <cyril> [CM illustrating on the board]
23:02:19 <cyril> CC: if you change the number of values in the attribute, you would have discontinuity in the rendering
23:02:28 <cyril> CM: that's a downside of the solution
23:03:38 <cyril> VH: no there would be continuity
23:03:53 <cyril> ED: anchoring is what people use
23:04:05 <cyril> VH: there are authoring tools that use it for positioning
23:04:22 <cyril> CM: the problem comes only for bidirectional text
23:04:31 <cyril> ... for purely rtl or ltr there is no problem
23:05:01 <ed> s/people use/most content uses/
23:06:34 <cyril> CM: there is another problem, when you don't supply enough values for bidi text, it's not clear where the remaining characters go
23:06:51 <cyril> <text x="10 20 30">ABcd
23:06:57 <cyril> ... where does the d go
23:07:12 <cyril> s/d go/d goes/
23:07:29 <cyril> ... if it's chunked you avoid this problem
23:08:42 <cyril> ... if you don't have chunking then you lay the text out, then you override the position of some glyphs and the remaining glyphs are not touched
23:09:06 <anne> anne has joined #svg
23:10:37 <cyril> VH: if the proper solution is to use glyph indexing, why not deprecating character-based positioning
23:12:24 <birtles> CM: I wrote a bunch of tests and everyone is doing it differently
23:14:07 <ChrisL> yes
23:14:09 <cyril> ED: I don't think implementations are so consistent with diacretic text
23:14:19 <ChrisL> why?
23:14:51 <ChrisL> ok
23:14:53 <ed> s/diacretic /diacritic /
23:15:18 <cyril> ED: so we should text this feature separately
23:15:32 <cyril> s/should text/should test/
23:16:20 <cyril> ED: ligature is not the same as diacritic mark
23:16:24 <ed> http://www.w3.org/TR/SVG11/text.html#CharactersAndGlyphs
23:16:29 <cyril> ED: it's refered to as a composite character
23:19:21 <cyril> VH: are we trying to fix 1.1 and produce an addendum or are we trying to define what we want for 2.0 ?
23:21:08 <cyril> CM: I just want some defined behavior for comibination of character-based glyph positioning, anchoring, ... but to have the glyph indexing 
23:21:40 <cyril> ... I want the problems resolved in a way that makes enough sense given the fact that we are using character-based positioning
23:22:03 <cyril> VH: we recognize that it's broken so people cannot use it properly
23:22:23 <ChrisL> whiteboard photo  http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0026/IMAG0034.jpg
23:22:41 <cyril> CM: I don't want that for simple cases that are interoperable, I don't want to disable certain features
23:23:34 <ChrisL> the ones with multiple xy are often from PDF to SVG conversion
23:24:14 <cyril> CM: Adobe would in the future move to glyph-indexing and positioning
23:24:20 <cyril> RC: yes probably
23:25:22 <cyril> CM: what I should do is condense that wiki page into a slide show of current spec contradictions and proposed solutions
23:25:30 <cyril> VH: I will ask feedback internally
23:26:02 <cyril> ED: you might want to look at I18n tests for bidi
23:26:15 <ed> s/for bidi/for bidi in svg/
23:27:10 <cyril> ACTION: heycam to produce a condensed description of the problems and solutions
23:27:10 <trackbot> Created ACTION-3090 - Produce a condensed description of the problems and solutions [on Cameron McCormack - due 2011-08-04].
23:27:58 <cyril> ACTION: heycam to upload the tests for complex text cases
23:27:58 <trackbot> Created ACTION-3091 - Upload the tests for complex text cases [on Cameron McCormack - due 2011-08-04].
23:31:02 <Zakim> -ChrisL
23:31:18 <cyril> CM: on the top of the wiki page, there are the 3 use cases that I want to preserver
23:31:25 <cyril> s/preserver/preserve/
23:37:54 <cyril> ED: yes
23:39:01 <cyril> ED: I'm not sure the current spec wording matches the implementations 
23:39:01 <Zakim> disconnecting the lone participant, +1.206.675.aaaa, in Team_(svg)22:34Z
23:39:04 <Zakim> Team_(svg)22:34Z has ended
23:39:05 <Zakim> Attendees were ChrisL, +1.206.675.aaaa
23:39:57 <cyril> CM: one aspect of the proposal was to add a value to text-anchor to turn off explicitly anchoring
23:40:06 <ed> s/ I'm not sure the current spec wording matches the implementations / I don't think the current spec wording matches the implementations exactly/
23:41:41 <ed> ED: in opera, the bidi reordering happens first, then the result is mapped to the given positions
23:42:37 <cyril> CM: when you have a long run of text rtl followed by a character ltr then the last two characters are separated by a large distance
23:43:26 <cyril> ... and if you don't have enough value in x/y then you may  consider the last two characters as a chunk and therefore the distance between them won't be as big
23:44:56 <cyril> Topic: Canvas in SVG
23:45:08 <cyril> BB: should we define a canvas element in SVG ?
23:45:39 <cyril> VH: we said we are going to put it on the agenda of an FX meeting
23:46:41 <cyril> AVK: if you go with the design where you get rid of the foreignObject, it does not make sense to define the canvas element in SVG
23:47:10 <cyril> CM: this might be a good argument for dropping foreignObject and allow the bare elements inside SVG
23:47:23 <cyril> ... it would be good for harmonization of audio, video, canvas ...
23:47:36 <cyril> VH: I agree
23:48:09 <cabanier> cabanier has joined #svg
23:48:35 <heycam> http://www.w3.org/Graphics/SVG/WG/track/issues/2417
23:48:52 <birtles_> birtles_ has joined #svg
23:49:00 <vhardy_> vhardy_ has joined #svg
23:50:58 <cyril> Topic: event attribute
23:51:33 <cyril> AVK: the IDL attribute is generic on the Element but SVG would have to define event handler content attribute
23:51:39 <cyril> CM: what is generic ?
23:51:58 <cyril> AVK: the bits about how functions are defined 
23:52:56 <cyril> AVK: DOM Core provides an interface that allows the SVG spec to say this is an event handler attribute
23:53:04 <cyril> ... and all the requirements follow from that
23:53:32 <cyril> ... for the entire list, it would be useful if SVG provides the delta compared to what HTML has
23:54:07 <cyril> CM: we don't want HTML and SVG both define onclick for example
23:55:30 <cyril> AVK: it would make sense to have the union of events between SVG and HTML in DOM Core
23:56:24 <cyril> ACTION: ed to collect the events from SVG as a delta with respect to HTML
23:56:24 <trackbot> Created ACTION-3092 - Collect the events from SVG as a delta with respect to HTML [on Erik Dahlström - due 2011-08-04].
23:56:40 <cyril> AVK: I would like to discuss also the event vs evt issue
23:57:30 <cyril> ... what we discussed was that there would be a single argument event passed to the function
23:57:35 <ed> that's ISSUE-2055
23:57:42 <ed> ISSUE-2055?
23:57:42 <trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- closed
23:57:42 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2055
23:57:56 <cyril> ... and that there would be a scoped variable with the same value called evt defined
23:58:08 <ed> ISSUE-2176?
23:58:08 <trackbot> ISSUE-2176 -- evt vs event Redux -- raised
23:58:08 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2176
00:02:40 <ed> http://www.w3.org/TR/SVGTiny12/script.html#HandlerElement
00:02:49 <ed> "The 'event' parameter shown above is an Event object corresponding to the event that has triggered the 'handler'. An 'evt' variable can be used instead of 'event' ('evt' is an alias to 'event')."
00:03:11 <anne> anne has joined #svg
00:04:14 <birtles_> birtles_ has joined #svg
00:05:58 <cyril> RESOLUTION: We decide to resolve ISSUE-2176 by introducing evt as an alias to event in event handlers
00:06:59 <cyril> ACTION: heycam to add a note to the SVG spec about ISSUE-2176
00:06:59 <trackbot> Created ACTION-3093 - Add a note to the SVG spec about ISSUE-2176 [on Cameron McCormack - due 2011-08-05].
00:14:59 <ed> [everyone looks over their open actions]
00:19:35 <vhardy> vhardy has joined #svg
00:22:11 <heycam> trackbot, close ACTION-3068
00:22:11 <trackbot> ACTION-3068 Investigate reference updates per Innovimax's comment closed
00:30:14 <heycam> RRSAgent, make minutes
00:30:14 <RRSAgent> I have made the request to generate http://www.w3.org/2011/07/27-svg-minutes.html heycam
00:31:00 <heycam> RRSAgent, pointer?
00:31:00 <RRSAgent> See http://www.w3.org/2011/07/27-svg-irc#T00-31-00