- 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:
http://www.w3.org/2012/05/08-svg-minutes.html
As text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
08 May 2012
Attendees
Present
+49.403.063.68.aaaa, Tav
Regrets
Chair
ed
Scribe
krit, heycam, ed, nikos
Contents
* [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
__________________________________________________________
<ed>
[14]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Age
nda
[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
<ed>
[15]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layou
t
[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
case
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)
way
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
variabels
... you would have to be very intelligent to knowing all
vairables
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
positioning
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.
position
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
future
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
bc</text>
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">
abc
def</text>
a and d would be aligned vertically
abc
def
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
possible
<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
attributes
... I come up with a lit of properties that we should have.
<ed> Text decoration rotation
text decoration
<text text-decoration="underline">
<ed>
[19]http://lists.w3.org/Archives/Public/www-svg/2011May/0141.ht
ml
[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
<ed>
[20]http://www.w3.org/TR/SVG11/text.html#TextDecorationProperti
es
[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/03b878488aa1ec8
bebb44e2baec36f64.jpg
[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
attribute
... 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
property
... 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
attribute
... the current interface can't represent transform values with
units
... or the new transform function types
... for new types, we can just expose them as "unknown" transform
types
... 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.ht
ml
[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
attribute
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
hard
... 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
tests]
<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]
masking
<ed>
[24]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_r
eferencing
[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
things
... 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
that
... 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
property
[discussion about whether authors actually ever want luminance]
CM: we could make url() targetting non-<mask> elements assume
alpha
... 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
ID-referencing
... 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
animated
... so we should just forget about trying to be consistent with
that
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"
values
... 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
[25]http://www.w3.org/2012/05/08-svg-minutes.html#action01]
<trackbot> Created ACTION-3287 - Send an updated mask
referencing proposal to the list [on Brian Birtles - due
2012-05-15].
<scribe> ACTION: Brian to add the SVG2 <mask> element attribute
to indicate whether it's alpha or luminance [recorded in
[26]http://www.w3.org/2012/05/08-svg-minutes.html#action02]
<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
doing
... 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
glyph...
... 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
selected
... 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
glyphs
jdaggett: my point: you should define everything in terms of
glyphids
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
things
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
[28]http://www.w3.org/2012/05/08-svg-minutes.html#action03]
<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
model
... when you nest other layout modes
... we could port x and y to be properties, rather than
top,left
VH: could we also say the html elements are positioned in the
viewport
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
well
<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
thread
... 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
composting
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
compositing]
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
[29]http://www.w3.org/2012/05/08-svg-minutes.html#action04]
<trackbot> Created ACTION-3290 - Dig out thread on WHATWG on
webworkers and canvas and comment on it [on Vincent Hardy - due
2012-05-15].
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
container
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
text
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
reasonable
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
font-feature-settings
CM: sufficient to allow font-variant-settings to override svg's
default
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
SVG
CM: vertical-align - we have baseline-shift, and css3-line
makes vertical-align:<length> be a shorthand for
alignment-adjust:<length>
... we should move towards properties that CSS has for line box
text-shadow?
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
[31]http://www.w3.org/2012/05/08-svg-minutes.html#action05]
<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
alignment-adjust:<length>
... 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
good
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
<heycam>
[32]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Late_Proposed_Requirements
[32] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Late_Proposed_Requirements
CM: First is array element
<heycam>
[33]http://lists.w3.org/Archives/Public/www-svg/2011Dec/att-002
1/00-part
[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
markers
... now that we have ability to do markers every x pixels
Tav: we already agreed we'd allow placement of objects along a
path
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
<Tav>
[34]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Define_.3CshapePath.3E_element
[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
functionality
... 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
thing
... 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
filter
... 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
[35]http://www.w3.org/2012/05/08-svg-minutes.html#action06]
<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
into
... 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
wanted
... 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
s/browswer/browser
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
s/deos/does
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
<ed>
[37]http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#pl
us
[37] http://dahlstr/
<ed>
[38]http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#ch
art
[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
things
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....
argh.
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
s/thyink/think
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_In
put#Display_of_InkML_trace_groups)
[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
terrible.
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
<Tav>
[40]http://wiki.inkscape.org/wiki/index.php/File:LGM2012_-_Powe
rstroke.pdf
[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
that
AD: We need to see the maths
VH: agree
<scribe> ACTION: Tab to work out the details of the
extrapolated stroke join [recorded in
[41]http://www.w3.org/2012/05/08-svg-minutes.html#action07]
<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:
<tabatkins__>
[42]http://tutorial.math.lamar.edu/Classes/CalcIII/Curvature.as
px
[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
trivial.
Summary of Action Items
[NEW] ACTION: Brian to add the SVG2 <mask> element attribute to
indicate whether it's alpha or luminance [recorded in
[43]http://www.w3.org/2012/05/08-svg-minutes.html#action02]
[NEW] ACTION: Brian to send an updated mask referencing
proposal to the list [recorded in
[44]http://www.w3.org/2012/05/08-svg-minutes.html#action01]
[NEW] ACTION: Cameron to mail CSS list regarding text-shadow
[recorded in
[45]http://www.w3.org/2012/05/08-svg-minutes.html#action05]
[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
[46]http://www.w3.org/2012/05/08-svg-minutes.html#action03]
[NEW] ACTION: Tab to work out the details of the extrapolated
stroke join [recorded in
[47]http://www.w3.org/2012/05/08-svg-minutes.html#action07]
[NEW] ACTION: Tav to write a filter primitive proposal
[recorded in
[48]http://www.w3.org/2012/05/08-svg-minutes.html#action06]
[NEW] ACTION: VH to dig out thread on WHATWG on webworkers and
canvas and comment on it [recorded in
[49]http://www.w3.org/2012/05/08-svg-minutes.html#action04]
[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/
[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:
[53]http://www.w3.org/2012/05/08-svg-minutes.html
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 UTC