<trackbot> Date: 27 July 2011

<vhardy_> ScribeNick: vhardy

<vhardy_> heycam: Topic Glyph Selection

Glyph Selection

<vhardy_> cabanier: this is an issue that came up a couple months ago like SVG does not let you select particular glyphs.

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

<vhardy_> heycam: talking about encoding may be misleading.

<vhardy_> cabanier: with identity encoding, the code is an index pointing to a glyph.

<vhardy_> cabanier: so this is very specific to the font you pick. If the font is not available, it does not work.

<ChrisL> its glyph encoding, not character encoding

<vhardy_> heycam: so you are talking about having glyph indices instead of text characters.

<vhardy_> cabanier: yes, that gives you more access.

<vhardy_> birtles: what about accessibility?

<vhardy_> cabanier: in the PDF precedent, there is a mapping between the glyphs and the unicode characters.

<ChrisL> yeah the accessibility folks are going to love this. there is no access t the text.

<vhardy_> heycam: so you specify glyph id to unicode character mapping.

<ChrisL> and if we put it in an attribute then the I18n folks will shout, to. So it needs to be element content

<vhardy_> birtles: so for a user agent, you would have to have a mapping table.

<vhardy_> cabanier: yes.

<vhardy_> birtles: there is some work that John Dagget on variation selectors. is that relevant here.

<vhardy_> vhardy: are you talking about IVSes?

<ChrisL> http://www.w3.org/Talks/2010/ChrisLilley-SVG-LaCantine/cover.svg requires firefox 4+

<vhardy_> birtles: yes, but I was also thinking of specific properties to chose ligatures.

<vhardy_> birtles: would that be enough?

<vhardy_> chril: this is experimental syntax in FF.

<ChrisL> it uses vendor prefixes

<ChrisL> eg .dlig {font-size: 60px ; -moz-font-feature-settings: "dlig=1,ss01=1,case=1"; }

<vhardy_> vhardy: the requirement is to provide absolute control over the glyph selection and their positioning.

<vhardy_> heycam: do you have a proposal?

<vhardy_> cabanier: not yet. Would like to offer the same feature level as PDF.

<vhardy_> heycam: Example:

<vhardy_> .... <text x="10 20 30"><altGlyph xlink:href="#a">a</altGlyph>...</text>

<vhardy_> <altGlyphDef id="a"><glyphRef glyph-name="..." /> </altGlyphName>

<vhardy_> heycam: the altGlyph element allows you to select the specific glyph to use for a particular run of text.

<vhardy_> cabanier: wouldn't the text engine still try to do ligatures?

<vhardy_> heycam: yes, without altGlyph. Not with altGlyph.

<vhardy_> shepazu: with the current mechanisms, you can disable ligatures if you want to.

<vhardy_> cyril: what about glyph substitution?

<ChrisL> 6.5 Ligatures: the font-variant-ligatures property

<vhardy_> heycam: If you select a glyph, there is no substitution.

<ChrisL> http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop

<ChrisL> Value: normal | inherit | [ <common-lig-values> || <additional-lig-values> || <historical-lig-values> ]

<vhardy_> shepazu: if you wanted a particular shape, you could use a combiniation of markup and styling to achieve the effect.

<vhardy_> heycam: in the use case I presented, you want no layout at all.

<ChrisL> 6.9 Defining font specific alternates: the @font-feature-values rule

<vhardy_> shepazu: I do not see a collection of what we want on the wiki page. Are we sure we have the requirements clear?

<ChrisL> http://dev.w3.org/csswg/css3-fonts/#font-feature-values

<vhardy_> cabanier, heycam: yes.

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

<vhardy_> cyril: why not use shapes in that case?

<vhardy_> cabanier: you would lose accessibility.

<vhardy_> shepazu: you could use a graphic and a <title>

<vhardy_> vhardy: you also need a solution like this if you have a significant chunk of text. Having all path is verbose.

<vhardy_> shepazu: another use case is groovy text with interlocking shapes.

<vhardy_> stearns: yes, there are fonts that have the right combinations of glyphs, and you could select those easily.

<vhardy_> shepazu: show an example of "Groovy text" with intertwined glyphs.

<vhardy_> (discussion about whether the altGlyph could also reference a shape)

<vhardy_> heycam: 3 main things:

<vhardy_> .. 1. how you reference a glyph in a font

<vhardy_> by id and have that disable glyph selection.

<vhardy_> .. 2. positioning 'characters' instead of glyphs in the <text> element's x attribute

<vhardy_> .. 3. ability to have an altGlyph reference a shape.

<vhardy_> shepazu: if we had capability #3, people would use it.

<vhardy_> (discussion on text path and shape path).

<vhardy_> shepazu: there has not been proposal to get shapes as part of a text layout.

<vhardy_> vhardy: to get back to cabanier's proposal, I think we have:

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

<vhardy_> ... 2. there is a mechanism for positioning characters (x and y attributes) and that should be positioning glyphs.

<vhardy_> ... 3. If 1 and 2 are addressed, we need to see if the solution would be terse enough to be acceptable.

<vhardy_> shepazu: Here is an example for groovy text:

<vhardy_> <g x-advance=".." id="groovytext">

<vhardy_> <path .../>

<vhardy_> <path .../>

<vhardy_> </g>

<vhardy_> heycam: yes, it would make a solution simpler.

<vhardy_> shepazu: yes, and it would avoid the font coordinate orientation issue.

<vhardy_> (discussion about the text x/y positions and how they work with ligatures)

<vhardy_> heycam: for example if you have <text x="10 20 30">ffe<text>

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

<vhardy_> if there is no ligature for ff, the first f is at 10, the second at 20 and e at 30.

<vhardy_> birtles: jdaggett says we should talk about glyph clusters and not glyphs.

<vhardy_> stearns shows a hindic example where the cluster is made of multiple glyphs.

<ChrisL> sigh. I'm going to get dropped every 50 minutes

<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. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action01]

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

<vhardy_> ACTION-3073: Report on how this would work with the shaping process.

<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

<vhardy_> (discussion on character and glyph positioning).

<vhardy_> heycam: when altGlyphs are used we should allow the author to skip extraneous x/y values that are not used because of ligatures.

<vhardy_> ACTION: cabanier to work with vhardy and text experts on x/y positioning and altGlyphDef and altGlyph. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action02]

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

<vhardy_> vhardy: what is the support for altGlyph and altGlyphDef?

<vhardy_> ed: Opera and WebKit have support altGlyph for SVG fonts, but not altGlyph for Opentype fonts AFAIK.

<tbah> Call ended....

<vhardy_> heycam: we should be able to extend the syntax if needed.

<vhardy_> birtle: we also need to keep accessibility in mind in the new solution.

<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. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action03]

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

text warping

<vhardy_> heycam: tbah, can you summarize the issue.

<tbah> http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html

<vhardy_> tbah: this is following our last discussion on Israel's examples.

<vhardy_> tbah: you can see the limitations with wide characters and text stretch.

<vhardy_> tbah: I have looked at the different ways that InkScape can distort paths.

<vhardy_> tbah: the most interesting are the ones at the bottom.

<vhardy_> tbah: the ones done as envelope deformations.

<ChrisL> using Inkscape's Envelope Deformation LPE

<vhardy_> tbah: it uses for paths, top, bottom, left and right.

<vhardy_> tbah: InkScape keeps the original path.

<vhardy_> tbah: it shows the kind of things you could do.

<vhardy_> tbah: it works nicely.

<vhardy_> tbah: the algorithm does not preserve vertical lines

<vhardy_> tbah: the person that wrote this code for InkScape could modify to do whatever we want.

<vhardy_> tbah: it would be nice to do that without converting to a path.

<vhardy_> tbah: it would also be nice to use the base line of the text instead of the visual bounding box bottom edge

<vhardy_> heycam: question: none of the glyphs have descenders in the examples.

<ChrisL> base line and ascent as top and bottom paths

<vhardy_> tbah: if they had descenders, they would be shifted up.

<vhardy_> tbah: there is an example.

<vhardy_> (example with descender has 'Sample Text: Office')

<vhardy_> shepazu: this satisfies some of the Groovy text examples.

<vhardy_> shepazu: how hard is this to implement.

<vhardy_> tbah: the implementation is complicated, but it is pretty fast.

<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

<vhardy_> tbah: it subdivides the path into small chunks and then transforms them.

<vhardy_> chrisl: it would be better to transform the control points and avoid subdividing.

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

<vhardy_> heycam: I think you need to subdivide.

<vhardy_> chrisl: I do not agree you need to subdivide. It is one way, that is not the only.

<ChrisL> NURBs

<ChrisL> I notice that lib2geom also has nurrbs support

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

<vhardy_> tbah: lib2geom uses convertion to SBasis curves.

<vhardy_> tbah: InkScape uses these curves extensively.

<vhardy_> heycam: is it simpler to use text on a path and warping that v.s. 4 different paths on all sides.

<vhardy_> ... algorithmically simpler.

<vhardy_> tbah: I dont think it is necessarily simpler.

<ChrisL> lib2geom has an irc dump as documentation :)

<ChrisL> quote

<ChrisL> All of these operations are fast. For example, multiplication of two

<ChrisL> beziers by converting to s-basis form, multiplying and converting back

<ChrisL> takes roughly the same time as performing the bezier multiplication

<ChrisL> directly, and furthermore, subdivision and degree reduction are

<ChrisL> straightforward in this form.

<ChrisL> unquote

<heycam> yeah

<heycam> I would love to understand how those s-basis curves work :)

<heycam> and the conversion between them and beziers

<ChrisL> \cite{SanchezReyes1997,SanchezReyes2000,SanchezReyes2001,SanchezReyes2003,SanchezReyes2004}.

<ChrisL> the same library uses SBasic curves to do the union and difference operations

<tbah> I would doubt this would use much CPU as compared to some of the filters.

<heycam> heh

<heycam> maybe we can get gpu accelerated path warping

<tbah> The warped D in one of my examples has 33 nodes after warping compared to 30 before so converting

<tbah> to and from the s-basis form doesn't seem to add that many extra nodes.

<heycam> nice

<ChrisL> right. i would expect the node increase to be proportional to the degree f warping

<ChrisL> tha tis a bg difference froma pre-subdivide or pre-tesellation approach

<heycam> yeah, I agree

<TabAtkins__> ScribeNick: TabAtkins__

shepazu: What is the scope or place for this? SVG2, or a special module, or what?

tbah: Dunno.
... This started as a way of clarifying what to do with the "stretch" value.

vhardy_: What was israel asking for?

ed: First he was just asking for "stretch" to be clarified. As it went on, he moved to wanting a more expressive modle.

vhardy_: One possibility is to just give access to the text geometry, and let you do crazy things with the geometry yourself.
... Java2d had something similar, where it gave you the geometry of the text outline.

heycam: That's probably a good short step forward.
... We may want to consider building in some kind of functionality, though.
... I think that when people to textpath, they probably want glyphs to be stretched properly. Currently it's just often ugly.

vhardy_: In Tav's example, look at, frex, the "ribbon" example - it often looks better than the "snake" option.
... 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.

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.

heycam: The "snake" option is only transitioning the controlpoints, right?

tbah: Yes.

heycam: I'm not sure what we want to get out of this discussion today.

<vhardy_> Converting Bezier curves to NURBS: http://www.mactech.com/articles/develop/issue_25/schneider.html

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

tbah: For now, I suggest that horizontal lines be warped to match the shape of the path, specified in the current spec.

TabAtkins__: Current impls do "stretch" by transforming the glyph bounding box into a quad and doing a simple perspective transform, which is pretty ugly.

tbah: Israel's suggestion means that horizontal lines are transformed such that their tangent is always parallel to the path.
... Vertical positions would be the same distance from the path as they are the baseline.

heycam: Would that involve subdividing path segments?

TabAtkins__: Yes, it would imply that horizontal lines become curved lines.

vhardy_: [shows an example of how a perpendicular grid would be transformed, using those principles]

heycam: Is that the same as the "office text"-in-a-circle example?

vhardy_: Yes.

heycam: Ok, that's the result that I'd like.
... I'm slightly reluctant to put in spec requirements for things beyond basic graphics algorithms without saying how to do it.

vhardy_: Is Bob Hopegood still an IE in the group?

ChrisL: No, but we could ask him to rejoin.
... Cam, why are you reluctant?

heycam: Just reluctant to do so without explaining how to do it, so it's defined in the spec.

<ChrisL> I missed the "without saying how" part on the phone, hence my question

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.

<heycam> ChrisL, no problem

shepazu: They don't even need to join, if they just help explain it.
... We all agree though that step 1 is exposing the path data via some API.

heycam: I think that's reasonable to resolve on.

RESOLUTION: We will provide a way to get glyph path data via some API.

[some discussion about where this would live]

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.
... So I think there are a few different ways we could expose this information.
... Like something that just takes a font name and a character, or whatnot.

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.

vhardy_: In Java, if you ask for the glyph outline you get the non-hinted outline.

heycam: I'm happy to write a proposal for something simple.

cabanier: In some fonts you're not allowed to get the outlines.

heycam: I don't see any difference between exposing the bytes of the font and exposing the path.

[unminuted discussion about legal issues]

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.

<scribe> ACTION: heycam to come up with API proposal for exposing glyph path data. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action04]

<trackbot> Created ACTION-3076 - Come up with API proposal for exposing glyph path data. [on Cameron McCormack - due 2011-08-03].

heycam: It sounds like we also want some options to talk to people who know something about path warping algorithms.
... Like Bob or Israel, so they can help inform us as to whether we add that into the SVG spec.

<scribe> ACTION: vhardy to reach out to Bob Hopgood for information about path warping for text. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action05]

<trackbot> Created ACTION-3077 - Reach out to Bob Hopgood for information about path warping for text. [on Vincent Hardy - due 2011-08-03].

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.

vhardy_: We can ask - I think he has paths and does animation, but in these examples it's exported pre-computed.

<scribe> ACTION: heycam to contact Israel about path warping information. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action06]

<trackbot> Created ACTION-3078 - Contact Israel about path warping information. [on Cameron McCormack - due 2011-08-03].

ChrisL: What about the guy who does lib2geom?

heycam: Nathan Hurst
... I can contact him to ask him... something...

shepazu: Something important.

heycam: Perhaps he can explain what he does in a more explainable manner.

<scribe> ACTION: heycan to contact Nathan Hurst about lib2geom for information about path warping. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action07]

<trackbot> Sorry, couldn't find user - heycan

<scribe> ACTION: heycam to contact Nathan Hurst about lib2geom for information about path warping. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action08]

<trackbot> Created ACTION-3079 - Contact Nathan Hurst about lib2geom for information about path warping. [on Cameron McCormack - due 2011-08-03].

heycam: Tav, anything else?

tbah: No, that's it.

Event attributes in SVG2

ed: I think SVG2 should align with what HTML5 does wrt event attributes.
... Basically that would add all of the on* attributes to the svg attributes.
... And for any new events, they'd automatically get an on[event-name] attribute added to all relevant elements.

anne: The way HTML does it is that, for each element that's dispatched, there's a corresponding on* attribute.
... Currently they're exposed on window, document, and HTMLElement. Plus a few that are only exposed on specific objects, like XHR or WebSocket.
... But, frex, things that are dispatched on <video> can be caught higher by using the on* attribute.
... So I think SVG should follow the same path. Any attributes that are dispatched should be added to SVGElement.

<ChrisL> yes it would be better to pu them on Element and have HTMLElement SVGElement inherit

heycam: SVG doesn't have many novel events that aren't already exposed generally.

birtles: The SMIL events.

ed: SVG has a 'SVGRotate' event, too.

[vhardy reviews the list of SVG events]

<ChrisL> on[a-zA-Z-]*

heycam: Are there examples in HTML of element-based events being scoped?

anne: No, anything that dispatches on elements are available on HTMLElement, document, and window.

heycam: Maybe HTML could define a hook so that we can put these things on window, or we can just do it ourselves.

anne: You can use the new "partial" thing in WebIDL.
... There's some thought to define the hooks in DOMCore.

<br type=lunch-prep duration=5min>

heycam: We haven't moved to the on* being on Element yet; right now it's on HTMLElement.
... Should we wait for DOMCore to define them on Element, or put them on SVGElement.

anne: I think Moz already puts them on Element, and they said that the HTML events should move to match them.
... So I think if we move those we should move SVG events as well.

vhardy_: What's the status of that move?

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.
... But I think DOMCore could define some hooks that make it easy for other specs to define their events on Element.

vhardy_: What about the SVG-specific events? Should we ask the HTMLWG to add them?

anne: Sounds like a good idea.

heycam: Are there event listener attributes defined in HTML that aren't HTML-specific?

anne: Well, something like onscroll
... They could fire in a document with no HTML elements in them.

heycam: Okay, so sounds like everyone thinks this is a good idea (to have the events on Element).
... anne, any timescale?

anne: Haven't looked into it yet.

heycam: It's not an immediate concern, but.

anne: Probably in the next six months or so.

RESOLUTION: SVG2 will move all events to Element, in accordance with the similar move in HTML.

anne: If you could file a bug it would be easier to follow up on.

<scribe> ACTION: heycam to file a bug on DOMCore to remind Anne about the event move. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action09]

<trackbot> Created ACTION-3080 - File a bug on DOMCore to remind Anne about the event move. [on Cameron McCormack - due 2011-08-03].

image-rendering property and why Tab is redefining it

<heycam> Scribe: Cameron

http://dev.w3.org/csswg/css3-images/#image-rendering

<heycam> ScribeNick: heycam

TA: the pixelate value was added a week ago
... I've specifically defined optimizeSpeed and optimizeQuality as simply being equivalent to auto
... if your specific goal is high quality grphics, you do need the ability to control speed & quality
... in general in CSS, you specificalyl don't want to give authors control of this
... you want the browser to do the best it can
... if you let them make the choice, they will base their decision on their own machine
... whenever we offer features that let you make a performance sensitive choice, they do it based on their computer
... so the new values I've added to image-rendering are specifically intent based
... "this image should preserve certain features when resized/scaled"
... browsers are then free to use whatever algorithm they want to match the intent
... auto can drop down to nearest neighbour
... but when you have the resources, use bicubic
... chrome resizes in bilinear, then after a timer if no further resizes are done, redoes it with lancosz
... the other two svg defined values just map to auto
... crispEdges would be used for pixel art or diagram with straight edges, something that would look bad if the edges were blurred
... in the simple case, you can use nearest neighbour, but alternatives could be used
... pixellate I added, which means just embiggen the pixels

CM: what's the difference?

TA: pixellate would just do pixel scaling, crispEdges could use a different algorithm for pixel art scaling for example

DS: you might have an image editing program where you want to see big square pixels

CM: would we want to do something similar with the other properties, text-rendering etc.?

VH: should we add values to image-rendering rather than replace them?

TA: what intent is good to have for vector images?
... crispEdges and pixellate would be more useful for rasters
... if there are specific types of intents that we want for vector values, we could use those

VH: I think that's a good point, but it's a separate problem
... you're talking abotu a case when referenceing a vector image
... image-rendering is already used in SVG

TA: the way I'm using image-rendering is only for raster images

ED: that's how it's defined in SVG too

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

VH: I can see your point of view, but I would also like the original definition of image-rendering
... as an author I would like to have the four sets of values
... somethings you would like this to be fast, so if you're on a faster computer, that's fine use a high quality algorithm
... I'm more focused on the user experience than visual quality

PD: we came to the same conclusion about not supporting image-rendering
... you couldn't as an author determine what the end user's desire was
... at the same time I don't understand your two recommendations

TA: the various pixel scaling algorithms are used by emulators

JY: what would the test for that look like?

TA: I'm not sure this property is testable
... the only MUST in there is for upscaling with pixellate
... the rest are SHOULDs

VH: if I'm an author and I want an image that may want to be scaled, or printed for example
... for printing I'd probably want optimizeQuality, it may take time, but I'd want it to be printed high quality

TA: currently, the only time browsers use low quality algorithms is if there really is not enough time for the HQ algorithms
... otherwise, it assumes as high quality as it can provide
... the rendering intent you want doesn't seem to be useful
... I think the browser will do the highest quality in the time it can

VH: java2d lets you select particular algorihtms

TA: webgl exposes some levels of performance information, so you can decide things yourself
... with webgl you really need the game to decide to scale back its work
... with images, in practice, I don't think there's a problem
... with one of the IE demos there were lots of scaled logos moving around, using bilinear was still too slow
... but we could choose to use nearest neighbour to make it fast enough
... so what we do now, fast when it can be, I think is what you always want
... 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

VH: the one were you said it was too slow because it chose bilinear

CM: I would say that's just a bug

VH: I think we're making a choice of speed vs visual quality
... and you're saying we will degrade quality to increase speed
... they may prefer to have a slower animation

TA: so it's deciding between animation jank and quality

VH: what nags me a bit is saying we can decide what's best for the author

TA: I think in the vast majority of cases we can get and do make that decision correctly
... and I'm not sure the remaining cases are important enough that we need to give that sort of control to the author
... for example in the really high load flying images constant resizing, I think it's pretty clear you don't want janky animations
... they always look bad
... so I think the browser can make that decision and it will be right in the vast majority of cases
... in those tiny minority of cases where it really matters, it will much more often be misused
... and you would end up requiring an uglier experience

VH: with optimizeSpeed, if you had the bandwidth you could use the higher quality
... it doesn't mean use the fast path all the time
... it's a tradeoff
... 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
... 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

ED: the spec already says something like that
... if you can achieve the performance with HQ algorithms, just use that

BB: you also want particular algorithms sometimes

VH: so I like the additional settings, I'm not opposed to that
... this is just about the existing settings

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
... in that case, I could see optimizeSpeed having some value
... in all other cases it would be equivalent to auto

<ed> http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty

CM: I think that's what the existing definitions say
... that's not to say that's how they're implemented, but that's the intention of the spec

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.
... it means use the best you can, and if you can't get the best speed, use lower quality

VH: what about optimizeQuality?

TA: that's the same as auto

VH: don't think so, currently it says "at least as good as bilinear"

TA: I think that's a bad thing. animation jank is nearly always worse than lower quality.
... optimizeQuality preventing you from going below bilinear is a bug
... since framerate is a larger problem

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
... so you might want to use nearest neighbour for the sake of time, but the author may want a better quality

TA: the way hardware is these days, you could use lancosz for printing without a time problem
... 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
... 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
... in the future, we won't need to worry about optimizeSpeed either, because we will always be able to do HQ in time

DJ: I tend to agree with Tab
... I think the new keywords are the more improtant ones, the ones that guarantee "worse looking" images

VH: I'm ok with what you said, if you add optimizeSpeed
... I think it's easier to add values

TA: the old ones would just be aliased to auto

VH: oh, so alias optimizeQuality to auto
... and keep optimizeSpeed?

<ed> scribeNick: ed

SVG in Canvas

DS: currenlty you can use canvas in html, with the canvas element
... there's a set of things for which canvas is better than svg, and vice versa
... getPixelAtPoint

DJ: you have to getImageData and pull out pixels

TabAtkins__: in canvas you can get a pixel value, which isn't possible in svg
... [highlevel description of what canvas is]
... you can e.g do blur by manipulating pixels in the imagedata
... you can draw video to it, and you can pull binary blobs from it

CM: that's like the toDataURI but without the uri, right?

TabAtkins__: yes
... the WebGL context can do more things, like use shaders and so on

CP: hlsl could be abstracted out, canvas acts as a middle for svg, for html

vhardy_: you can draw svg to canvas, right?

TabAtkins__: yes, via image
... drawImage and pass in an svg

anne: passing in an svg element is not in the spec
... opera supports that

DS: that should be in the spec

CP: it works already via image element, which is specced

[a round of introduction, group welcomes Charles Pritchard to the session]

DS: i would like to use canvas in svg
... to e.g expose the canvas via the svg:image element

DJ: wouldn't it be better to have a canvas element in svg instead?
... you're duplicating an API
... it's the canvas context thatäs the verbose api
... you expose the getContext method on the image element, but that's a bit weird because you draw to it
... if you use the exact same element and API then that makes it easier

anne: presumably the html group could have done the same, but didn't

CP: there's also the getCSSCanvas
... works together with css
... only one set of width and height ...
... allows you to get scalable results
... it's manual with canvas
... but with getCSScanvascontext
... it's slightly different
... it's more managed
... in webkit you can buffer the drawing commands and replay them later
... you can use a set of bitmaps to get more scalable
... they're not managing multiple bitmaps
... works with css backgrounds

CM: not that familiar with the getCSSContext

TabAtkins__: mozilla can use moz-element to render any element into a background
... webkit has something that allows you to pull out a canvas context from a background

DJ: getCSSContext was a hack we wish we didn't put in
... we want to move to element()

DS: svg doesn't have backgrounds

TabAtkins__: svg has fills

DS: but it's not the same
... the svg root could have a background

vhardy_: svg tiny does have viewport-fill

DS: maybe we could allow backgrounds in svg
... and allow getting a canvas from the background

TabAtkins__: both produce the image as imagevalues, and you can fill something with a canvas

CM: so rect filled with some canvas content

vhardy_: for the paintservers?

TabAtkins__: via the element() syntax you could point to something like that

<circle fill="element(mycanvas)"/>

<canvas id="mycanvas">

vhardy_: how does this all work?
... so not the getCSSContext, but the element() syntax

TabAtkins__: right
... can refer to things outside of the document

vhardy_: by id?

TabAtkins__: yes

CP: is it the case now that you can use getCSSContext?

TabAtkins__: yes, but we want to move away from that

DS: so we could use a canvas to fill any shape in svg

vhardy_: the element syntax is implemented in firefox?

TabAtkins__: yes
... not all parts we discussed here
... need to add the syntax for the paintservers

DS: that's the kind of integration i'd like to see in svg

vhardy_: the other part is the canvas element in svg
... width and height are different in svg than in html

DS: they perhaps need to be resolved to pixels differently

TabAtkins__: you need the width and height to be the pixel dimensions

CM: you could rescale if the zoomfactor changes

vhardy_: what do you do if you zoom an html page with canvas?

CP: you listen for the resize event and redraw the canvas

DS: in svg you could just use currentScale

vhardy_: you have to detect that the canvas size changes, and set it

CP: yeah, just do that and set a scale transform

DJ: you may have to look at device pixel ratio

CP: yes, for devices, but on desktop it usualyl doesn't cahnge

CM: what happens when the svg transforms scale something that has a canvas element below?

DJ: the coordinate system in svg is independent
... you have to say how many pixels you want

CM: so the smallest size that looks nice at the transformed size

DJ: typically ppl means css pixels

CM: so authors should be in control?

DJ: well, you specifgy in user untis the size of the canvas element for layout in the svg
... but you delay creating the backing bitmap

CP: but what if several places uses the same canvas element, but with different scales?
... do you have to use separate canvas elements to get it without pixelizing the result?

CM: if you were animating a transform of a <g> containing a <canvas>, would you have to recreate the bitmap?

TabAtkins__: or you have to start out big so that it's scaled ok

CM: you keep the bitmap buffer around

vhardy_: right, but you might want to repaint if the size changes

CM: so you only want to know if the transform changes

vhardy_: canvas should be a same as anything else you draw
... so rasterize so that it looks ok

CM: you still need to redraw the canvas manually

DJ: if you pinchtozoom would you expect to recreate the canvas for each step?

vhardy_: just asking for a way to get notified when the scale changes

CP: css transitions has transitionend/start

DJ: by default when you draw something in svg you get optimal rendering
... except for a raster image, which has to be scaled
... wiuth canvas you can improve the visual output depending on scale

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

CP: requestAnimationFrame gives a hook where you can attach some handling

vhardy_: you could do that outside the repaint loop
... i think i can withdraw my proposal, maybe we have enough with the zoom and resize events

<vhardy_> ed: I am interested in having Canvas in SVG.

DS: interesting to drill down into detail, but i'm just looking at gaging the interest in having the functionality

<ChrisL> I'm in favour of havinga cavas element available in svg

<ChrisL> ... but have no special input beyond that

DJ: typically people don't run javascript int he middle of painting
... it's the using of javascript that updates the rendering
... bigger concern is if you have a loop of canvas in html drawing something svg with canvas (circular loop)

CP: that's just going to give a static bitmap

CC: what about export of svg rendered to the canvas?

TabAtkins__: most of the canvas drawing commands maps to svg
... but when you're manipulating pixels directly then it's not really possible

vhardy_: can you hook up a new context to the canvas element?

DS: there's been lots of experimenting with wrapping canvas and svg
... given a raster you can't go back to vectors

CP: recording commands is possible, but it's overhead
... but you're going to want a dom tree anyway
... svg is great for interop, and we use it for a few things

<shepazu> http://schepers.cc/w3c/svg/api/cog.svg

CP: but you want something with great svg import/export
... not script hacks

DS: svg's dom api sucks

<TabAtkins__> https://wiki.mozilla.org/SVG:Language:Regrets

<jwatt> hey, that's my secret page

<TabAtkins__> NOT SO SECRET ANYMORE

<jwatt> apparently

<dino> wow. I have many more regrets about SVG than jwatt.

<dino> i would not know where to start :)

<jwatt> there's only so many I had time to write down

<jwatt> :)

<TabAtkins__> https://docs.google.com/a/google.com/document/edit?id=1WYzbMkC_Q1pi6HyMNu4p6XevqXtGEHvmRjEZZemR6r8&hl=en&pli=1#

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

CP: js libraries do provide you with that

vhardy_: you need svg and canvas for different use-cases
... trying to merge the two is a good thing though

TabAtkins__: the svg dom is clumsy to work with

DS: and less intuitive than the canvas API

CM: right, so using DOM core methods that's too much work

CP: i like innerHTML

DS: there are script libs that allow you to do some things easier
... but having a shared language for creating the shapes and so on is good

CM: you want to be able to use currentFill=blah, and fillRect and so on and that it generates svg

vhardy_: but it can be hard to make that preserve structure

DS: we need to look at both, but unify gradients

vhardy_: there were some proposals for svg2 dom
... like inline json for example

<TabAtkins__> TabAtkins__: Some examples from a doc (unfortunately private) for a better drawing API for SVG:

<TabAtkins__> var font = root.font(”DroidSans”, [”DroidSans.ttf”, “DroidSans.swf”],

<TabAtkins__> {fontWeight: ‘bold’, fontStyle: ‘normal’});

<TabAtkins__> root.linearGradient(”myGradient”, “-blue-green”);

<TabAtkins__> var group = root.group();

<TabAtkins__> var rect = group.rect(20, 20, 300, 300, {fill: “id(#myGradient)”});

<TabAtkins__> var text = group.text(30, 40, “Hello World!”,

<TabAtkins__> {fontFamily: “DroidSans”});

<TabAtkins__> group.translate(-5, -5)

<TabAtkins__> .scale(1.5, 1.5)

<TabAtkins__> .animate({x: 200, opacity: 0.2}, 2000);

DS: don't want to remove the ability to get good structued svg files, with the new api

CP: you probably want to use svg, and use drawImage instead

CM: robert was in favor of doing something like that
... there are some immiate mode apis that allow you to do groups
... we could have that

vhardy_: as in the example shown above from tab

CP: inkml is the only format i've seen that has a streaming mode and an archived mode
... you can flatten the strucutre

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API

CP: pdf has streaming capabilites
... but improving the flexibility is good
... we want to preserve the vectors

DS: dropped in link, different from tabs exmaple

<vhardy_> vhardy: talking about variations, I like things like:

CM: are there any plans of improving DOM core to make it easier to create elements and attributes

<vhardy_> var rect = group.append({tag: 'rect', x: 10, y: 20, fill: 'blue'});

anne: haven't heard any suggestions yet

CM: so ppl aren't complaining?

anne: not enough
... only suggesting i've heard is like "new HTMLElement"
... not a lot of requests on the mailinglists

<wi> hola

anne: there's innerHTML

CM: shouldn't we try to improve the base platform?

<wi> alguien desea platicar?

anne: does jquery have the sort of thing you're asking about?

CM: yes

anne: wondering about hte vconvinence methods they have

TabAtkins__: jquery just wraps up innerhtml

anne: that's being specified

vhardy_: the proposed syntax is json, i prefer that syntax over innerhtml

CM: like taking a bag of arguments

<vhardy_> Summary of issues for SVG and Canvas integration:

<vhardy_> 1. <canvas> in SVG

DS: todataURI in svg is somethign i want, and getimagedata

<vhardy_> 2. SVG in 2D context's drawImage

<vhardy_> 3. CSS image values as SVG paint servers

<vhardy_> 4. SVG export from Canvas

<vhardy_> 5. SVG export to Canvas

CM: so just a convience function, to avoid having to paint svg to canvas and pulling pixels/datauri out from that

CP: if canvas is a requirement of SVG2 then you can do many of these thigns

DS: would like to see canvas as a firstclass element in svg

brian: so foreignObject?

anne: you could replace that with onlu <html> sort of like <svg> works in html5

vhardy_: let's go through the list above

6. toDataURL

7. getImageData

CM: so first point?

vhardy_: we need to resolve the width/height issue

CM: just doing the same as <image> should work

brian: so why do we need this without the foreignObject?

ISSUE: <canvas> element in SVG

<trackbot> Created ISSUE-2417 - <canvas> element in SVG ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2417/edit .

CM: next one, SVG in 2d context's drawImage

vhardy_: anne, drawImage doesn't mandate support for svg?

anne: right

DS: just needs to be mentioned in the spec

anne: you can pass in video, canvas and image elements in drawImage

vhardy_: we should request to be able to render an svg elements

TabAtkins__: there are some security concerns, like foreignObject

CP: to be able to draw an svg path directly to a canvas would be nice

anne: there are many things that can be external in svg, and that can taint the canvas

DS: the svg integration spec is meant to cover some of that

TabAtkins__: we could probably find a good way to do this, by disabling some things

vhardy_: if you could paint an svgsvgelemnent to a canvas
... you could create a datauri of the subtree and pass that via the drawImage call, so it's a workaround
... as an image.src

CP: taking a snapshot of an animated svg and creating a raster

s/6. toDataURL/6. toDataURL and toBlob/

ISSUE: SVG in 2D context's drawImage

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

CM: so point 4

vhardy_: many libs allow this
... you can ask for the svg output

TabAtkins__: so let jslibs handle this

8. new API to construct svg trees

CM: so point 5
... SVG export to canvas

DS: this would tak e some arbitrary svg and spit out the corresponding canvas javascript commands to do that

vhardy_: could be done in a library

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

<scribe> ACTION: Tab to work with charles pritchard to propose a canvas function that uses svg paths [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action10]

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

CM: point 6: toDataURL and toBlob
... not sure if it meant to generate a png

DS: yes, that's what I meant

DJ: toDataURL takes a param for what you want back

DS: the one i'm most interested in is the rasters

CM: would have the same security concerns as drawing svg to a canvas

DS: there are ways around that

CP: 6 and 7 have the same concerns

vhardy_: anne, would it make sense to add capabilty to canvas to draw a string?

anne: what do you mean with string?

vhardy_: a serialized document

TabAtkins__: you could use a crippled security context
... like for img elements

anne: it seems better to pass the element

vhardy_: i have a snippet of svg i want to draw in canvas
... don't want ot have to base64 encode it

anne: two separate things, you could use innerHTML
... vincent said it was not related to tainting?

CM: the only reaosn why your'e serailing is to be able t get it into the canvas

anne: if it's a separate file you could aslo use an iframe

CM: so have someone investigate how to get toDatauRL and pixels back
... and the security concerns

anne: so for foreignObject that would taint the svg

ISSUE: Investigate how to get pixel data out of svg subtrees securely

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

<scribe> ACTION: heycam to investigate ISSUE-2419 [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action11]

<trackbot> Created ACTION-3082 - Investigate ISSUE-2419 [on Cameron McCormack - due 2011-08-03].

CM: 8. New API to construct svg trees

CP: would be nice to have ArrayBuffer in svg and canvas API's, very efficient for gpus
... avoids string serialinzg data
... necessary for drawing fast

<scribe> ACTION: doug to propose a new API for constructing svg trees [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action12]

<trackbot> Created ACTION-3083 - Propose a new API for constructing svg trees [on Doug Schepers - due 2011-08-03].

--- 15 minute break

SVG Accessibility

<TabAtkins__> shepazu: Two aspects to this.

<TabAtkins__> shepazu: One, should we push for SVG being leverage for Canvas accessibility?

<TabAtkins__> shepazu: Two, how can SVG be made more accessible?

<TabAtkins__> shepazu: I have a plan going forward for the latter.

<TabAtkins__> pritchard: In about 2009, people started asking for a11y in canvas.

<TabAtkins__> pritchard: In both SVG and Canvas, shapes are used; it's not text and a box model.

<TabAtkins__> pritchard: Richard Sch and I started looking into this.

<TabAtkins__> pritchard: I found several issues by trying to implement HTML forms in Canvas, and found many different things.

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

<TabAtkins__> pritchard: On the iphone, you can drag your finger around and it can find bounding boxes and read them to you.

<TabAtkins__> pritchard: But triangles? Not so much.

<TabAtkins__> pritchard: So with ARIA you can specify the "role" of something to an AT.

<TabAtkins__> pritchard: So, how does ARIA work with SVG and Canvas?

<TabAtkins__> pritchard: ARIA initially didn't take SVG into account.

<TabAtkins__> pritchard: Though they'll do more work with this in the future.

<TabAtkins__> pritchard: Canvas gets a lot of AT stuff for free with the hidden subtree; it can contain buttons, frex.

<TabAtkins__> pritchard: [explains the canvas subtree]

<TabAtkins__> pritchard: [explains the ability to draw focus rings based on whether a specified element in the subtree is focused]

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

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

<TabAtkins__> shepazu: [draws a pie chart]

<TabAtkins__> s/pie chart/radial menu/

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

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

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

<TabAtkins__> pritchard: You can either link the focus-area to the appropriate <option>, or do something different like a list of links.

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

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

<TabAtkins__> vhardy: Can you disable the UA's normal rendering here?

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

<TabAtkins__> pritchard: [something about caret]

<TabAtkins__> [Doug is interested in exploring the idea of ARIA and carets]

<TabAtkins__> heycam: If you're doing a custom widget in windows, you can report the caret location, right?

<TabAtkins__> mattmay: Yes.

<TabAtkins__> heycam: So it seems like that's something you'd want to do with canvas as well, right?

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

<TabAtkins__> pritchard: So we proposed setCaretPosition

<TabAtkins__> pritchard: And Ian suggested ScrollPathIntoView

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

<TabAtkins__> shepazu: So, let's not drill down this far into Canvas a11y.

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

<TabAtkins__> pritchard: So, for example, enumerating the selectable elements so you can move through them. You need to know this *before* focusing them.

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

<TabAtkins__> pritchard: Canvas lacks the ability to talk about active regions ahead of time.

<TabAtkins__> pritchard: SVG has an opposite problem - it has a ton of paths, and we don't necessarily need all of them.

<TabAtkins__> heycam: Basically the set of things you want to report are the same as the set of focusable things?

<TabAtkins__> pritchard: Basically, yeah.

<TabAtkins__> shepazu: In Tiny 1.2 we introduced a @focusable attribute, which was meant to be for things like this.

<TabAtkins__> pritchard: [talk about using SVG and ARIA to create a checkbox and lable]

<TabAtkins__> mattmay: [talk about the difference between "virtual cursor" and "form" modes in ATs]

<TabAtkins__> ISSUE: Looks at @focusable in context of text and a11y

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

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

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

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

<TabAtkins__> pritchard: My main thing I found with SVG was that it's not quite as hierarchical as HTML.

<TabAtkins__> heycam: aria-flow-to sounds pretty interesting to use here too.

<TabAtkins__> mattmay: flow-to affects tab order, not reading order (order of the virtual cursor).

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

<TabAtkins__> shepazu: My "connectors" stuff was about that.

<TabAtkins__> pritchard: flow-to changes the reading order in some circumstances.

<TabAtkins__> shepazu: What other things does canvas have for a11y?

<TabAtkins__> pritchard: Juts ARIA stuff.

<TabAtkins__> pritchard: You may want to use things for various profiles. OpenClipArt is all very presentational documents, frex.

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

<TabAtkins__> pritchard: [gives an example of how you might want a different path than the visual representation in SVG for focusing/activating AT behavior]

<TabAtkins__> shepazu: Then I think Rich got into something weird with hit testing.

<TabAtkins__> pritchard: Rich thought we could combine setClickableRegion and hit-testing, such that the browser can automatically route clicks around.

<TabAtkins__> [explanation of how that could work potentially]

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

<TabAtkins__> pritchard: Yes.

<TabAtkins__> heycam: So you'd have to listen to mousedown on the particular element.

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

<TabAtkins__> shepazu: But where does this end?

<TabAtkins__> pritchard: It seems like this is the end. Based on the OS AT APIs so far, these fill in all the information necessary.

<TabAtkins__> pritchard: We have focus position, caret position, and clickable regions. That's as far as all the ATs go anyway.

<TabAtkins__> heycam: These seem more reasonable than the permathread suggests.

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

<TabAtkins__> shepazu: The final part of the story imo is that two browser vendors have come forward and said "no".

<TabAtkins__> pritchard: We're working on this. We've been talking with Apple, and with Jonas Sicking from Moz.

<TabAtkins__> pritchard: And MS has certain high AT standards in their products that make them potentially interested.

<TabAtkins__> pritchard: Also I've been working with Apple and Voiceover to fix their handling of Canvas.

<TabAtkins__> shepazu: So I think what you wanted in SVG was a method to bind an element to the path.

<TabAtkins__> shepazu: And my suggestion was, why not just have an SVG element (with ARIA) that simply carries the semantics.

<TabAtkins__> shepazu: The other is the above, but drawing the SVG shape into the canvas.

<TabAtkins__> shepazu: So why not use SVG?

<TabAtkins__> pritchard: Cost. It's expensive to serialize paths.

<TabAtkins__> TabAtkins__: He suggested drawing with SVG instead, with a linkage to the represented element.

<TabAtkins__> pritchard: That works, but it doesn't fix canvas accessibliity.

<TabAtkins__> shepazu: No, it fixes platform image accessibility.

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

<TabAtkins__> shepazu: So if you animate the pie chart in canvas, don't you also have to update the clickable region?

<TabAtkins__> pritchard: Yes, but given the shape of the proposed APIs, you'd just reuse the path that you're using to draw anyway.

<TabAtkins__> ISSUE: Contact platform a11y api people about non-rectangular path regions.

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

<TabAtkins__> mattmay: Adobe likes non-rectangular paths.

<TabAtkins__> pritchard: If you put <canvas> into SVG, and you put a button into there, how do you use the subtree in SVG?

<TabAtkins__> shepazu: Increasingly, SVG is being used in HTML too.

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

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

<TabAtkins__> pritchard: Great internal policy, but in the web, there are already many cases where people use canvas for inappropriate things.

<TabAtkins__> pritchard: Also, some of these subjects are relevant directly to SVG.

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

<TabAtkins__> pritchard: Like describing a region of a radial manu as a button.

<TabAtkins__> s/manu/menu/

<TabAtkins__> shepazu: I've done that with SVG and buttons already.

<TabAtkins__> pritchard: And we'll be reviewing more parts of ARIA/etc to see what's missing in SVG.

<TabAtkins__> shepazu: So you say you're making progress with the vendors; seems there's not too much for us to do?

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

<TabAtkins__> shepazu: Yes, and that's what I want to talk about.

<TabAtkins__> shepazu: There's two things I plan to do in SVG2.

<TabAtkins__> shepazu: One is, make an ontology of infographics (document navigation paths, etc)

<TabAtkins__> shepazu: Assessment techniques one uses when looking at infographics, and annotate them.

<TabAtkins__> pritchard: And for things like pie charts, <table>s are a great retained version of data that could potentially work here with SVG.

<TabAtkins__> mattmay: SAS has a demo involving tactile feedback of interactive graphics.

<shepazu> http://schepers.cc/svg/accessibility/

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

<TabAtkins__> shepazu: (There's a problem that ARIA doesn't expose role=column. WAI-ARIA rejected my feedback to add that earlier.)

<TabAtkins__> shepazu: One, setting up roles and attributes for infographics (for SVg, canvas, flash, etc.)

<TabAtkins__> shepazu: Two, start talking to AT vendors about expanding the platform APIs for a11y

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

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

<TabAtkins__> shepazu: That's basically my plan anyway.

<TabAtkins__> heycam: For things like Excel, how are charts exposed to AT APIs? They must do something already.

<TabAtkins__> mattmay: Dunno for sure.

<TabAtkins__> mattmay: All of that work is custom between Office.

<TabAtkins__> mattmay: It's not a model I'd want to follow.

<TabAtkins__> mattmay: But if you create a model that would support it, I'm sure they'd be glad to follow.

<shepazu> http://www.w3.org/TR/html-aapi/

<TabAtkins__> shepazu: The second thing I want to do in SVG2 is produce an analog of this guide for SVG.

<TabAtkins__> heycam: This is the default roles you get if you don't use ARIA. We should definitely have this.

<TabAtkins__> shepazu: So those are the two things I want to do in SVG2 for a11y.

<TabAtkins__> shepazu: I've already started on the API mapping.

<TabAtkins__> shepazu: Do we feel we need any kind of resolution on the canvas api stuff?

<TabAtkins__> heycam: I think the kinds of things Charles proposed isn't really needed in SVG.

<TabAtkins__> pritchard: Right - you already have most of this.

<TabAtkins__> heycam: But if you have canvas in SVG, whatever gets decided for HTML would get handled just fine.

<TabAtkins__> heycam: I think we should maybe integrate editable text with canvas.

<TabAtkins__> pritchard: [something about shape-wrap]

<TabAtkins__> mattmay: There's precedent for creating an overlay/underlay of live areas. Like PDF.

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

<TabAtkins__> mattmay: So selecting the text or whatever would map down into the subtree.

<shepazu> here are some issues raised by Rich Schwerdtfeger on SVG accessibility http://www.w3.org/Graphics/SVG/WG/wiki/Accessibility_Issues

<jwatt> talking to ghosts, Zakim?

<jwatt> heycam?

<heycam> hi jwatt

<jwatt> hi

<jwatt> if I remove xhtml1-transitional+edit.dtd I get

<jwatt> Recoverable error on line 114 of publish.xsl:

<jwatt> FODC0002: java.io.FileNotFoundException:

<jwatt> svg2/master/xhtml1-transitional+edit.dtd (No such file or directory)

<jwatt> when trying to run the "Build chapters" section

<jwatt> is fixing that just a case of changing the doctype declarations in all the chapters?

<jwatt> or is there something else I should know about?

<jwatt> or should I really keep that file?

<jwatt> seems like we should just use the html 5 doctype now, no?

<heycam> it would be good if it could be done without

<heycam> I don't remember the particular reason I included it to get things working

<jwatt> oh

<heycam> but yes, if we can just the HTML5 doctype, that would be great

<jwatt> hm

<jwatt> there was a reason

<heycam> if it doesn't break things

<jwatt> sucks :)

<heycam> perhaps it was that some files used HTML entities?

<heycam> (like &nbsp;) and saxon thus wanted to fetch the DTD to expand them?

<jwatt> would make sense

<jwatt> ok, I guess I just have to keep playing

<jwatt> thanks

<heycam> ok, no problem

<heycam> I will be awake for another half hour or so, if you have more questions before I head off

<jwatt> ok, thanks

<jwatt> dunno how much longer I can stay awake

<heycam> ok

<heycam> oh wow have you been up all night?

<jwatt> yeah

<jwatt> need. to. finish.

<heycam> :(

<jwatt> heycam: is svg.idlx only a build artifact?

<jwatt> or is it something we want to publish?

<heycam> yes

<heycam> no

<jwatt> cool

<jwatt> ta

<jwatt> ah, crap

<jwatt> it wants the .mod files in DTD too

<jwatt> need to get rid of svgdtd.html too I guess

<heycam> kill kill kill

<jwatt> master/publish.xml dies

<jwatt> err

<jwatt> just the svgdtd bit :)

<heycam> whew

<jwatt> heycam:

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

<jwatt> run from /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/svg2/

<jwatt> that puts its output in /Users/jwatt/websites/svgwg/svgwg.org/hg-sandbox/jwatt/publish/

<jwatt> what the heck?!

<heycam> hmm

<heycam> does it perhaps use the cwd to work out where to create the publish/ directory?

<heycam> (i.e. it wants to be run with .../master/ as the cwd?)

<jwatt> that's not what your perl version of build.pl does

<jwatt> oh

<jwatt> wait

<jwatt> hmm

<jwatt> yeah

<jwatt> it does run in master

<jwatt> so there must be something hardcoded somewhere in one of the files

<heycam> not impossible!

<jwatt> <output use-pe-publish-directory='true'/>

<jwatt> in publish.xml

<jwatt> hmm I recall reading about a second attribute somewhere

<heycam> lemme pull from the repo and take a look

<heycam> url again?

<jwatt> publish-directory=

<jwatt> sweet

<jwatt> (assuming it works)

<jwatt> it's not online

<heycam> ok

<jwatt> yet

<jwatt> got it

<jwatt> next!

<jwatt> so glad I did the porting of your script with you when I did!

<heycam> woo

<jwatt> very next line is busted :)

<jwatt> a pretty close next

<jwatt> heycam: my $chaptersNoIndex = join(' ', @all[1..$#all]);

<heycam> yeah...

<jwatt> that means all the items in the array except the first one?

<heycam> yep

<jwatt> ok

<heycam> in a string, joined with a space

<jwatt> that makes more sense

<jwatt> build.py gets all but the last one by mistake

<jwatt> oops

<heycam> :)

<jwatt> ok, I /think/ I'm pretty much through this

<jwatt> just a bit of cleanup and then a lot of testing

<heycam> yay

<jwatt> omg, I have a single-page.html!

<heycam> !!

<jwatt> right, now to take a real careful look at the diff between the rejigged system and the old system

<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

<jwatt> heycam:

<jwatt> +++ build/publish/types.html 2011-07-28 09:10:53.000000000 +0100

<jwatt> @@ -2,7 +2,7 @@

<jwatt> Scalable Vector Graphics (SVG) 1.1 (Second Edition)

<jwatt> Chapter 4: Basic Data Types and Interfaces

<jwatt> - $Id: types.html,v 1.99 2011/07/22 05:00:21 cmccorma Exp $

<jwatt> + $Id: 27-svg-minutes.html,v 1.2 2011/07/29 00:30:22 swick Exp $

<jwatt> Note: This document is generated from ../master/types.html.

<jwatt> Run "make" from ../master/ to regenerate it.

<jwatt> if you're still about, any idea why that's happening?

<heycam> it'll be cvs keyword expansion, yeah?

<jwatt> ahhh

<heycam> i.e., such things don't exist in hg probably?

<jwatt> no idea

<jwatt> ok, I'll ignore that :)

<jwatt> thanks

<heycam> cool

<heycam> ok, talk to you tomorrow

<jwatt> sleep well!

<heycam> you too ;)

trackbot, start telcon

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 28 July 2011

<scribe> meeting: SVG WG Seattle F2F

<scribe> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Starting SVG 2

<jwatt> ah

<jwatt> err

<jwatt> should be on in roughly 60 seconds

<jwatt> it's not letting me in

<jwatt> have the telcon details changed?

<jwatt> yeah

<jwatt> skype seems to be sick

hmm, do you have a voip client?

<jwatt> I have skype

<jwatt> :p

sorry, I mean a SIP client

<jwatt> no

www.w3.org/2006/tools/wiki/Zakim-SIP

I use code.google.com/p/telephone/ as the SIP client

and created an account on ekiga.net to use with it, as suggested by that wiki page

I find calling in to the Zakim SIP interface much better quality than using Skype, actually

jwatt, while you work on getting that set up, we will discuss a different short topic

<switch> in SVG 2

<jwatt> sure

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Jun/0039.html

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
... which is something I found a bit weird, it's kind of not very cleverly designed in that sense
... so I had a few questions on what to do with that
... what we want to decide for switch in SVG 2, either deprecate it or fix it somehow
... in my example, I show a few different cases
... one would be a newly introduced element
... one woudl be a custom element, maybe that just one UA implements experimentally
... and because of the requiredFeatures just being in the null namespace, it's not recognised
... and it's not switchedo n

s/o n/ on/

scribe: 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
... you cannot currently have a 1.2T video element with switch, and then fallback to a foreignObject with html:video

DS: you could nest it in a group
... it's a kludge, but I agree

ED: another aspect is what to do with non-chosen subtrees
... currently we don't really say what's supposed to happen with those
... but in some cases we get behaviour just from ebing in the document
... audio elements might start playing
... which can be a problem

DS: I thought we resolved at some point that "rendered" could mean that audio doesn't play

ED: I think the larger question is what we want to do with the switch element
... do we still want to keep it around, and if so, how should we fix it?

VH: can you give an example of what you would do with a new element?

ED: say SVG 2 introduces a new element foo
... and we add a new feature string for that
... so we put requiredFeatures="string" on taht element
... in UAs that don't support that new foo element, it won't actually pick up that requiredFeatures attribute
... it's seen as not have a requiredFeatures

CM: so it doesn't look for a DOM attribtue requiredFeatures, but because it doesn't implement SVGConditionalSomething?

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

DS: it seems particularly ill designed

VH: originally switch was introduced to help with progressive implementation of the spec
... so authors could do some animation in UAs that didn't implement animation yet

CC: would it help to have requiredFeatures in an SVG namespace?

ED: how do we want to proceed?

DS: you could put it on a g

BB: what about failing unknown elements?

CM: you could just force it to look at that attribute in the null namespace, regardless of the namespace of the unknown element

ISSUE: define switch to work with unknown elements and processing behaviour for audio elements etc

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

Starting on SVG 2

JW: basically I've been mucking around with a website we can use as a staging server to be able to get mercurial hooks
... I've given up on the w3c systeam to have the resources for that
... 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
... I started a wiki page

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org

DS: why was this necessary?

JW: for the mercurial hooks section

CM: [explains the hooks]

JW: we could make it so that when successful changesets get pushed, that it pushes it to the w3c server automatically

ED: how much of a problem would it be if we pushed to the w3c repo?

JW: it would be a pain
... this is one of the things I was going to bring up
... 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
... but you're right we don't want to have to merge
... if one person pushes in one place and others in the other

DS: how hard was it to do those hooks?

JW: to write them, I didn't really know anything about it before
... took me a few days to work out
... but it's easy now that I've looked at some examples

DS: do you think this initial infrastructure would be difficult for the w3c team to install?

JW: the thing they're not happy about is that hooks are basically scripts that run on the server
... and they don't trust anyone to be pushing random stuff
... 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
... so they would want to review the hooks every time we made a change to them
... at least in the early stages that might be frequent

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?

JW: yes, perfectly possible

DS: long term, it seems having this weird redirection is ...

ED: I think it would help to be able to expierment with checking systems for the spec itself
... I use that for my site, for example
... catching errors before allowing pushing to the server

DS: ok, that's cool

JW: one of the main things I want to sort out from the start is line ending changes getting pushed
... 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
... and .whatever is binary files
... and also certain files that are fixed unix or windows line endings
... 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
... so you won't screw up the diff when committing due to the line ending differences

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial

JW: some of you already have an hgrc file in your home directory
... if we're going to use this ul extension, it would be good to have all these lines in your config file
... that page tells you where to put your config file and what to put in it

<cyril> s/ul extension/eol extension/

JW: as far as users are concerned, that's all you need to do

<jwatt> http://mercurial.selenic.com/wiki/EolExtension

JW: that's the documentation if anyone wants to look it up to set particular line endings for some files
... so one of the hooks on the server checks for line ending changes and blocks the push if someone screws them up

DS: I'm trying to compare my existing hgrc file with yours
... I'm wondering what the key parts to change are

JW: the important parts are the [eol] section
... and in the [extensions] section, the "hgext.eol =" line, which is the line that enables the extension
... the extension comes bundled with hg, so there's nothing to install, it just enables it

s/it just/that line just/

DS: is 1 and True the same thing?

JW: I imagine so
... tbh I would suggest adding all of these to your config file

DS: so everyone who's planning on committing, let's add this config now

JW: so basically, in terms of the repo, I went ahead and imported the Second Edition files
... but I split things up a bit
... any files that are generated are no longer in the repository, they will just be created locally on your machine
... the .hgignore file that comes with the repo will make the build directory ignored
... and I split the tools directory out, since I discovered there's quite a bunch of tools down the cvs repo that were required

ED: the generated files, that includes the publish directory?

JW: I've made the builds create a directory build/publish/
... all files generated that aren't published go in build/
... and the stuff in build/publish/ would be zipped up, whatever

ED: is it fine to have this kind of set up?
... currently it seems everything on the w3c site is on some kind of version control system
... everything that's public
... but can we have the publish/ directory something that is generated on the w3c server?

JW: what I changed is that instead of having master/ and publish/ at the root, we have a . and a build/publish/
... and erik is asking whether the w3c servers will have a problem with build/publish/ not being in version control

<jwatt> what's the code?

DS: would we not have somewhere to point the public to?

JW: it would be easy to have a hook on svgwg.org to publish the generate spec there
... maybe that could be done on the w3c server

DS: couldn't you check it in somewhere on the w3c server?

ED: we could have a hook on the svgwg.org server, that syncs the build version or checks it in somewhere else

DS: that would be a feature

CM: it could be checked in to www.w3.org/Graphics/SVG/

JW: or a separate repo on dvcs.w3.org

DS: we should consider whether this infrastructure could be generalised to other WGs in the future

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

DS: ok

JW: for the moment, I've pushed these repos up to a sandbox on svgwg.org

<jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2/

<jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2-tools/

JW: you could just check those two out side by side, then run make inside the svg2 directory
... starting with the tools repo
... first change is I added the hgeol file for the eol extension

<jwatt> it's saying the conference is restricted

jwatt, do you want to try skyping in to one of us here directly?

<vhardy_> jwatt, what is your skype id?

vhardy_ will place his laptop in the middle of the table

<jwatt> msg username

jwatt, vhardy_ will just try to set up a conference bridge here, might be better actually

<jwatt> ok

<vhardy_> jwatt, can you call 408-536-9900 (code: 5108463, pwd: 20112011)

<jwatt> calling

<vhardy_> there is a UK number +44 208 606 1105

<jwatt> no

<jwatt> it's reading options

<jwatt> this isn't working

<jwatt> vhardy: I think it's empty

<vhardy> what isn't?

<jwatt> the meeting

<jwatt> it seems to thing I'm in

<jwatt> but is reeling of a list of numbered options

<vhardy> you should not get the options.

<vhardy> Let me try to restart the conf and then you can dial in again. ok?

<jwatt> ok

<vhardy> you can dial in now.

<jwatt> https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a

<jwatt> see comment at top in the meantime

JW: I copied 4 directories from CVS and a few files and put them in the tools repo
... I just want to check to see if it's ok
... I annotated it r=WG as if we have approved it

<jwatt> argh, it's interupted me to read more options

JW: the hooks are actually managed in the repo itself

<jwatt> https://svgwg.org/hg/svg-repo-hooks/file/tip

JW: the hooks are there
... everyone who has access to the server can access those hooks
... so all the hooks are in the hooks.ui file
... and hg is told which ones of those to actually use in the hgrc file there
... let's look at the svg2 repo
... 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
... I was also wondering if there was a few other files we could get rid of
... one of those is master/copyright-notice.html

CM: that's a vestige, you're fine to remove that

JW: the other one was master/indexlist.html
... which is mentioned in publish.xml but doesn't seem to get used
... I'll take that out too
... also master/names.html

CM: don't know why that's there

JW: ok, those were my main questions
... one thing I would note is that the relaxng directory I haven't added yet
... it seems to have 1.2T stuff and 2.0 stuff according to a comments

s/comments/comment/

scribe: we can always add it in later

CM: I think we should wait until murata-san has done the rng for 1.1F2, and start from there

JW: the third commit was just me fixing build scripts and things
... and any other files so that make would work with the tools directory where it is now
... if you check them out side by side, you should be able to build
... so don't pull those repos, I'll create new ones without those files we mentioend
... should I then push them into svgwg.org/hg/svg2/?

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

shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide

CM: how we will review patches? attach them to bugs?

<jwatt> https://svgwg.org/hg/svg-repo-hooks/file/tip/hgrc

JW: not sure, we do have a bugzilla instance

<shepazu> s/hook/höök/

JW: don't know how useful the review will be in the end

[we review the hooks listed in the hgrc file]

<ed> --- 15 min break ---

<ed> ok, so we moved some topics around today

<vhardy> ScribeNick: vhardy

path extensions

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Path_data_turtle_graphics_proposal

heycam: some things are hard to do.
... one is to have a part segment at a particular angle.
... turtle graphics type commands would be a lot easier.
... it would solve a usability problem. It would also make animation easier.

heycam shows a segment as in http://www.w3.org/Graphics/SVG/WG/wiki/File:A2.svg

scribe: it is not easy to animate that segment properly to rotate around the elbow.
... with the proposed value, animating the single rotation value would be sufficient
... shepazu wanted to talk about a simpler arc command.
... my proposal and a simpler arc command would make doing things like pie charts a lot easier.
... in the wiki page there are two different proposals.
... the first proposal adds new path commands (r and R)

R would set an absolute degree value.

r would set a relative rotation

f would be a straight line from the current point using the current rotation angle, for a given length (see wiki).

f would always be relative

scribe: with this proposal, can only do straight line segments.
... Second proposal is to not introduce an f and modify existing path commands to say that they may be subject to the rotation angle.

e.g., M 0, 0 h 10 r 45 ~ 10

(discussion on what r45 L 100 200 would mean)

shepazu: adding an implicit rotation in the path command that influences the following commands can be confusing.

heycam: the default rotation is the tangent to the curve at the current point.

shepazu: what if we had syntax like r 15, 10 (rotate 45, length 10)

(going over the second example)

shapazu: there was a discussion about extending the path syntax v.s., doing a super path.

heycam: I think there it is better to extend the path syntax.

(discussion about similarity to adding paint servers to SVG with the image values)

vhardy: I think the feature is very valid.

shepazu: let's take a pie chart use case.

(discussion about pie segments, showing different people have various ways of thinking about them).

cyril: there was improvements for SVG 1.2.

shepazu: may be we should not touch the path syntax at this point.

<TabAtkins_> TabAtkins_: <path><segment transform='...' d='...' /><segment .../></path>

heycam: the behavior for syntax error is precisely defined, so this is not introducing a new risk.

shepazu: then you have things that are poorly drawn.

heycam: it would be the same with other solutions.

shepazu: but you could switch to an alternate content.

heycam: with this too.

shepazu: you are right, we are going to extend SVG, so we are going that have this in multiple areas.

<cyril> CC: I was talking about: http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html

shepazu: I was thinking about adding a <shape> element.

heycam: should we think about having a new way to extend the path syntax and not change the <path> element.

shepazu: I am uneasy about it, but I do not have a good alternate solution.

tab: I think we can add to the syntax and not create problems we would not have otherwise.
... that argument applies to anything you could add.
... <shape> wont help that issue.

shepazu: I think we may get an adverse reaction to changes to <path>

heycam: may be the expectation was there that we would not change the path syntax.

vhardy: what about having an API for the feature?

heycam: it would not help for the declarative animation use case.

shepazu: I think the use case is valid.

(discussion about the ~ proposal).

cyril: could it be that after the rotation command, then it affects everything that comes after it. No need for a ~

(general agreement that this is better)

vhardy: how do you get back to the current tangent if you have modified it?

heycam: not currently possible in the proposal.

(discussion on how to address that).

<scribe> 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. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action13]

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

cyril: it would be good to have a list of changes we want to path.
... last year, we presented use cases at SVG Open. e.g., the ability to compose path, concatenate, reverse.
... I will send a link to the paper.

<cyril> perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf

<cyril> http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements

<heycam> cyril, you can add dot points to that "Path improvements" section there?

Catmul curves

<shepazu> http://schepers.cc/getting-to-the-point

shepazu: look at the pictures
... if you mouse over the line, you see the actual Bezier curve control points. It is not intuitive.
... this is a lot of control points.
... you can see that if you add the proposal, the path is a lot simpler.
... I could use 'P' instead of 'R'
... if you look at the Update 3 example, you can see a comparison of spiro curve and catmull-rom curve.
... the catmul version just has a few more segments, but you have more control too. And I added line to segments.

heycam: are Spiro curves much more complicated.

shepazu: if you mouse over the curve, you see the spiro curve control points.
... spiro curves make very nice curves, slightly unpredictable.
... the key essensece of catmull rom, all the points are on the curve.
... there is also a tangent parameter which I ommited.

<heycam> ScribeNick: heycam

<scribe> Scribe: Cameron

shepazu: I think it makes it harder to use with the tension parameter

s/tangent/tension/

s/ommited/omitted/

scribe: I think authors would rather not think about that, and just want some smooth path through the points

<vhardy> ScribeNick: vhardy

shepazu: the tightest tension parameter makes line segments, the losest one make swoops.
... if you look at the "Awesomeness of SVG path Element" figure, you see how there is no line segment. If you want line segments
... you can splt the Catmull-Rom command and add line commands.

ed: if you just want the points, why not add to polyline?

shepazu: because you may want to mix it with other path segments.
... I was currious if you needed extra parameters for each of the points.
... you might if you wanted to control the tightness per point. You would need three numbers per point.

ed: the syntax is easier to modify on polyline.

shepazu: this is really easy if you just want to use Catmull-Rom.

heycam: people have wanted 'point on a path' for a while.
... my only concern is the default tension.

<ed> s/the syntax is easier/the syntax and SVG DOM is a bit easier/

shepazu: I chose a default tension, but we could wait for implementation feedback.

heycam: I am wondering if different kinds of paths would benefit from different tension parameters.

vhardy: I agree. I think it is fine to have a default for the tension, but we should have a way to control it.

(some agree).

tab: you could specify a tension in a command.

shepazu: you could have something like
... P <tension> <list of points>

vhardy: but then it is not per point.

shepazu: if someone wants to implement it and provide suggestion for syntax, that would be fine.

heycam: none of the existing path commands have optional arguments, so we do not have a syntax for that, like a slash /

tab: I think we could go by fine with a default tension.

shepazu: you could have P t (x, y)+

vhardy: that is still for the whole curve.

shepazu: I think that is the most common case.
... 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.
... having an initial tension may be a [0, 1] parameter instead of the actual range in the Catmull Rom formulas.

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

<scribe> ACTION: shepazu to make a Catmull Rom editor that takes variable tension parameters. [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action14]

<trackbot> Created ACTION-3085 - Make a Catmull Rom editor that takes variable tension parameters. [on Doug Schepers - due 2011-08-04].

shepazu: for the tension at the junction between P curves, we could have an optional end tension for the last point on the curve.
... P t (x, y)+ (t2)

<cyril> s/(t2)/(t2)?/

Capturing previous resolution.

RESOLUTION: we will add a path rotation command.

chrisl: how is this going to work in existing SVG 1.1 content.

chris: why not add a new element with these commands instead.

chrisl: what is the advantage of appending to the path command.
... I want to make sure that we considered this?

heycam: we had a discussion about this.
... if you want a reasonnable behavior on all implementation, you would use a <switch>/requiredFeature.

chrisl: I just wanted to make sure this was a concious decision.

heycam: yes, it was a conscious decision.
... 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.

chrisl: another element might still be easier/better. Have you considered it? We could also add NURBS.
... 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).

shepazu: I had similar objections. We need to be ready to justify it.
... anything we add should be normalizable to SVG 1.1 syntax.
... we could provide utilities or algorightms for the conversion.

heycam: I think that is a good idea.

chrisl: yes, and authoring tools could also offer that as an option and include a switch between the new and old syntax.

cyril: we did not talk about the verbosity aspect. Path commands are compact. Adding elements is move verbose.

heycam: I think there is still room for new path commands and the things you were suggesting.

chrisl: we need both the spec. and scripts providing the equivalence between the syntaxes (additions and old path syntax).

heycam: we have agreed to work on the SVG graphics API.
... we did not discuss the switch for these new features.

<cyril> s/move verbose/more verbose/

shepazu summarizes the earlier discussion on <switch>

ed: there was no resolution on that issue.

cyril: the behavior of <audio> on switch is defined in SVGT 1.2 and we should port it to SVG 2.0.

heycam: what does display:none do for audio and video in HTML5?

anne: nothing. No effect.

tab: if you dont want it to play, you don't put it in the document.

(discussion on audio and video in HTML5).

LUNCH BREAK

<shepazu> ACTION: shepazu to suggest audio-volume control properties to CSS WG [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action15]

<trackbot> Created ACTION-3086 - Suggest audio-volume control properties to CSS WG [on Doug Schepers - due 2011-08-04].

<ed> http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty

<ed> ACTION-3086: http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty

<trackbot> ACTION-3086 Suggest audio-volume control properties to CSS WG notes added

<ed> 1 hour

<shepazu> http://schepers.cc/svg/path/dotty.svg

<ed> http://www.imdb.com/title/tt0137523/quotes?qt=qt0479254 ?

<birtles> ScribeNick: birtles

Easier integration of HTML into SVG

TA: If we could abandon XML it would be really easy

VH: I've done a write-up covering both directions

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG

<anne> doug

VH: The reason I bring this up is author convenience
... to match expectations
... I believe the issues we have can be fairly easily overcome
... this is pretty well implemented currently wrt to foreignObject
... the only the thing foreignObject does is provide an initial viewport
... in the last e.g. if you specify the containing block/viewport then that's all you need to apply the box model
... for the opposite direction (SVG in HTML)
... it's useful, e.g. to put a circle in a cell
... but it doesn't appear in the middle
... 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
... in this example, if I had x/y it would be handled differently
... if you have an SVG element which is not <svg> then it becomes part of the box model

CM: rather than adding a new attribute on div can be just use left/height etc.?

VH: I don't think you can because they will reference the nearest containing block

CM: you want to values to be in SVG co-ordinate space
... so you can just interpret them as SVG would

CL: that's why we have foreignObject
... to deal with that mapping

AK: I think you need to keep it

VH: I think you need to keep the handshake

CL: It's defining two--the SVG space and the CSS canvas and mapping the two together

VH: The first case, my proposal is to provide a shorthand for what foreignObject does
... it's just a matter of syntax

<cyril> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

AK: If you want to introduce a new attribute you'd have to extend HTML as well

<ed> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#foreignobject

VH: My real question is, I think it would be nice to have a shorthand
... it seems unnatural to me to have this kind of overhead
... I think it's very natural to want to integrate text into your graphics
... you should be able to do that simply

CL: foreignObject also makes the content display

<ChrisL> because svg says that foreign namespace stuff mixed in is okay and does not display

CM: it the past mixing SVG and HTML was a kind of extension feature but now its commonplace

VH: The naming now seems inappropriate "foreign" object

AK: you could add an "html" element in SVG

CM: if you're going to do that, then you may as well drop the requirement for a container element

TA: the reason we require the <svg> root in HTML is because of namespaces
... I suspect the same problem occurs in reverse

CM: e.g. <font>

AK: In the e.g. (in the doc) the <div> would end up in the SVG namespace

<ChrisL> so it sounds like te current html5 spec does it the right way and the namespaces come out the right way.

<ChrisL> if we added an html element in the svg namespace, as an alias of foreignObject, it would not work in html5

AK: to escape from HTML you need <svg> or <math>, to escape <svg> you need <foreignObject>
... the problem is you need to establish a bounding box in SVG

CM: so it's not a parser problem

TA: it shouldn't be

DS: Can html add x/y/width/height to the root?
... or use CSS to establish the viewport of the html

VH: so instead of the containing-block attribute you use CSS
... so it's a new property for establishing the viewport, not just left/top
... you need to define which viewport you're going to define your element into
... you need the rectangular viewport you're going to put it into

<ChrisL> anne: if you had two divs following each other they would make two canvases

CM: just use the top/left/width/height props to specify the SVG coordinate space for rendering the HTML
... and that's also the width/height of the CSS box
... need to consider interaction with max-width/height

TA: I think you should be styling the box directly

VH: one thing is to size the box, but foreignObject also defines which box you're going to layout into

TA: we can just define how the absolute positioning model means in SVG
... what is the reference box there

VH: even the static positioning, if I just have a div what does 100% mean?

TA: we can assume it's absolutely positioned

VH: the computed value of the position property would be static

TA: svg|* > html|* { pos: abs }

AK/CM: I don't think we need to force it to be absolute

AK: but we have to define how width/height works

VH: if you look for a CSS block in SVG it's only the <svg> element

s/block/box/

<ChrisL> I think the problems introduced by removing fO are worse than the current situation

AK: CSS requires a root element
... so it's difficult if e.g. you have two paragraphs

CM: so you'd have to specify the behaviour

AK: it's not been specified yet

CL: I think it's a bad idea, I understand the motivation but I think it introduces more problems
... SVG has a lot of mention of the containing element, rootmost element etc.
... if you remove that you lose the definition of units and introduce all sorts of other problems
... yeah you have to type fO etc. but it all works
... both of these changes require the html parsing to change
... would introduce CSS problems
... I don't think it would work

CM: we wouldn't half solve the problem, we'd have look at all the implications and tricky cases
... we just have to look at it carefully

DS: what we have now works, but if we introduce different syntax there'll be a transition period where it won't work
... but people with SVG-capable browsers are generally only the latest version and getting updates

s/only/on/

scribe: if we're going to do this we should do it soon
... especially before new releases of IE (after version 8)
... 8

VH: from a user's point of view
... 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
... and compare that with a single line of text
... which you can just drop in
... functionality-wise it's odd that we don't have this yet

CM: it makes the platform look less cohesive that you have to do that
... presuming that parser changes are OK

TA: switching over to using html directly should cause no problems
... it's symmetrical with what we do with svg in html
... people have been doing that for a long time

DS: it wasn't that common, there were just a few obscure platforms

TA: We can ask about that parser change from the point of the HTML parser

AK: The proposal is to embed any html element

TA: embedding svg/math in html is easy, we can control the size of it using things in those elements
... in the reverse situation we don't have that information
... because x/y aren't valid html attributes
... in the SVG case at the min. we'd need the HTML root to take x/y
... if you're within the SVG model you need to use the SVG positioning model for coherence
... We have 3 possibilities
... 1) keep fO
... 2) add x/y to html root or to all elements
... (we already have width/height)

RC: we have CSS transforms

<ChrisL> yes, we already have width ad height *and they mean different things*

TA: 3) cast SVG model in terms that CSS can manipulate

VY: is the last one already in discussion for the purpose of animation

TA: yes, that's in discussion

VH: it might be interesting to investigate option (3) further

DS: we can map that fairly easily

TA: or just have x/y be CSS properties that would only be valid within the SVG positioning model
... like using grid properties within a grid

<scribe> ACTION: Erik to put on the FXTF agenda, discussion about HTML positioning in SVG and contact dbaron [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action16]

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

<scribe> ACTION: Vincent to illustrate the three options put forward by Tab in the SVG/HTML integration proposal [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action17]

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

Moving onto the second part, SVG in HTML

AK: the second part doesn't work with the parser

TA: we tried to do it and it makes the parser too difficult

VH: why was that

TA: it has to do with keeping namespaces working correctly
... particularly wrt to XHTML/HTML compat
... that's why you need an svg/math root

AK: we'd need to rev the html parser every time an SVG element is added

DS: so a bare <svg> in HTML would do what?

(some discussion about what the defaults are)

DS: there are 3 cases where people want to make SVG content
... 1) where you want it to be fixed width/height
... 2) as with (1) but with stuff outside the viewport (still fixed size)
... 3) everything automatically scales to fit the content
... I think you get the most benefit from (3)
... auto-scaling SVG is the most beneficial SVG
... if you want it to be fixed width/height there are ways of doing that

CM: but we don't have automatic viewport

DS: If we just have "<svg>" that should be mean auto-scaling viewport
... i.e. = <svg vb="bounding box">

<ChrisL> tat is what we have already. if uou omit the viewbox then you get autoscaling

CL: if you don't have a viewport and add content everything will scale down

CM: I think what implementations do is compute 100% to a pixel size based on the size of the containing block of the SVG
... and then that number of pixels becomes the implicit viewBox width/height and starting at 0,0

<ChrisL> if that is the case, then current implementations dont give us doug's third case 9even thoygh that was the original intent)

DS: my proposal is that a bare "<svg>" (no attr) takes the bbox of the content in +ve coordinate space

<ChrisL> s/9e/(e

<ChrisL> so you would only get first quadrant displaying?

DS: and auto-scale that

(DS draws a circle with origin 0,0 and shows that only the lower-right quadrant would be shown)

VY: that is problematic for text
... where if you don't specify 'y' it won't be visible

DS: that's something the authors just have to figure out

s/VY/JY/

DS: then an alternative is just take the bounding-box

CL: I don't think you don't need to restrict it to the positive quadrant

DS: ok
... so we take the bounding box of all the content

(DS draws a square with "TEXT" positioned at 0,0, i.e. above the top edge of the rect)

CC: You're proposing different behaviour for the same syntax

CM: I think the existing behaviour is useful

DS: In those cases use the attributes

CM: So you're keying the distinction off the presence/absence of the attributes

<cyril> CC: You're proposing to break compatibility

DS: Yes
... and most content is produced by authoring tools that produce those attributes
... so I don't think we'd break compatbility
... this proposal matches authors' expectations
... I think this is the most intuitive behaviour

<ChrisL> that sounds god to me

<ChrisL> s/god/good/

<shepazu> 0:)

VH: yes, in my proposal I was assuming this behaviour

CC: I think it changes the way implementation works
... previously you would prepare the buffer beforehand

ED: you already have that with the overflow property

VH: I think it's unfortunate that the parser issues prevent us from including SVG elements directly
... so Doug you're talking about keeping a wrapper <svg> element but making it simpler

DS: Yes
... it avoids the parser problem
... ensures we have only one SVG root
... which simplifies it
... if you have two circles (as per the document)

ED: yeah what coordinate space do you use if you reference a gradient

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
... generally people don't want to use a single <circle> but something more complex
... so the cost of adding an <svg> root is not so great

<ChrisL> i agree

<ChrisL> <svg bboxtype="stroke">

DS: we're going to have different bounding boxes (e.g. the current defn doesn't include stroke width)

<ChrisL> current bbox is purely geometric. it exclides stroke, markers and filters

DS: and the new bbox that includes everything would be the one we use for the autoScaling behaviour

<vhardy> s/exclide/exclude

DS: there are two options
... one simply sets the viewBox to include the content
... the other also then stretches the <svg> containing block to take as much room as is available
... in either case we want some simple behaviour for a bare "<svg>"

VH: I agree it's less common to want to include a single SVG element in HTML than the other way around
... the new scaling behaviour is nice but not strictly necessary
... I withdraw my proposal to allow SVG elements in HTML without an svg root
... for the reasons we discussed

(discussion about how the CSS overflow property got split into overflow-x/y)

<birtles_> ACTION: Jen to propose auto viewBox sizing and SVG container box sizing for bare <svg> in HTML [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action18]

<trackbot> Sorry, couldn't find user - Jen

<birtles_> ScribeNick: birtles_

<ChrisL> trackbot, status

<birtles> ACTION: Jennifer to propose auto viewBox sizing and SVG container box sizing for bare <svg> in HTML [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action19]

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

<birtles> ScribeNick: birtles

<ed> --- 15 minute break ---

Text layout

<cyril> Scribe: Cyril Concolato

<cyril> ScribeNick: cyril

CM: text layout, positioning, anchoring, bidi ...

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout

CM: going through my text layout proposal
... there are examples on the wiki, but no image, didn't have time to make snapshots
... the primary problem is that the x/y attributes on text elements are used for 2 purposes
... 1) as an anchor position
... 2) to position glyphs
... sometimes they can be in conflict
... for <text x="10 20 30">abc</text> if you have text-anchor=start and ltr text there is no conflict
... but if you have bidi text like <text x="10">ABCabc</text> with ABC rtl and abc ltr, what is the x for ?
... is it for the A or for the whole text chunk ?
... probably you don't want to do anchoring and positioning
... and if we separate we would not have this conflict

VH: should we consider a solution for text and a solution for glyph

CM: I think for glyph positioning we can use the previous proposal but for text positioning we cannot break the existing
... when it is ambiguous we could disable anchoring

VM: if there is one value that is anchoring and multiple values is glyph positioning ?

CM: yes

VH: then what is the anchor ?

CM: my proposal is that there is no shifting to do anchoring

ED: you could do a middle thing to have each character centered

CM: it is not a use case I have considered

<ed> s/middle thing/text-anchor=middle/

BB: what happens when you're positioning text chunks instead of glyphs/characters

<vhardy> http://www.w3.org/TR/SVG/text.html#TextChunk

CM: ligatures still work across chunks

<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

<ChrisL> cm: yes

<ChrisL> in that case i think this is a good proposal

s/eft/left/

<ed> "Ligatures only occur when a set of characters which might map to a ligature are all in the same text chunk."

CL: what happens if you have tspans ?
... with two different colors ?

<ChrisL> ... and ligature formation

ED: tspans would define a new text chunk

CM: only if it has an x on the tspan

<ed> s/x/x or y attribute/

CM: I don't really consider that in my proposal

VH: the first issue and proposed solution is chunk, anchor and bidi
... is there anything else ?

CM: that's the rationale I gave for the whole thing
... to distinguish between positioning and anchoring you use the number of values in x/y

ED: what happens when you have 1 value in x and multiple values in y

<ed> s/ in y/ in a tspan child/

<text> <tspan x="10 20"> ab

in this case there is no anchoring in my proposal

CM: one problem with multi-line text with text and tspans
... you wouldn't want bidi across those things
... BB: could you illustrate the 2 cases with discontinuity: rtl/ltr

s/... BB:/BB:/

[CM illustrating on the board]

CC: if you change the number of values in the attribute, you would have discontinuity in the rendering

CM: that's a downside of the solution

VH: no there would be continuity

ED: anchoring is what people use

VH: there are authoring tools that use it for positioning

CM: the problem comes only for bidirectional text
... for purely rtl or ltr there is no problem

<ed> s/people use/most content uses/

CM: there is another problem, when you don't supply enough values for bidi text, it's not clear where the remaining characters go

<text x="10 20 30">ABcd

scribe: where does the d go

s/d go/d goes/

scribe: if it's chunked you avoid this problem
... 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

VH: if the proper solution is to use glyph indexing, why not deprecating character-based positioning

<birtles> CM: I wrote a bunch of tests and everyone is doing it differently

<ChrisL> yes

ED: I don't think implementations are so consistent with diacretic text

<ChrisL> why?

<ChrisL> ok

<ed> s/diacretic /diacritic /

ED: so we should text this feature separately

s/should text/should test/

ED: ligature is not the same as diacritic mark

<ed> http://www.w3.org/TR/SVG11/text.html#CharactersAndGlyphs

ED: it's refered to as a composite character

VH: are we trying to fix 1.1 and produce an addendum or are we trying to define what we want for 2.0 ?

CM: I just want some defined behavior for comibination of character-based glyph positioning, anchoring, ... but to have the glyph indexing
... I want the problems resolved in a way that makes enough sense given the fact that we are using character-based positioning

VH: we recognize that it's broken so people cannot use it properly

<ChrisL> whiteboard photo http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0026/IMAG0034.jpg

CM: I don't want that for simple cases that are interoperable, I don't want to disable certain features

<ChrisL> the ones with multiple xy are often from PDF to SVG conversion

CM: Adobe would in the future move to glyph-indexing and positioning

RC: yes probably

CM: what I should do is condense that wiki page into a slide show of current spec contradictions and proposed solutions

VH: I will ask feedback internally

ED: you might want to look at I18n tests for bidi

<ed> s/for bidi/for bidi in svg/

<scribe> ACTION: heycam to produce a condensed description of the problems and solutions [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action20]

<trackbot> Created ACTION-3090 - Produce a condensed description of the problems and solutions [on Cameron McCormack - due 2011-08-04].

<scribe> ACTION: heycam to upload the tests for complex text cases [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action21]

<trackbot> Created ACTION-3091 - Upload the tests for complex text cases [on Cameron McCormack - due 2011-08-04].

CM: on the top of the wiki page, there are the 3 use cases that I want to preserver

s/preserver/preserve/

ED: yes
... I'm not sure the current spec wording matches the implementations

CM: one aspect of the proposal was to add a value to text-anchor to turn off explicitly anchoring

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

<ed> ED: in opera, the bidi reordering happens first, then the result is mapped to the given positions

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

Canvas in SVG

BB: should we define a canvas element in SVG ?

VH: we said we are going to put it on the agenda of an FX meeting

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

CM: this might be a good argument for dropping foreignObject and allow the bare elements inside SVG
... it would be good for harmonization of audio, video, canvas ...

VH: I agree

<heycam> http://www.w3.org/Graphics/SVG/WG/track/issues/2417

event attribute

AVK: the IDL attribute is generic on the Element but SVG would have to define event handler content attribute

CM: what is generic ?

AVK: the bits about how functions are defined
... DOM Core provides an interface that allows the SVG spec to say this is an event handler attribute
... and all the requirements follow from that
... for the entire list, it would be useful if SVG provides the delta compared to what HTML has

CM: we don't want HTML and SVG both define onclick for example

AVK: it would make sense to have the union of events between SVG and HTML in DOM Core

<scribe> ACTION: ed to collect the events from SVG as a delta with respect to HTML [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action22]

<trackbot> Created ACTION-3092 - Collect the events from SVG as a delta with respect to HTML [on Erik Dahlström - due 2011-08-04].

AVK: I would like to discuss also the event vs evt issue
... what we discussed was that there would be a single argument event passed to the function

<ed> that's ISSUE-2055

<ed> ISSUE-2055?

<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- closed

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2055

AVK: and that there would be a scoped variable with the same value called evt defined

<ed> ISSUE-2176?

<trackbot> ISSUE-2176 -- evt vs event Redux -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2176

<ed> http://www.w3.org/TR/SVGTiny12/script.html#HandlerElement

<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')."

RESOLUTION: We decide to resolve ISSUE-2176 by introducing evt as an alias to event in event handlers

<scribe> ACTION: heycam to add a note to the SVG spec about ISSUE-2176 [recorded in http://www.w3.org/2011/07/27-svg-minutes.html#action23]

<trackbot> Created ACTION-3093 - Add a note to the SVG spec about ISSUE-2176 [on Cameron McCormack - due 2011-08-05].

<ed> [everyone looks over their open actions]

<heycam> trackbot, close ACTION-3068

<trackbot> ACTION-3068 Investigate reference updates per Innovimax's comment closed

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/shape./shape)/
Succeeded: s/ some support for SVG fonts./ support altGlyph for SVG fonts, but not altGlyph for Opentype fonts AFAIK./
Succeeded: s/thought/though/
Succeeded: s/web/lib/
Succeeded: s/matter/manner/
Succeeded: s/'rotate'/'SVGRotate'/
Succeeded: s/the spec/the SVG spec/
FAILED: s/6. toDataURL/6. toDataURL and toBlob/
Succeeded: s/can/can get/
FAILED: s/pie chart/radial menu/
FAILED: s/manu/menu/
FAILED: s/o n/ on/
FAILED: s/ul extension/eol extension/
FAILED: s/it just/that line just/
FAILED: s/comments/comment/
FAILED: s/hook/höök/
FAILED: s/tangent/tension/
FAILED: s/ommited/omitted/
FAILED: s/the syntax is easier/the syntax and SVG DOM is a bit easier/
FAILED: s/(t2)/(t2)?/
FAILED: s/move verbose/more verbose/
FAILED: s/block/box/
FAILED: s/only/on/
FAILED: s/9e/(e/
FAILED: s/VY/JY/
FAILED: s/god/good/
FAILED: s/exclide/exclude/
FAILED: s/middle thing/text-anchor=middle/
FAILED: s/eft/left/
FAILED: s/x/x or y attribute/
FAILED: s/ in y/ in a tspan child/
FAILED: s/... BB:/BB:/
FAILED: s/people use/most content uses/
FAILED: s/d go/d goes/
FAILED: s/diacretic /diacritic /
FAILED: s/should text/should test/
FAILED: s/for bidi/for bidi in svg/
FAILED: s/preserver/preserve/
FAILED: s/ I'm not sure the current spec wording matches the implementations / I don't think the current spec wording matches the implementations exactly/
Found ScribeNick: vhardy
WARNING: No scribe lines found matching ScribeNick pattern: <vhardy> ...
Found ScribeNick: TabAtkins__
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: ed
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: vhardy
Found ScribeNick: heycam
Found Scribe: Cameron
Found ScribeNick: vhardy
Found ScribeNick: birtles
Found ScribeNick: birtles_
WARNING: No scribe lines found matching ScribeNick pattern: <birtles_> ...
Found ScribeNick: birtles
Found Scribe: Cyril Concolato
Found ScribeNick: cyril
Scribes: Cameron, Cyril Concolato
ScribeNicks: vhardy, TabAtkins__, heycam, ed, birtles, birtles_, cyril

WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa +33.9.53.77.aabb ChrisL tbah
New list: tbah ChrisL +1.206.675.aaaa


WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa tbah ChrisL
New list: +1.206.675.aaaa jwatt


WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa jwatt
New list: +1.206.675.aaaa ChrisL

Default Present: ChrisL, +1.206.675.aaaa
Present: heycam brian ed cabanier cyril stearns_ tabatkins_ tbah shepazu Charles Pritchard
Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
Found Date: 27 Jul 2011
Guessing minutes URL: http://www.w3.org/2011/07/27-svg-minutes.html
People with action items: cabanier doug ed erik heycam heycan jen jennifer shepazu tab vhardy vincent