« Return to Thread: Minutes, Hamburg 2012 SVG WG - Day 2

Minutes, Hamburg 2012 SVG WG - Day 2

by Nikos Andronikos :: Rate this Message:

| View in Thread

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

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

[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

<ed>

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

[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

[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

[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

[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

[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

[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

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

« Return to Thread: Minutes, Hamburg 2012 SVG WG - Day 2