<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
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/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 text-decoration="underline">
<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
<heycam> ScribeNick: heycam
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]
<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
<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].
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
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
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)
<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.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/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 the white-space property? just thinking about backwards-compat with exiting 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: http://www.w3.org/2012/05/08-svg-minutes.html People with action items: brian cameron tab tav vh 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 scribe.perl diagnostic output]