W3C home > Mailing lists > Public > www-svg@w3.org > May 2012

Minutes, Hamburg 2012 SVG WG - Day 2

From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Date: Tue, 8 May 2012 14:59:25 +0000
To: "www-svg@w3.org" <www-svg@w3.org>
CC: "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>
Message-ID: <D6788E6173C4A64B9B42DE1F2EB94EB9BBDFABA8@exm02-wvp.cisra.canon.com.au>
Minutes as html:


As text:


      [1] http://www.w3.org/

                               - DRAFT -


08 May 2012


          +49.403.063.68.aaaa, Tav


          krit, heycam, ed, nikos


     * [2]Topics
         1. [3]text layout proposal
         2. [4]text decoration
         3. [5]CSS3 transforms
         4. [6]CSS Transforms
         5. [7]masking
         6. [8]Update on SVG-in-OpenType implementation/proposal
         7. [9]Canvas in SVG
         8. [10]text
         9. [11]Future F2F meetings
        10. [12]SVG 2 Requirements
     * [13]Summary of Action Items


     [14] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda

   <Tav> I'll join when I can... today is a holiday in France,
   I've got two young girls to watch.

   <krit> scibenick krit

   <krit> scribenick krit

   <ed> scribeNick: krit

text layout proposal

   heycam: sepeerate facility to get hits from the fonts


     [15] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout

   heycam: to get information how glyphs get transformed
   ... or one glyph into two glyph and two to one. Also the
   position of the position per character must be defined in DOM
   ... We can define behaviro
   ... I think it is useful to have sth defined
   ... as summary
   ... (some drawings)
   ... people use x,y attributes to define position of glyphs
   ... people use spans and position for multiline texts
   ... or define position of single chars
   ... what if you have less positions than chars? what happens
   with the other chars?

   x="10 20 30">a b cd</text>

   heycam: <text x="10 20">ABCdef</text>
   ... every number applies per char
   ... what happens with the other chars? it is undefined

   krit: it is not

   heycam: might be, but i don't like it

   jdaggett: i jump in
   ... text>final</text> => 4 glyphs
   ... font-variant: small-caps => 5 glyphs
   ... (fi) one char
   ... evry lauyout, style happnes per glyph
   ... if you want to have a pos api, than you have to look more
   at the glyph
   ... values x,y should get deprecated

   cabanier: it should not

   tabatkins__: UAs should never apply ligtares

   jdaggett: you have reordering where logical order and glyphs
   are not right

  <tabatkins__> (Note: I didn't say that. I was verifying whether
   Rik was claiming the *author* decides whether to use ligatures,
   or someone else. He clarified that it was the browser. I then
   asked him if he meant that browsers should just never use
   ligatures in SVG.)

   jdaggett: web is not a closed author system, but SVG might be.
   So that does not apply both
   ... notation is based on PDF that does not work

   cabanier: not neccesaarily PDF

   jdaggett: from PDF world one char is one glyph, which isn't the

   cabanier: that isn't the case for PDF either

   jdaggett: a combining-ring = &
   ... or a-ring character, a font would have a glyph for
   ... so you never no how many glyphs you have from the chars
   ... that is why it can not work at all\

   vhardy: do we talk about deprecating or fixing the model? do we
   want to have HTML model?

   heycam: we can't remove positioning. But want to move over to
   sag as much as possible

   jdaggett: your head will explode if you try to fix

   tabatkins__: maybe just use the simple cases of position, which
   might not cover complex cases

   jdaggett: we could also say that for this reason, the model
   does not work and therefore gets deprecated

   heycam: in the case where fi turned to one glyph
   ... the fi would get one glyph and takes one entry of the
   positioning list

   jdaggett: this is much to complex for UAs

   krit: I am not sure if we do it for WebKit, but i think we
   address ligature

   jdaggett: that would be against the model
   ... since text layout should be independent of rendering
   ... only way would be to scan everything a second time after
   text lay outing and respecting font behavior

   ed: it is broken, I don't think that we get it right

   heycam: I would be happy with an interoperable (not so useful)

   jdaggett: I think it would be a waste of time to specify it
   ... even if it might be useul
   ... it is very font dependent and also dependent on the
   ... you would have to be very intelligent to knowing all

   heycam: I think the fi case gets handled by most browsers

   jdaggett: I can write tests that would be totally not
   interoperable cross UAs

   heycam: might be
   ... so it is fine basically
   ... I think we can't remove the pos. API from the spec
   ... a lot of people use it

   birtles: a lot of these usecasess can be addressed by <tspan>

   jdaggett: It comes from the PDF world to hard code text

   heycam: who is against defining it more
   ... where is the reason to not let it undefined?

   jdaggett: I think it is easy to define it, but you would not
   produce the results that you want (e.g because of different
   font handling dependent on platforms)

   ed: PDF solves it by embedding fonts?

   cabanier: not necessarily it has a one by one model to save it
   ... but yes, you need the right fonts to not get broken stuff

   vhardy: we could add a paragraph that it is font related and
   could get it wrong when using other fonts

   jdaggett: I wouldn't go that way to define basic layout with

   vhardy: The broken behavior is already the case today

   jdaggett: I would say try to avoid that
   ... I am not sure if the API would be a lot of use

   vhardy: instead of fixing, should we talk about relying on the
   HTML model
   ... I thing paragraphs are a really need of web developers
   ... And we might think how we can fix positioning chars in
   another part

   jdaggett: FF allows you to select within a ligature

   krit: but not expected?

   jdaggett: maybe it is
   ... my point is when you want a model that knows about the
   position of fonts, then it is not easy

   vhardy: in some cases you want a particular glyph on a part.

   tabatkins__: SVG could allow <p>

   Tav: InkScape makes a lot of use of positioning glyphs

   jdaggett: how do you deal with ligatures

   Tav: it is heavily used
   ... I don't know what we do for ligatures

   jdaggett: in the 80% case the current model works
   ... for the other 20% it doesn't

   Tav: but there are at least 80% where it works

   jdaggett: it simply breaks for a not so simple exampels
   ... and we will run into situations where UAs are inconsistent
   ... there are sequences of uni code chars ... that...
   ... on web you can not guarantee the existence of the font, the
   model does not work

   Tav: but there is a usage beside the web

   tabatkins__: we won't drop positioning
   ... we could use a simple model that does just wok on simple
   cases, and deprecate it with the note not to use it in the

   jdaggett: It is syntactic sugar. You should use spans if you
   want to have it

   Tav: I could be fine with it
   ... there are a lot of different use cases like titles and so
   on. But span might work here as well

   heycam: I'll look what we can simplify further
   ... SVG does not talk about ligatures now
   ... you have to know how characters turn into glyph

   jdaggett: the problem is the lay outing can not always expect
   that the underlaying platform is able yo use sub pixels on text
   rendering so you might not be pixel perfect.
   ... and because you often don't know how ratserization works on
   the underlaying platform, or you can not control it, the model
   simply does not work

   cabanier: even a sub pixel can make a huge difference
   ... ont the screen

   jdaggett: I think the model forces an extremely platform
   dependent implementation.

   heycam: next topic whitespace instead of XML whitespace
   ... the XML has different behavrio in comparison to CSS

   <text> a


   heycam: SVG would not add a whitespace
   ... while e.g HTML does
   ... I try to map xml:space="preserve"
   ... newline would became spaces now
   ... but I think we could do that
   ... <text x="10" whitespace="pre">



   a and d would be aligned vertically



   birtles: I would expect that it breaks a lot of content, incl.
   content that i wrote

   <ed> [16]http://www.w3.org/TR/CSS21/text.html#white-space-prop

     [16] http://www.w3.org/TR/CSS21/text.html#white-space-prop

   <ed> [17]http://www.w3.org/TR/CSS21/text.html#white-space-prop

     [17] http://www.w3.org/TR/CSS21/text.html#white-space-prop

   <ed> [18]http://www.w3.org/TR/SVG11/text.html#WhiteSpace

     [18] http://www.w3.org/TR/SVG11/text.html#WhiteSpace

   tabatkins__: I would expect more problems, since you have a new
   space, that would eat one of your positioning values

   vhardy_: illustrator exports it with xml:space preserve

   ed: so there's nothing in the proposal that maps
   xml:space=default to something in the white-space property?
   just thinking about backwards-compat with exiting content

   heycam: I'd assume it is a bit like an edge case
   ... I'd like to get rid of the special xml space behavior if

   <birtles> Talking about: Neutering other properties
   (display:block, position, float, border, padding, margin,
   text-align, text-indent, ...)

   cabanier: SVG doesn not use the same layout model

   krit: it would mean to somehow accept css boxing model into SVG

   tabatkins__: might not make for margin, other than that does
   not mean neg. influence

   <text> ab<tspan padding="100px">cd

   tabatkins__: padding does only work on inline directory on
   inline elements .. sp the base line would align

   on the vertical direction

   heycam: most problem might be for position and float
   ... the new supported properties would be presentation
   ... I come up with a lit of properties that we should have.

   <ed> Text decoration rotation

text decoration

   <text text-decoration="underline">


     [19] http://lists.w3.org/Archives/Public/www-svg/2011May/0141.html

   tabatkins__: jdaggett: CSS does not specify sth. like that,
   because it is undetectable


     [20] http://www.w3.org/TR/SVG11/text.html#TextDecorationProperties

   heycam: problematically is the separation by tspan

   birtles: if you redefine the decoration on the span again, this
   will break the previously defined decoration.

   heycam: makes sense

   tabatkins__: I think we could use the spec work from CSS
   without to much work

   <ed> -- 15min break --

   <shans_> tab's feet:

     [21] http://0.media.collegehumor.cvcdn.com/87/15/03b878488aa1ec8bebb44e2baec36f64.jpg

CSS3 transforms

   <heycam> ScribeNick: heycam

CSS Transforms

   Dirk: this is the joint venture between CSS and SVG WGs

   ... the CSS transforms spec defines a couple of new properties,
   like transform, transform-origin, transform-style

   ... some properties are needed just for 3D

   ... besides the properties there's also a definition for SVG
   transform attribute

   ... this allows transforming the coordinate space of the element

   ... for CSS transform property we want to have a presentation

   ... so that we can apply transforms using CSS

   ... besides the transform attribute, we introduce some new
   presentation attributes for the new CSS transform properties

   ... there's new syntax for the transform presentation attribute

   ... the spec now allows units for translations, rotations

   ... the new syntax is the combination of syntax allowed by the
   original SVG transform attribute and the CSS transform property

   ... there's also gradientTransform and patternTransform

   ... both are now presentation attributes but map to the transform

   ... there were some issues with rotate()

   ... in CSS this has only a single angle argument

   ... in SVG, it has three arguments -- the two optional arguments
   are the center of the rotation

   ... we agreed that we'll still allow rotate() with 3 arguments,
   but not required for UAs that only support CSS transforms (and
   not SVG transforms)

   ... the 3D transforms also now apply to SVG

   ... there are some special cases for patterns

   ... the spec defines that the pattern gets flattened first before
   painted as the pattern

   ... pattern/gradient elements don't have a bounding box, so
   there's no simple way to resolve percentages

   CM: you could make percentages for objectBoundingBox resolve to
   the bounding box of the used element

   ... and for userSpaceOnUse, resolve against the coordinate system
   you're in

   Dirk: we have the SVG DOM interface defined for the transform

   ... the current interface can't represent transform values with

   ... or the new transform function types

   ... for new types, we can just expose them as "unknown" transform

   ... for unit values, px/cm/ can just be exposed as user units

   ... I've also specified that transform can be used with <animate>
   and not just <animateTransform>

   ... how much SVG animation text should we put in this spec?

   ... for example additive rules, etc.?

   ... I think we should put it in this spec for the moment, since
   this spec is moving faster than SVG2

   ... and then eventually we can remove them from this spec and
   just reference SVG2

   ... for <animateTransform>, we have a specific list of transform
   types it supports

   ... I'm specifying that that type="" attribute is extended to
   support the new types

   ... we might be able to come up with a definition for paced
   animation of <animate attributeName="transform">

   VH: currently it's undefined, I think we should say that in the
   spec that that's the current behaviour

   BB: what's the big time pressure?

   VH: unprefixing

   [some discussion about current undefined behaviour for zero or
   identity values for additive/cumulative transform animations]

   [dirk shows an experimental build of WebKit + CSS3 Transforms
   in SVG]

   <Tav> Is the build publicly available?

   Tav, Dirk sent a link to the build to www-svg and public-fx


     [22] http://lists.w3.org/Archives/Public/www-svg/2012May/0013.html

   <Tav> Oh, I did see that, no Linux build (me sad).


   [discussion about whether you are allowed to have different
   Initial values for transform-origin for SVG and HTML elements]

   <ed> [23]http://dev.w3.org/csswg/css3-transforms/

     [23] http://dev.w3.org/csswg/css3-transforms/

   BB: there's no overlapping syntax that works both in CSS and in
   SVG presentation attributes, because you can't use unitless
   values for say translate() in CSS

   ... and units won't work in existing UAs in the SVG presentation

   Dirk: I could add a note to point out that SVG 1.1 doesn't
   support units in transform=""

   ... we've added >600 tests so far

   ... we've done mainly reftests, but also some JS tests

   VH: a lot of the tests are trying all kinds of units on the
   transform properties

   ... if you test translate with two parameters, if you end up
   testing all units then you end up testing units as much as the
   transform spec itself

   ... how far do you go with these things?

   ... are we really testing transform behaviour here, or the Values
   & Units spec?

   TA: our first several attempt at supporting vw and vh, they
   weren't applied properly in many contexts

   ... so you do want to test that vw and vh work everywhere, just
   in case

   ... drawing a line about what's reasonable to test is kind of

   ... if you're writing reftests, then humans won't be looking at
   it, so better to be exhaustive

   [discussion about whether to use prefixes in WG submitted

   <Tav> We could temporarily use the -prefix-free JavaScript code

   [suggestion of a feature for Shepherd to automatically convert
   tests to use prefixes, so that early testing is possible]



     [24] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_referencing

   BB: we can get Cyril to have a look at it later

   ... at the last F2F we were talking about masks

   ... I raised the issue that when producing content via script,
   the primary way to link masks to targets is by ID references

   ... and when you're doing that via script, you have to generate
   unique IDs

   ... that's a bit of an overhead to have to do this, if all you
   want to do is apply a mask to something from script

   ... it makes the content harder to read too

   ... animations in SVG however you can just have <animate> as a
   child of what you're targetting

   ... so it's easier to produce from script, and reading the source

   ... so I had an action to look into removing that dependency on
   ID references for a number of other parts of SVG

   ... in that wiki page I've got some areas I've identified where
   this could be useful

   ... as well as removing that ID reference, there are some related

   ... the initial discussion came up in the context of allowing
   masks to use the alpha of the mask content

   ... it'd be nice if as we fix this referencing scheme to also
   accommodate the ability to specify how the mask content should
   be used, luminance or alpha

   ... recently on www-svg we were talking about masks for general
   HTML content, whether SVG's masking is suitable for that

   ... you need to wrap the mask content in a <mask> element, but it
   seems useful to be able to point directly to the mask content
   without a surrounding <mask> element

   ... the initial proposal I sent to the list a couple of months
   back is that you have the mask target pointing to the
   definition of the mask

   ... Erik or Cameron suggested to add a "child" keyword to the
   mask property

   ... that would mean find the first child <mask> element and use

   ... we could do something similar for xlink:href=""-dependent
   things: feImage, font-face-uri and textPath

   ... for those we could just have them automatically apply to the
   child if the xlink:href="" is missing

   VH: if you go in that direction, and you have multiple things,
   masking, clipping, etc., and you say "child" and you want
   multiple things

   ... how would you handle that?

   BB: I think it works so far, because it looks for the first
   child element that is a <mask>, or the first that is a
   <clipPath>, so it's clear which you mean

   ... but there is a problem with that if you want to allow
   omitting the wrapping <mask> element

   ... maybe if you use the url() syntax you don't need to point to
   a <mask> element, but with the "child" keyword you would need a
   child <mask> element

   Dirk: it would be good if this could work for fill/stroke, but
   that would get complicated

   ... for fill:child, what does it mean? you might want multiple
   gradients, patterns...

   ... or for fill and stroke

   BB: don't have an answer for that yet

   ... if you have multiple matching children, I currently say to
   use the first one

   ... if we want to support masks allowing alpha instead of
   luminance, we could have an "alpha" keyword in the mask

   [discussion about whether authors actually ever want luminance]

   CM: we could make url() targetting non-<mask> elements assume

   ... or introduce a separate alpha-mask property

   VH: if mask can target <mask>-less elements, then how does the
   coordinate system work?

   CM: just like userSpaceOnUse?

   VH: and take the tight bounds of the element?

   BB: for now I'm just thinking from the perspective of the

   ... if we extend the mask property, is that also going to be
   useful for targetting masks

   Dirk: another alternative, perhaps might break content, <mask>
   could automatically apply to its parent if the parent doesn't
   have "none" as its mask property value

   BB: I mentioned there's a bit of an inconsistency with
   <animate>, but I think it's unavoidable

   ... it currently uses xlink:href to target the thing that's

   ... so we should just forget about trying to be consistent with

   Dirk: I'm not sure I think it is an important use case

   CM: is the biggest problem how to handle fill and stroke here?

   Dirk: probably

   CM: we could have fill="child 2" to select the second possible
   fill element child

   BB: we don't have to solve that right now, but it's an issue to
   be solved
   ... option B, from Cyril

   ... here it would have a target-element property on the child
   element, and it would have either "parent" or "by-reference"

   ... in the example on the page, if that <mask> also had an ID and
   was referenced from some other element, it would look confusing

   ... because it has target-element="parent" on there but the other
   use of the mask is by reference

   BB: the main difference is the first point, whether the link in
   this direction makes sense

   CM: I think A makes more sense than B
   ... we could have the child <pattern> element indicate whether
   it wants to be for the fill or stroke

   ... and then still just have the parent specify mask="child"

   VH: I'd rather have wrapper <fill> and <stroke> elements as
   children of the target

   BB: the other question is whether we stick alpha keywords into
   the mask property, or to have a separate alpha-mask property

   CM: I think I would rather allow "alpha" in the mask property,
   but also be able to specify a type="" on <mask>

   [some discussion about multiple child <mask> elements looking
   like they would all apply to the parent]

   RESOLUTION: <mask> element will gain an attribute to specify
   whether it's alpha or luminance

   <scribe> ACTION: Brian to send an updated mask referencing
   proposal to the list [recorded in

   <trackbot> Created ACTION-3287 - Send an updated mask
   referencing proposal to the list [on Brian Birtles - due

   <scribe> ACTION: Brian to add the SVG2 <mask> element attribute
   to indicate whether it's alpha or luminance [recorded in

   <trackbot> Created ACTION-3288 - Add the SVG2 <mask> element
   attribute to indicate whether it's alpha or luminance [on Brian
   Birtles - due 2012-05-15].

   <ed> -- lunchbreak --

   <ed> scribeNick: ed

Update on SVG-in-OpenType implementation/proposal

   <heycam> [27]https://wiki.mozilla.org/SVGOpenTypeFonts

     [27] https://wiki.mozilla.org/SVGOpenTypeFonts

   CM: a short update on the current implementation work we're
   ... what the actual font is going to look like
   ... last time we discussed there was some issues about how to
   split the glyphs
   ... the current impl allows you to specifity separate documents
   in the font
   ... rather than using glyph elements you can put a glyphid on
   any element in the document
   ... just a numerical id
   ... can be a single character, used with CMAP
   ... or a variant of a character

   jdaggett: you have a base CMAP for mapping it
   ... concerned that you're using it as a private mapping
   ... in css3 fonts i'm definiing how fallbacks are done
   ... if you can't use a particualr font, you'll fallback to
   something else
   ... there's no content that uses it now

   CM: because this proposal relies on CMAP... (missed) VCS

   jdaggett: i'd need to look at the specifics of the proposal
   ... the unicode ppl have allowed a registrry to be created that
   doesn't enforce a way to
   ... CJK, it's important that you have the design of the
   ... you can write using two different syntaxes

   CM: conflicting entries?

   jdaggett: there are separate entries, clear that you're using a
   variation selector by a group
   ... but two values in the same stream map to the same glyph

   rik: fonts can have different CMAPs

   jdaggett: different encodings?
   ... nothing you have different CMAPs that can be arbitrarily
   ... CMAP strucutre is just codepoint to glyph
   ... you can have glyphs that have no mapping in a CMAP
   ... smallcaps for example
   ... problem with the database is that compound have to be aware
   that fonts have one mapping but not the other
   ... maybe fonts will be able to resolve this, that two mappings
   are the same
   ... not always clear to the person designing the font
   ... not always clear which points to the same glyph

   CM: the font designers are making a decision about it

   jdaggett: aren't you allowing arbitrary glyph ids?

   CM: yes
   ... either glyphid or character + variation selector

   jdaggett: for opentype features to work
   ... only way it will work is if you resolve to a glyphid

   CM: it might be simpler to specify as characters rather than

   jdaggett: my point: you should define everything in terms of

   CM: the attributes are in the svg document
   ... main aspects of the proposal, separate the glyphs into
   separate documents so that the whole thing doesn't have to be
   running in the background
   ... all the metrics get deferred to the opentype tables
   ... except for the bbox, which is computed from the svg

   [discussion on bbox and how they're calculated]

   CM: one of the concerns cyrys was meantioning
   ... don't want conflicting information

   jdaggett: is there a wiki defining the format?

   CM: see the link that was pasted in above
   ... text can be stroked and filled, you can get these from the
   referenceing text element
   ... there's a computed strokewidth because the coordinate
   systems are different
   ... in html you might want to access the color property and not
   just the fill and stroke

   TA: maybe outside svg it should treat color as the fill

   CM: no external referecnes allowed, script is disabled, svg
   animations work

   jdaggett: what does bbox mean when you have animation?

   CM: good question

   ED: in normal svg the bbox would just change if you animate

   CM: someone should write up something about this
   ... and post to the opentype-interest community grouo

   <heycam> ACTION: Cameron to raise these issues about
   SVG-in-OpenType and get somebody to write up a proposal to send
   to the CG list [recorded in

   <trackbot> Created ACTION-3289 - Raise these issues about
   SVG-in-OpenType and get somebody to write up a proposal to send
   to the CG list [on Cameron McCormack - due 2012-05-15].

Canvas in SVG

   VH: there were a numer of things on canvas in svg... first
   simpler integration of canvas in svg

   <vhardy_> vwhardy_ has joined #svg

   TA: i was arguing with hixie about it last night
   ... the inclusion of canvas in svg should be relatively easy

   CM: does it require parser changes?

   TA: yes

   DS: does it work for pure svg documents?

   TA: as long as you handle namespaces correctly it should work
   ... once we define if html elements in svg render we'd have to
   think more about it

   DS: just rendering part i have concerns over

   CM: to clarify, in text/html... is it both directions?

   TA: less of a usecase for bare svg elements in html
   ... but for bare html element inside svg is easier

   [discussion of how for unknown elements are rendered]

   CM: it's awkward to specify the namespaces

   TA: you can declare the html namesapce on the root svg and then
   use e.g html:p

   CM: unless there are parser complications i'd prefer if it
   worked in both directions

   TA: there are complications
   ... if we allow it one way there'll be more incentive to allow
   the other direction too

   DS: if you have a p and we render them in svg, we'd need the
   svglocatable interfaces for positioning

   TA: you can assume css transforms would work, from (0,0) and
   then translate to where you want it

   DS: so a <div> would have a css box

   TA: we'd say that the svg layout is composable with the css box
   ... when you nest other layout modes
   ... we could port x and y to be properties, rather than

   VH: could we also say the html elements are positioned in the

   CM: you might nest svg elements to get new viewports and
   intermix with html

   <heycam> <svg><p>..</p><rect/><p>..</p></svg> could render the
   two <p>s as if they are in a containing block defined by the
   <svg>'s viewport

   TA: i'm confident we can come up witha decent model that works

   <heycam> and the <rect/> just gets rendered at its position

   VH: if we decide for general integration
   ... then i'd like to drop the idea of adding the canvas element
   in the svg namespace, same for video and audio

   [discussion of hit-testing on canvas with alphamasks]

   VH: we need to address hit testing

   TA: we could use css inclusions

   VH: third issue is, canvas rendering is happening in the main
   ... we need it isolated into its own thread
   ... without touching the DOM

   CM: wasn't that something being added to web workers?

   TA: not added yet i think, but you can shuffle imagedata back
   and forth

   CM: so just passing the context, not pixels

   VH: we want to give the resulting image to the svg for

   TA: it's not limited to script
   ... it's just to offload the work to a different thread
   ... not sure if it's there yet, we can poke it some more

   rik: isn't chrome alrady doing drawing on a different thread?

   TA: yeah, unless you do image processing on it
   ... embedding canvas would be solved by being able to embed
   html elements directly

   [implementation discussion of canvas gpu rendering and svg

   CM: one thing people wanted was paiting svg subtrees to canvas

   VH: that hit lots of security issues

   CM: good approach with the bare html variant

   <scribe> ACTION: VH to dig out thread on WHATWG on webworkers
   and canvas and comment on it [recorded in

   <trackbot> Created ACTION-3290 - Dig out thread on WHATWG on
   webworkers and canvas and comment on it [on Vincent Hardy - due

   DS: width and height attributes on canvas might be an issue, if
   we wanted to make more thigns properties

   [discussion on p with width and height and how that works]

   TA: if we can convince the htmlwg to add width and height
   attributes to all elements then it might become easier to
   integrate into svg

   DS: just concerned about moving p in or out of svg, if it has
   some special meaning
   ... so it's either supported everywhere or nowhere?

   TA: yes

   VH: svg does abolsute positioning for everything
   ... transforms apply
   ... so transform on a <g> woiuld affect child <div> elements
   for example

   TA: don't think we want to use x,y attributes on some elements
   and top,left on others

   DS: margin gets ignored?

   TA: yes

   VH: just confused about the x,y thing

   TA: we might not need it
   ... direct html children in svg, make svg element block

   VH: g don't have x,y, but it has transform
   ... we have to look at anchoring too, it's very useful
   ... for divs and p's you might want the same
   ... like align to the center of the box

   TA: you could use text-align for that

   CM: yes, i like that, becasue you'd have a css box
   ... can you use calc() values in transforms?

   TA: yes

   CM: could vh refer to the svg viewport?

   TA: at the moment it's the root viewport

   <heycam> ScribeNick: nikos


   CM: SVG spec says to turn off ligatures. Was written before
   ... When you use positioning and second is on text path
   ... some ligatures can't be turned off

   [ discussion on whether you can turn off ligatures ]

   JD: some ligatures are required in Arabic

   CM: I think it should be up to author to turn discretionary
   ligatures on or off - don't see why it should be overwritten

   <Tav> [30]http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html

     [30] http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html

   Tav: firefox uses ligatures on path

   CM: that's using ligature chars in doc not FFI

   JD: rendering path has switches to turn it off

   CM: I'd like to not have that

   JD: what's the point when using text on path

   CM: sometimes you have straight line segments where it is

   Tav: See example I posted - there's some that look ok

   CM: Even without warping, just position of points where glyphs
   get rendered. I'd like to have control

   JD: don't see a problem with existing spec saying it's off in
   some situations, but allowing it to be forced on

   CM: how do you force on if you have letter spacing

   JD: 3 browsers now support font feature settings, you use

   CM: sufficient to allow font-variant-settings to override svg's

   JD: in CSS, normal is to use opentype defaults. it's
   essentially a no-op
   ... if you use normal you get existing behaviour

   CM: next is pseudo elements should ::before and ::after apply

   ED: you could only use it on tspans

   CM: and text is ok

   TA: before and after means before and after first and last
   child of the element
   ... there are problems with x and y right?

   CM: I'd rather it applied to the glyphs that correspond to the
   characters in the DOM?

   TA: in that case how do you apply before and after

   CM: it's tricky to apply x
   ... if you're using just x=10, no multip-le positions
   ... first is ltr, then rtl
   ... x=10 correpsonds to ltr which is going to be in middle
   ... after you do positioning, then shift the whole chunk
   because you have anchoring to x

   [TA drawing an example]

   [consensus is that the text, with the before and after applied,
   is anchored to the x values given]

   CM: does anyone like it and think it should apply?

   ED: I'd like to see more detail

   CM: ::first-line and ::first-letter are simpler. I think we
   should do it
   ... first letter you can put colour and font size but you can't
   put fill

   TA: That's because it is designed for CSS. should be fine for

   CM: vertical-align - we have baseline-shift, and css3-line
   makes vertical-align:<length> be a shorthand for
   ... we should move towards properties that CSS has for line box


   CM: text-shadow?
   ... should it apply to svg text
   ... if you use it on a clip path it has no effect

   TA: clip path is geometry based

   DS: masks are different

   VH: webkit does it properly. it has a shadow on the text if you
   stroke the text

   CM: that will need to be defined somewhere. is it worth having
   in CSS spec?

   TA: yes

   ED: makes sense

   <scribe> ACTION: Cameron to mail CSS list regarding text-shadow
   [recorded in

   <trackbot> Created ACTION-3291 - Mail CSS list regarding
   text-shadow [on Cameron McCormack - due 2012-05-15].

   <ed> -- 15min break --

   CM: vertical-align - we have baseline-shift, and css3-line
   makes vertical-align:<length> be a shorthand for
   ... According to whats in the CSS3 line box spec currently we
   won't have a problem having svg text use vertical align and
   other properties
   ... But spec may be subject to change so we should try to find
   out if this will have an effect

Future F2F meetings

   DS: 23-25 July is F2F in seattle

   CM: we may attempt to co-locate in Paris

   VH: I can't attend on 23 and 24th in US but I might be able to
   in Paris

   DS: we have an Adobe office in Paris

   VH: Don't think we can book 2 different offices at Adobe - it's
   extra overhead
   ... if Cyril can organise something at Paris, that would be

   CM: we also have to discuss Zurich
   ... ED and I were wondering if we should allocate time to have
   a working meeting and push editing along, what are peoples
   thoughts? is it a waste of time to travel for that?

   VH: I think a 2 day hackathon would be good

   CM: this is in Seattle

   DS: How many days for organisation?
   ... I'll create a wiki page for the Seattle/Paris meeting
   ... Will co-ordinate with Cyril to see if Paris is possible,
   and test videoconference equipment.

   <ed> SVG Open - September 11 to 14, 2012

   CM: For Zurich, CSS group is also considering meeting there

   ED: Do we have it before or after?

   VH: after is preferable

   ED: How many days?

   CM: 3

   ED: 17th-19th will be the dates

   CM: We aren't planning on meeting as a whole group at TPAC. But
   whoever is there should be available for a meet up.
   ... I'll mail Andreas to let him know dates

   DS: times for Seattle will be 7am-3pm

   CM: France will be evening (until midnight)

SVG 2 Requirements


     [32] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Late_Proposed_Requirements

   CM: First is array element


     [33] http://lists.w3.org/Archives/Public/www-svg/2011Dec/att-0021/00-part

   CM: from description it sounds like it's similar to David's
   replicate proposal
   ... 3rd dot point sounds like something we could handle with
   ... now that we have ability to do markers every x pixels

   Tav: we already agreed we'd allow placement of objects along a

   CM: I wonder whether the marker stuff we were talking about
   yesterday could be a solution for that

   Tav: I think you'd need an offset

   CM: along the path or perpendicular?

   Tav: perpendicular


     [34] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Define_.3CshapePath.3E_element

   CM: I guess you could design marker so reference point is below
   graphical content

   Tav: Don't think anyone has agreed to work on it

   CM: it seems like there would be a fair degree of overlap
   between the shape path element and the new style markers
   ... ideally we'd have one thing that would provide the
   ... some of those dot points, I'm not sure what they'd entail
   ... It's 43 on our list of commitments. Has Doug with a
   question mark listed.
   ... I'll talk to doug and see how well it fits with the marker
   ... The other 2 points of the request sound like replicate
   where you move through space and instantiate objects repeatedly

   Tav: We decided to not do replicate

   CM: First one - rectangular array. You could do that with the
   new markers. have a path with a number of subpaths that are
   straight lines and put markers on those

   [ discussion on whether you can achieve this with use elements]

   Tav: We have a google SOC intern working on it. You can say for
   every row or column, change the hue by a certain percentage, or
   a random change

   CM: My initial inclination is to say no because it sounds like
   it's similar use cases to the replicate thing

   Resolution: We won't accept the array element proposal

   CM: Next requirement is Half-tone (Screening/Pattern filter)

   Tav: This is the one I'm interested in
   ... This was proposed by the person who did the canned filters
   in Inkscape. Didn't seem interesting to start with. Wanted a
   filter to do newspaper screening.
   ... They're actually very complicated
   ... Circles aren't circular but as they grow they morph into
   more of a diamond shape when it's 50% grey and then a white
   circle in a black square when you get to darker grey
   ... It's interesting but I don't think it's worth an entire
   ... If you go further and look at what else you can do, i.e.
   stipling, then you can do some nice effects
   ... You can do this in SVG currently but you must create
   thousands of clones
   ... For a filter you could specify an algorithm. Similar to the
   turbulence filter

   CM: I wonder if it makes sense to have a primitive feRandom
   that takes a seed

   TA: How would you plug that into the various things
   ... it's not an image its a number source

   CM: those numbers would be mapped into colours

   Tav: You can place symbols based on a gradient or image. See
   lake example. Probability of grass depends on gradient.
   ... final example is Pointillism. It has 22000 circles so it's
   not something you can do practically with clone.

   CM: what do you get when you save it with Inkscape?

   Tav: 22000 use elements
   ... My point is there's lots of interesting effects you can do
   with this filter primitive

   CM: can you do the newspaper one with different shaped dots?

   Tav: you could define them as a parameter

   CM: I think you could select without built in newspaper
   functionality, just 3 instances of the filter primitive
   ... If we wanted to avoid having the newspaper as a specific
   type. I think you could take primitives similar to later
   examples on the page

   Tav: quality wouldn't be quite so good but you could

   RC: too bad we had to change CSS shaders because you could do
   it with that
   ... you divide using a grid and look at each part
   ... You can't read the colour value due to security

   CM: so what's the input then?

   RC: input can be a texture but in general you'd want it to be
   something that's already drawn

   CM: I'm in favour of this
   ... This would go in filter spec not in SVG2

   VH: I can take an action with Tav to work out where it would
   make sense to use shaders

   Tav: My concern is I'm not sure how easy it would be for
   Inkscape to use shaders.
   ... we're not using the GPU now for anything

   CM: to me it fits well as a built in primitive

   <scribe> ACTION: Tav to write a filter primitive proposal
   [recorded in

   <trackbot> Created ACTION-3292 - Write a filter primitive
   proposal [on Tavmjong Bah - due 2012-05-15].

   CM: this isn't a requirement but it's something we will look
   ... I don't think that if its possible to do with shaders that
   we shouldn't add a primitive

   Resolution: We won't require screening filter primitives for
   svg 2 but we will look into it for filter spec

   CM: Next is Multipage support

   Tav: This one came from me when I went out to see what people
   ... it's something our users would like to see
   ... it was in svg 1.1 proposal at some point

   CM: i'd be interested in finding out if we can use CSS print
   stuff to use multiple pages for svg

   AD: we've had interest in this over the years but never got
   traction. With CSS it might work but as a straight svg thing I
   don't think it will work.

   Tav: my impression in the past was it was too complex

   AD: if printing people don't do it I don't know if there's any
   chance in a browswer


   AD: EPUB 3 you can have svg as root of a page and several pages

   CM: I'd be interested in seeing how the CSS stuff could apply
   to SVG

  TA: answer is very lightly
   ... a lot depends on breaking a line and shifting rest to the
   next page and that's nonsense for svg

   CM: there's some properties to start a page at a particular
   point. you could do that with groups as pages

   TA: that works with css flow, but not absolute positioning,
   which is what svg deos


   CM: if you have absolute with multipage

   TA: it's measured from top of the screen (first page)
   ... most of multi page stuff relies on the flow
   ... if you overflow in perpendicular direction of flow then
   it's undefined

   Tav: I think what people using Inkscape are thinking about is
   presentation. where one group is background and another group
   is a page using that background.

   TA: Better to do that in HTML because that's what it's good at

   Tav: I think you're misunderstanding. It's like having layers.
   Using groups as layers.
   ... It's for presentations on screen. Each layer is a slide.

   CM: I think people were thinking of pages as being on paper.
   ... If you want to do that with HTML you use some script to
   show and hide elements
   ... colon target?

   TA: It's also similar to a display stack proposal I have on my
   blog. Given lots of children you only display one at a time.

   Tav: Yeh that's what they want but with a background slide and
   possibly page numbering.
   ... In Inkscape there's an extension that does this but it
   requires a lot of Javascript.

   TA: you can do it with zero Javascript if you use the target
   pseudoclass and hash links to change between slides

   <ed> [36]http://simurai.com/post/20251013889/svg-stacks

     [36] http://simurai.com/post/20251013889/svg-stacks


     [37] http://dahlstr/


     [38] http://dahlstr/

   RC: looking at the bugs, it does seem like people want multiple
   sheets of paper, pages are getting used to mean different

   CM: How averse you to small amount of script? If you're not
   it's solved already.

   <Tav> Can't call back in as conference is now restricted....

   TA: You should be able to use access keys to navigate slides
   with no script

   Tav: I'll get back to those that have complained about this and
   see what they thyink


   CM: We should merge things from a element anyway
   ... Next is Variable stroke opacity

   ED: is there a proposal? There's no links.

   CM: at one level, we discussed that it's possible to do this
   with patches

   TA: Yuk. Humans can't do that

   Tav: Even authoring tools can't do it nicely

   AD: variable stroke opacity is very complex. No one will
   implement it.

   <ed> (this requirement was split off from the inkml requirement

     [39] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups)

   RC: Illustrator has it. Exporting to any other format is

   AD: you don't rasterise a stroke along normal to the path. You
   generate and fill a polygon. So filling algorithm must go
   perpendicular to the path.

   [discussion on how implementations do paths]

   Tav: Does this apply to the "Gradient along/across stroke "
   requirement too?
   ... Illustrator has it

   TA: Yes it's equally difficult

   CM: Any plans to implement it in Inkscape?

   Tav: not at the moment

   RC: It's so difficult

   Tav: We'd have to save it as svg as that's our format

   CM: I'm inclined to say too difficult for now, especially as
   it's late and we have a lot to do.
   ... If it's implemented in Inkscape and you can provide
   feedback on difficulty maybe we can look at it again

   Resolution: No Variable stroke opacity or Gradient along/across
   stroke in SVG 2

   CM: Final requirement is New Stroke Join

   Tav: it's basically a variable width stroke done as an effect
   ... in svg file in Inkscape namespace we define a path and in
   svg namespace you get a shape
   ... at the moment you have 3 choices, flat, miter and round
   ... we implemented 2 more choices, one uses extrapolated tracks


     [40] http://wiki.inkscape.org/wiki/index.php/File:LGM2012_-_Powerstroke.pdf

   Tav: look at the eighth slide

   CM: looks good on the sharp corner

   Tav: it's taking the current curvature at the point of the path

   CM: and just drawing an arc?

   Tav: there's no picture of the Spiro

   CM: I'd be ok with it as it doesn't seem too hard to implement

   VH: it doesn't seem easy in all cases
   ... libraries don't give you the control to do this

   CM: library would have to change

   VH: a lot of implementations wouldn't have access

   ED: what happens if the curves never converge?

   TA: you could fall back if you exceed some threshold

   CM: what should we do with the requirement

   AD: need to look at the details of implementation

   Tav: Extrapolated is just an arc
   ... Spiro has a derivative but I'm not suggesting we support

   AD: We need to see the maths

   VH: agree

   <scribe> ACTION: Tab to work out the details of the
   extrapolated stroke join [recorded in

   <trackbot> Created ACTION-3293 - Work out the details of the
   extrapolated stroke join [on Tab Atkins Jr. - due 2012-05-15].

   VH: We're expanding with new segments - what are those

   TA: they are arcs

   CM: there's 2 problems that people have. 1. the details should
   be written down
   ... 2. Graphics libraries need to support this.
   ... I think most of the reason VE haven't made much progress is
   because of this

   Resolution: Look at this again once Tab completes ACTION 3293

   <tabatkins__> This page contains all the necessary math to do
   the extrapolated joins:


     [42] http://tutorial.math.lamar.edu/Classes/CalcIII/Curvature.aspx

   <tabatkins__> Instantaneous curvature is just dT/ds, where T is
   the unit tangent and s is the path length.

   <tabatkins__> And all of SVG's curves can be easily recast into
   forms that make this easy to calculate.

   <tabatkins__> Then producing an arc of a given curvature is

Summary of Action Items

   [NEW] ACTION: Brian to add the SVG2 <mask> element attribute to
   indicate whether it's alpha or luminance [recorded in
   [NEW] ACTION: Brian to send an updated mask referencing
   proposal to the list [recorded in
   [NEW] ACTION: Cameron to mail CSS list regarding text-shadow
   [recorded in
   [NEW] ACTION: Cameron to raise these issues about
   SVG-in-OpenType and get somebody to write up a proposal to send
   to the CG list [recorded in
   [NEW] ACTION: Tab to work out the details of the extrapolated
   stroke join [recorded in
   [NEW] ACTION: Tav to write a filter primitive proposal
   [recorded in
   [NEW] ACTION: VH to dig out thread on WHATWG on webworkers and
   canvas and comment on it [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [50]scribe.perl version
    1.136 ( [51]CVS log)
    $Date: 2012/05/08 14:56:26 $

     [50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [51] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at

     [52] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CBAdef/ABCdef/
Succeeded: s/???:/birtles:/
Succeeded: s/ab/abc/
Succeeded: s/prserbe/preserve/
Succeeded: s/xml whitespace/xml:space/
Succeeded: s/so we want to be compatible with exiting content/so there'
s nothing in the proposal that maps xml:space=default to something in t
he white-space property? just thinking about backwards-compat with exit
ing content/
Succeeded: s/parent/child/
Succeeded: s/<as,//
Succeeded: s/vh/vwh/
FAILED: s/browswer/browser/
FAILED: s/deos/does/
FAILED: s/thyink/think/
Found ScribeNick: krit
Found ScribeNick: heycam
Found ScribeNick: ed
Found ScribeNick: nikos
Inferring Scribes: krit, heycam, ed, nikos
Scribes: krit, heycam, ed, nikos
ScribeNicks: krit, heycam, ed, nikos
Default Present: +49.403.063.68.aaaa, Tav
Present: +49.403.063.68.aaaa Tav

WARNING: Fewer than 3 people found for Present list!

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL:
People with action items: brian cameron tab tav vh

     [53] http://www.w3.org/2012/05/08-svg-minutes.html

WARNING: Possible internal error: join/leave lines remaining:
        <vhardy_> vwhardy_ has joined #svg

WARNING: Possible internal error: join/leave lines remaining:
        <vhardy_> vwhardy_ has joined #svg

WARNING: IRC log location not specified!  (You can ignore this
warning if you do not want the generated minutes to contain
a link to the original IRC log.)

   End of [54]scribe.perl diagnostic output]

     [54] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Tuesday, 8 May 2012 15:00:30 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:51 GMT