SV_MEETING_TITLE -- 08 May 2012

<ed> 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> 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> http://www.w3.org/TR/CSS21/text.html#white-space-prop

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

<ed> 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> 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: 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

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> 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> 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 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 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> 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 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 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> 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 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> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Late_Proposed_Requirements

CM: First is array element

<heycam> 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> 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 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> http://simurai.com/post/20251013889/svg-stacks

<ed> http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#plus

<ed> http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#chart

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

- DRAFT -

SV_MEETING_TITLE

08 May 2012

Attendees

Contents

text layout proposal

text decoration

CSS3 transforms

CSS Transforms

masking

Update on SVG-in-OpenType implementation/proposal

Canvas in SVG

text

Future F2F meetings

SVG 2 Requirements

Summary of Action Items

Scribe.perl diagnostic output