See also: IRC log
<trackbot> Date: 27 July 2011
<vhardy_> ScribeNick: vhardy
<vhardy_> heycam: Topic 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].
<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.
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].
<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
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
<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 ) 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
<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
<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 .
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
<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?
<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
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 ---
<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
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
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[End of scribe.perl diagnostic output]