http://www.w3.org/2010/09/06-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
06 Sep 2010
See also: [2]IRC log
[2] http://www.w3.org/2010/09/06-svg-irc
Attendees
Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cyril, anthony, Jonathan Watt
Contents
* [3]Topics
1. [4]ISSUE-2368
2. [5]CSS Transitions and Animations
3. [6]paint servers
4. [7]Demos
5. [8]Font description features
6. [9]HTML + SVG in no-HTML User Agents
7. [10]Shape path
8. [11]Path on a path
9. [12]Spiros
10. [13]2D-transforms
11. [14]Connectors
12. [15]SVG points
* [16]Summary of Action Items
_________________________________________________________
<trackbot> Date: 06 September 2010
ISSUE-2368
<cyril> ISSUE-2368?
<trackbot> ISSUE-2368 -- Problems with grammars for numbers --
raised
<trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2368
[17] http://www.w3.org/Graphics/SVG/WG/track/issues/2368
<cyril> CC: I think the BNF grammar for points and paths has a bug
<cyril> ... missing '?' after the exponent
<cyril> ... and also is not correclty aligned with the <number>
datatype
<cyril> ... which does not allow integer followed by just a '.'
without digits
<cyril> ... I propose to merge the datatype definitions
<cyril> ED: agreed
<cyril> ACTION: Cyril to propose new wording for the spec for
ISSUE-2368 [recorded in
[18]http://www.w3.org/2010/09/06-svg-minutes.html#action01]
<trackbot> Created ACTION-2843 - Propose new wording for the spec
for ISSUE-2368 [on Cyril Concolato - due 2010-09-13].
<cyril> scribe: Cyril
<scribe> scribenick: Cyril
CSS Transitions and Animations
ED: let's start with transitions
DS: that's a higher priority
ED: Mozilla implements transitions on SVG properties
... ?
... Can you do paint server animations ? gradient interpolations ?
JW: WE implement animation on anything that's a CSS properties I
would think
... we cannot animate attributes that are not CSS
DS: we should ask the CSS WG to consider transitions to apply to
attributes in SVG
<ed> [19]http://dev.w3.org/csswg/css3-transitions/
[19] http://dev.w3.org/csswg/css3-transitions/
ED: there is a transition-property property, maybe there should be a
transition-attribute property
<ed> DS: or perhaps the transition-property should handle both
attributes and properties
<scribe> ACTION: Doug to contact the CSS WG about a
transition-attribute property or equivalent [recorded in
[20]http://www.w3.org/2010/09/06-svg-minutes.html#action02]
<trackbot> Created ACTION-2844 - Contact the CSS WG about a
transition-attribute property or equivalent [on Doug Schepers - due
2010-09-13].
CC: Can you start a CSS transition interactively ?
ED: sort of ...
... you'd have to change the class name based on a click
... the CSS animation module spec is a bit more advanced, covers
more functionnality
... we need to spell out somewhere how the CSS transition/animation
model fits with the SMIL sandwich model
<scribe> ACTION: Erik to see what implementations are doing with
regards to CSS transitions and SMIL sandwich models [recorded in
[21]http://www.w3.org/2010/09/06-svg-minutes.html#action03]
<trackbot> Created ACTION-2845 - See what implementations are doing
with regards to CSS transitions and SMIL sandwich models [on Erik
DahlstrÃ¶m - due 2010-09-13].
ED: I have examples mixing CSS animations/transitions and SMIL
animations
AD: we treat the CSS animation/transition as a single interval in
the SMIL timing sandwich model
... when the CSS animation begins it goes on top of the sandwich
CC: what about the additive behavior
AD: we have to pick a default behavior for CSS animations
... probably additive
CC: what happens when a property is animated on a g element with CSS
and is inherited by a child element
... does it behave as if it was animated using SVG animations
JW: Mozilla does not support CSS transitions of CSS gradients
<ed> [22]http://dahlstrÃ¶m.net/svg/css3/transitions/
[22] http://dahlstr/
ED: CSS transitions of CSS gradients is complex because you have to
fetch gradients and do the animation properly if they have the same
number of stops
DS: I'm worried about the schedule of implementations
... I wouldn't be surprised if the next versions of browsers include
transitions
... we need to check this issue carrefully
... but there doesn't seem to be recent editing activity
... implementations seem to be moving forward regardless of the
progress of the spec on the Rec track
... so this is problematic from a coordination view point because
unless the spec is updated the implementations will only match the
current draft not what is the best for SVG and HTML
AD: I created an ISSUE-2369
ISSUE-2369?
<trackbot> ISSUE-2369 -- Define CSS3+SMIL behaviour for 'inherit' --
raised
<trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2369
[23] http://www.w3.org/Graphics/SVG/WG/track/issues/2369
JW: it may not be problematic for mozilla's implementation because
we use a moz prefix
DS: it depends on how quickly you can update that
... we should schedule an FX call on this issue
ED: we need to prepare a clear agenda and material
DS: we need 1) an analysis of transitions and how it should affect
SVG, we need to publish that on a wiki
... 2) pointing the CSS WG to that and then make an FX call
... Who's prepared to make this analysis
... ?
CC: there are 2 points: the timing issue and the inherit issue
ED: I'm interested into it
<scribe> ACTION: Erik to prepare a draft about the relationships
between CSS transitions and SVG [recorded in
[24]http://www.w3.org/2010/09/06-svg-minutes.html#action04]
<trackbot> Created ACTION-2846 - Prepare a draft about the
relationships between CSS transitions and SVG [on Erik DahlstrÃ¶m -
due 2010-09-13].
DS: I don't think CSS animations is that urgent
ED: I don't know well enough about it
paint servers
TB: we would like to see mesh gradients
... matching the PDF version so that you can export easily
AD: that is a good idea
ED: me too
TB: we don't have a spec yet
... The litterature has 4 types of mesh gradients
... one of them is Coons patch
... the formula's in the Adobe spec
AD: I see the Coons patch was formulated in 1967
... is a great candidate for inclusion in SVG
CC: VRML also has a mesh gradients, it was specified in 1997
ED: everyone agrees that it's nice to have
AD: yes
... we need a draft of specification (syntax ...)
<scribe> ACTION: Tav to draft report on Coons patches [recorded in
[25]http://www.w3.org/2010/09/06-svg-minutes.html#action05]
<trackbot> Created ACTION-2847 - Draft report on Coons patches [on
Tavmjong Bah - due 2010-09-13].
DS: I always wanted to have a gradient along a path (spline
interpolated gradient)
... this is a precursor for diffusion curves
TB: someone wanted to have a spiral gradient
AD: what is the use case ? who would use it ?
AG: I see a use case for a black to white gradient along a path
AD: once you have the idea for spline interpolation, you can use the
whole path syntax
... you're actually talking about a gradient that is normal to the
tangent of the path
TB: what do you do at sharp corners
AD: there are also issues when the path is self intersecting and if
there are are many tangents at a given point of the path
... someone has to do some research on these aspects
DS: from an authoring view point, it would be cool and useful for
diffusion curves
AG: Tav, did you have feedback on diffusion curves from the Inkscape
community
TB: not that I have seen on the mailing list, but there are other
forums that I don't monitor
ISSUE: Investigate gradients along a path for SVG 2
<trackbot> Created ISSUE-2370 - Investigate gradients along a path
for SVG 2 ; please complete additional details at
[26]http://www.w3.org/Graphics/SVG/WG/track/issues/2370/edit .
[26] http://www.w3.org/Graphics/SVG/WG/track/issues/2370/edit
AG: we are still looking at the diffusion curves and I'll have some
report soon
DS: CSS allows image as a paint server
AD: I would like to have a video as a paint server
CC: that's called texture mapping
ED: currently, we could do it with a pattern but we could extend it
or change it so that if a fill points to an image or video element,
you basically generate that as a pattern
AD: it could be using object bouding box
ED: but we have to look at image or video at the native resolution
DS: SVG introduced a bad designed by forcing everything that is
referenced to use an element (marker, clipPath ...)
... use and symbol break this design and that's good
... those specialized element give you only the viewpoint
... but that could be defined generally
AD: in XPS there is a concept of a brush
... the brush can be an image, a gradient, a video ...
... GDI works the same
DS: that's a good idea
ISSUE: Allow paint servers to reference images and videos
<trackbot> Created ISSUE-2371 - Allow paint servers to reference
images and videos ; please complete additional details at
[27]http://www.w3.org/Graphics/SVG/WG/track/issues/2371/edit .
[27] http://www.w3.org/Graphics/SVG/WG/track/issues/2371/edit
TB: we also talked briefly about the hatching
... some inkscape users would be interested into that
... patterns have problems in the connecting of two patterns
AD: Andreas Neumann mentionned some interesting hatching used in
HP-GL
... I have open sourced an implementation of HP-GL on the web
DS: is the technology royalty free
AD: HP-GL is more than 20 years old
ISSUE: Investigate hatching for SVG 2
<trackbot> Created ISSUE-2372 - Investigate hatching for SVG 2 ;
please complete additional details at
[28]http://www.w3.org/Graphics/SVG/WG/track/issues/2372/edit .
[28] http://www.w3.org/Graphics/SVG/WG/track/issues/2372/edit
AD: www.ishtek.com/hpgl2.htm
<anthony> Scribe: anthony
<scribe> ScribeNick: anthony
Demos
DS: Andrew Matseevesky
... showed me this demo
... during the conference I showed catmull-ron curves
... and he suggested an alternative way to do the curves
... This is a basic thing
... [Shows demo using Andrew's drawing tool]
... He calculates the control points on the spline itself
AD: What's the technique?
DS: Squares are the end points
... and the circles are control points
CC: What order?
AD: Is it putting an artificial point on a path
... looks like knots
TB: The control points can't be on the path
DS: Sorry, the handles are on the path
... he suggested instead of catmull-ron curves
... that you could basically break up a path into
... multiple points
... other people understood the maths
... I couldn't understand the maths
... other thing I wanted to show
... was his method of painting gradients
... first click fills the area
... second click adds colour to the original fill to create the
gradient
... subsequent clicks adds a new colour
... not sure if that is approximating something
... This is sort of like a mesh gradient
CL: Seems to be building one up on the fly
DS: Not sure if it's interesting from an SVG point of view
JW: I'm not getting it from the point of view of an author how you
would predict it's behaviour
AG: Particularly for animation
... you lay these things down
... then animate it
... might get an unknown result
AD: Need to figure out what editors export and draw
... and support those
... things like diffusion curves are really neat but might be able
to do the same things using other technologies
DS: Thing is you can't have hit testing on diffusion curves because
they make up a shape
CL: I always thought of them as a paint server
... just seemed easier to clip
... much easier to cut out the shape than keep inside the line
DS: It's a singular paint server for a single element
... mesh gradients can be applied to multiple points
AG: Could use SVG point for mesh gradient
<scribe> ACTION: Alex to Implement trimesh gradients using phong
shading model [recorded in
[29]http://www.w3.org/2010/09/06-svg-minutes.html#action06]
<trackbot> Created ACTION-2848 - Implement trimesh gradients using
phong shading model [on Alex Danilo - due 2010-09-13].
Font description features
CL: Related to CSS3
... how the changes between CSS effects us
... and what things you'll be able to do and not be able to do
anymore and stuff
... So CSS2 had 3 things you could with fonts
... you could intelligently match on their characteristics rather
than the name
... the second one was synthesis
... i.e. make me a font with certain characteristics
... the third one was download
... SVG 1 dropped the first two
... and just supported download
... CSS2.1 dropped all of them
... CCS3 makes the same choices that SVG did
... i.e. only supports download
... but does make some changes
... the way that small caps are specified
... has changed
... all the implementations faked up small caps
... CSS3 talks about platform limitations
... that need to be taken into account
... which is the weight of the fonts
... One of the Windows APIs (GDI) insist that all fonts have two
weights
... instead of multiple weights
... so if you have a font with 6 weights, you will still only get
two
JW: Does DirectWrite support more than two weights?
AD: Yes
CL: Firefox has a new font engine that's currently switched off
... One of the changes in CSS3 fonts is when you write an @font-face
weight, the weight gets used
... [show's demo]
... Notice that this is a font with four different weights
... and this is Windows XP
CC: Viewer?
CL: Firefox minefield
... this font family has the weights
... CSS says how you handle the weights
... it's allocated the weights
... that's using @font-face
... so using the fonts used on my system
... only get two weights
... instead of four
... so we should align with this
... exactly and completely
DS: To that end, should we simply reference that?
CL: We have an XML syntax
... but we could do some sort of normative reference
... Straight into stylistic sets now
... same font with same text
... have different style types on the letters
... it's an OpenType feature
... still searchable
... still the same text
... and the fall back is the same line
... this is discretionary ligatures
... here is one where there are small letters tucked into other
letters
... Swash forms
... when it has more space it does different swash
... the fall back is again the top line
CC: What is the syntax?
CL: Syntax is currently under discussion in the CSS Working Group at
the moment
TB: Mozilla supports ligatures?
CL: Yes
TB: Inkscape puts the ligatures in, but they don't come up
JW: We should look into that
DS: Could be a bug. I know cases where ligatures disappear when you
put them on a path. Even on straight path
CL: My proposal is we align completely with what CSS3 Fonts says
... I'd be prepared to do any editing work necessary
DS: This is for SVG 2 or 1.1?
CL: Just SVG 2
AG: I'm happy with it
AD: Ok, makes sense
DS: ooo and ahhhhh
... Enthusiastic agreement
RESOLUTION: We agree that in SVG 2 we will completely align with CSS
3 Fonts
HTML + SVG in no-HTML User Agents
DS: There are three basic ideas:
... one is SVG shouldn't have text wrapping
... second position should have basic word wrapping
... third is SVG should not rely on HTML to do any word wrapping
CL: The second point could be broken up
... it was more about the formatting
... rather than the markup
JW: Might be time to rethink the box model
... need be able to handle shapes that are not box model
... need to talk to people in Mozilla
AD: One thing is need to think about the pure SVG world
... such as IPTV
... where they want wrapping
... but they don't want to pull in another names space
CL: We had wrapping text in a shape, but we couldn't do two
paragraphs
... it was basically, here's some text, here's a shape and fit it
DS: If we want deeply structured text
... there should be some HTML involved here
... paragraphs, tables
... should be able to pull in a subset
CL: Couldn't restrict it
AD: All you're doing is replacing invisible GIF with the ability to
fill text into a shape
... that's the join that is the most useful from a design point of
view
DS: From a specification point of we shouldn't limit HTML
... but from best practices point of view
CL: I see two classes of UAs
... Pure SVG UAs and one that knows about HTML and other standards
... I'm not seeing a third class
... that can do SVG and bits of other things
DS: Do we have to assume that all aspects of the box model will
apply
AD: The only reason we never went with it
... was we could never solved the margin problem
... so those problems were two hard to solve with complex shapes
... which is why we said drop margins
... and we said if you're using an odd polygon, don't use padding
and margins
... we thought about stand alone SVG
... the work should be revisited
... in light of SVG being in HTML
... bringing complex wrapping to SVG, offered things that other
standards couldn't
... we were address use cases where the shape was not a box
DS: This comes back to a concern that TB had
... we're talking about aligning more closely with HTML
... and this is great for some UAs
... but a problem with other UAs
... we need to be careful that we don't abandon pure SVG UAs
... TextArea was poorly named
... I would suggest we break here with SVG Tiny 1.2
on this
scribe: I suggest we have a mechanism, where we have something
called a text shape
... you would reference a shape and say wrap to this shape
AD: So we have clipPath
... so we can reference textShape
JW: Putting aside SVG only UAs
... the sensible thing to do is the ability in HTML to reference an
SVG
... the whole flowing concept wouldn't exist in SVG
... it would exist in HTML
... the shape comes from SVG
ED: That would be useful in SVG as well
JW: In SVG you have a coordinate system
AD: Unless you have an anonymous block
... it has it's own coordinate system that moves inside the block
JW: Taking an SVG element that's implicit
DS: You're suggesting that the syntax is like flow-shape
... as property
... that you apply
... I think that it should take multiple values
... a comma separated list of shapes
AD: You'd have to address what happens when you the shapes fill up
... we've addressed what happens when you have donut shapes and self
intersecting paths
<tbah>
[30]http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Text-Flow.html
[30] http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Text-Flow.html
JW: Cameron looked into flow stuff at some length
CL: As part of constraints
TB: Inkscape implemented this SVG Full 1.2 feature
... Inkscape still exports this
CL: Batik implemented this
DS: Here is one suggestion for Inkscape. If we did this type of text
flow, it would be very easy to take old Inkscape content
... and convert it to this sytnax
... that would work
... CSS WG and XSL-FO WG are already interested in this
... we could tell them that we are considering a property
AD: Would be nice to have use case and requirements
... I can see so much merit in saying, here's a complex polygon and
fill it with your HTML content
... so image and tables would be treated as rectangular blocks
... and if they look really tiny, they look really tiny
JW: And you could say how much overlap and colouring outside the
lines you could do
DS: People shouldn't wrap images and iFrames
AD: Need to keep it simple
... not everyone has access to optical kerning for example
<jwatt> AD: a lot of the problems were worked out in the now retired
SVG 1.2 Full draft
[31]http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html
[31] http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html
<scribe> ACTION: Doug to Start a write up page on
shape-flow-container-galley property [recorded in
[32]http://www.w3.org/2010/09/06-svg-minutes.html#action07]
<trackbot> Created ACTION-2849 - Start a write up page on
shape-flow-container-galley property [on Doug Schepers - due
2010-09-13].
AD: What do you do with the HTML if you're just in SVG
... So the text between the tags is shown in HTML but not show in
SVG
... what does SVG do with the mixed content
DS: Would a solution about the text container flow discussion
... that we have a property that can be applied to SVG or HTML
content
... which passes the id of one or more shapes
... to which the text is wrapped
TB: As long as you have the SVG text there covered
... then that's fine
DS: It would be easy for people to author in Inskcape and hand code
the HTML that they wanted to use
CC: I think this would work, but with a small note
... when you're doing Tiny on embedded platforms
... the computation might be too hard
AD: I've done the flow text for any platform
... it's not very expensive at all
CC: I think it's a nice trick
DS: Do we take into account stroke?
AD: Have to decide, might find it harder to do it to the stroke
... Going to back to my question about what happens to unrecognised
content
DS: So I did up this test
<shepazu> <svg xmlns="[33]http://www.w3.org/2000/svg">
[33] http://www.w3.org/2000/svg
<shepazu> <circle id="circle_1" cx="75" cy="25" r="20" fill="orange"
stroke="red" />
<shepazu> <foo stroke="green">
<shepazu> <rect id="rect_1" x="75" y="25" width="40" height="40"
fill="lime" />
<shepazu> </foo>
<shepazu> <ellipse id="ellipse_1" cx="115" cy="65" rx="25" ry="12"
fill="indigo" stroke="indigo"/>
<shepazu> </svg>
DS: Most user agents do not render the rectangle
... Firefox does render the rectangle
AD: I actually prefer your behaviour
DS: And so do I
... for an extensibility mechanism
... for elements not in the SVG name space
... they essentially act as groups
... in the SVG name space
... but if you do understand the element you render
... as it suppose to be
AD: This is useful for the case in geo mapping
... where the is a global geo transform
... currently they have to make it a sibling of the SVG to make it
work
... and do these horrible hacks for it work
... where as if it were a parent
... wouldn't have to do these hacks
JW: Seems like you could get bitten doing this
DS: From an accessibility point of view
... if you had a connector and it had a child path
... if the UA didn't understand connector
... you'd still get the path nested inside the connector
... so a UA like inkscape could output connector for example
... and it would work in firefox
AD: Rather than using meta data in inkscape
... where groups are overloaded as layers
... could have a <layer> and it would just work
ED: opera cuts off subtrees that are rooted by unknown elements (in
both svg and other namespaces)
... more efficient than walking the tree to find something you
understand
DS: So things not in the SVG name space it is ignored
ED: It's not going to work in the deployed UAs but it's a nice idea
... This kind of proposal will work fine
DS: Inkscape will not have to change
CC: What about text
... what if you had a <foo> with text content inside and this <foo>
is child of <text>
ED: So it's an unknown text element
AD: Just decide if it is displayed or not
ED: Have you tried that test?
AG: So is this going to work for pure SVG UAs only?
... or this is not going to apply to UAs that understand HTML + SVG
DS: The element might be put in the HTML namespace
... shouldn't cause any problems but wouldn't be ideal
ED: I think it would take someone to write a proposal first
... from this discussion it doesn't seem too hard
DS: I could write something up in integration
... right now in SVG 1.1 it says to "ignore" them and doesn't define
what "ignore" means
... SVG Tiny 1.2 "ignore" is defined
AD: Don't think it'd be a problem
... most of it is done as controlled deployment space
<scribe> ACTION: Doug to Add the idea of processing children of
unknown elements in the SVG namespaces to the integration
specification [recorded in
[34]http://www.w3.org/2010/09/06-svg-minutes.html#action08]
<trackbot> Created ACTION-2850 - Add the idea of processing children
of unknown elements in the SVG namespaces to the integration
specification [on Doug Schepers - due 2010-09-13].
Shape path
<ChrisL> OT [35]http://www.w3.org/2010/09/SVGmeetup-Paris.html
[35] http://www.w3.org/2010/09/SVGmeetup-Paris.html
ED: Text on a path is laying out text on a path
... so putting shapes on a path is similar
CL: What do you do with the varying shape sizes
... and their x & y positions?
... does that mean you need a 'g' like element
... that gathers together a collection
... and puts it on a path
... if you have a container you reference the container
DS: Would we create a new container?
... or would it be a property on <g>?
CL: You wouldn't use an SVG for each one
DS: Then there's a question of orientation of a marker
... do you honour the x & y, the cx & cy
CL: The x & y would be ignored
AD: What's the use case?
DS: The people who have already been doing this with fonts
<ChrisL> avoiding misusing text (text on a path) for decorative
shapes
DS: if you wanted to have a pattern along a line
... might be a good substitute for markers
AD: Cartographers might like this
CL: For markers you want to give an explicit x & y position
ED: If there was an implementation that did full SVG fonts you'd
already do that
... but it's not the right way to do it
DS: Next step is to draw the use case and requirements
CL: It's shapes repeated along a path
DS: We hadn't decided if this was for laying out existing shapes or
creating a pattern
AG: Maybe that's what the x & y of a shape mean
... it's an offset from the tangent and the normal
AD: You need a positioning mechanism
DS: I think we need to go to a use case and requirements document
... this is different to shape path
... because it didn't have repetition
... if you were doing a train or a train track you wouldn't want all
these elements in the DOM
... maybe it's a pattern in that sense
CL: Who's pushing for this and who is going to write it up?
DS: I expect the Mapping Taskforce
ED: I think that's a good starting point
<scribe> ACTION: Doug to Talk to Andreas about shapes on path and
stroke patterns about drawing up use case and requirements [recorded
in [36]http://www.w3.org/2010/09/06-svg-minutes.html#action09]
<trackbot> Created ACTION-2851 - Talk to Andreas about shapes on
path and stroke patterns about drawing up use case and requirements
[on Doug Schepers - due 2010-09-13].
Path on a path
TB: This is about using a path to deform an object
... this is useful for varying the stroke using a shape or a path
... [shows a demo]
DS: How would it work on a syntactic level?
TB: You'd define a shape
... Right now Inkscape does a whole bunch of things with live path
effects
CL: So if the mathematics in the deformation defined on how it
works?
TB: If you want the formula I can extract it
<tbah>
[37]http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffec
ts.html
[37] http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects.html
ED: Would be nice to have a full description
DS: Do people like the idea?
CL: It's a different way to how we thought about doing variable
stroke width
<scribe> ACTION: Tav to Extract the maths from Inkscape for path on
path and write a report [recorded in
[38]http://www.w3.org/2010/09/06-svg-minutes.html#action10]
<trackbot> Created ACTION-2852 - Extract the maths from Inkscape for
path on path and write a report [on Tavmjong Bah - due 2010-09-13].
Spiros
CL: At the type con I was talking about Spiro. I was shown code that
did only one iteration until it reached a result
... but I was told that you only need three or even one iteration
... the only thing is you might get slight angles that don't match
correctly
... but it's very slight
... the algorithm might be something worth considering
<ChrisL> shown code/shown code by Raph Levein/
DS: I propose we do some shape that takes the same syntax as path
... but has new shape types in it
<ChrisL> polycurve element. like polyline but ... curved
<ChrisL> worried that path is too entrenched, cost of changing it is
too high
DS: that's where we'd put the catmull-ron curves as well
<jwatt> scribe: Jonathan Watt
<jwatt> scribenick: jwatt
2D-transforms
<anthony>
[39]http://dev.w3.org/cvsweb/~checkout~/Graphics-FX/modules/2D-trans
forms/spec/2DTransforms.html?rev=1.1
[39]
http://dev.w3.org/cvsweb/~checkout~/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html?rev=1.1
AG: I've got proposed changes marked by red (remove) and green (add)
... should "transform affect" just be "transform property" for SVG
as well as CSS?
CL: the default value for 'transform' in CSS is 'none"
<ed> just for the comparison, here's the latest css3 2d transforms
spec: [40]http://dev.w3.org/csswg/css3-2d-transforms/
[40] http://dev.w3.org/csswg/css3-2d-transforms/
CL: we would need to make clear how that interacts with transforms
on parent and child elements
JW: surely it would just act as the identity matrix for matrix
concatenation for the purposes of working out the CTM
TB: there's a lot of discussion on the cairo mailing list for adding
perspective transforms to cairo
AG: so what I've done is my rough pass at merging the two specs, and
now we need to tidy it up
DS: so this adds transform-origin
ED: we talked about how transform-origin needs to be fixed for
backwards compat
... in a previous telcon
<ed> x[41]http://www.w3.org/2010/03/11-fx-minutes.html
[41] http://www.w3.org/2010/03/11-fx-minutes.html
<ed> [42]http://www.w3.org/2010/03/11-fx-minutes.html
[42] http://www.w3.org/2010/03/11-fx-minutes.html
<ed> [back from break]
AG: I can't see minuting of a resolution for transform-origin in
those minutes
ED: it could have been a different telcon
<ed> [43]http://www.w3.org/2010/05/17-fx-minutes.html
[43] http://www.w3.org/2010/05/17-fx-minutes.html
<ed> [44]http://www.w3.org/2010/05/03-fx-minutes.html
[44] http://www.w3.org/2010/05/03-fx-minutes.html
ED: what do we need to align with CSS 2D transforms?
DS: there are some things we should have, such as transform based on
an arbitrary point
CL: I don't believe CSS 2D transforms allows *arbitrary* points
<ChrisL> we need to add the transform-origin (including auto centre)
from CSS to our attribute syntax
ED: the spec should say that it applies to SVG content, and how
... and there should be an authoring note saying that if you use the
new 2D transforms features it may not work as an attribute
... but I don't think we need to put the new wording in any other
spec than this one
... so hopefully we can then implement and get something working
quicker, without waiting for SVG 2
... it means we get the transform-origin attribute as well
CL: we're reusing the 'transform' name?
ED: yes
CL: I think SVG 2.0 should clearly mark what is new to make it
easier for authors to decide what to use if they're concerned with
backwards compat
Connectors
CC: connectors as Doug proposes have two parts: the semantics, and
the graphical
... I would prefer to have a path element with connecting semantics
on it
... if you need to change the drawing when two points move, I'd
prefer to have a drawing operator
... so have a path that contains connector elements
... instead of having connectors with drawing semantics
... the main difference is that UAs that don't understand connectors
would still draw the path, at least initially
... if the points need to move then it wouldn't be fixed up
automatically of course
DS: I think that's a reasonable syntax
... I've suggest a connector with a path fallback instead
CL: put in an editorial comment explaining the alternative and the
pros and cons of each
resolution: publish connectors spec with alternative proposal
DS: I'm also going to publish a usecases and requirements spec
... it's not ready for first public working draft yet
... we don't want comments yet until we've progressed it further
ourselves
SVG points
TB: what is the orientation?
... can we have that as a property?
DS: x-axis
<ChrisL> rotations of the marker would be about that point. need
syntax for that? or does 'auto' cover it already?
DS: there's a general question of orientation around a point
... markers are one
... text are another
... you may want it to be independent of transform
... or dependent on the orientation of the device
AD: depending on orientation of the device could go wrong
... things could end up crossing in weird ways
... probably you want script rather than magic auto reorientation
... I wonder about the usability from an authoring perspective
DS: you can always do it using script if you don't want the auto
behavior
resolution: add SVG point to the connectors spec, to possibly be
moved later
<scribe> ACTION: Doug to spec out SVG point [recorded in
[45]http://www.w3.org/2010/09/06-svg-minutes.html#action11]
<trackbot> Created ACTION-2853 - Spec out SVG point [on Doug
Schepers - due 2010-09-13].
<anthony> We are concluded for the day
<ChrisL> adjourned
trackbot: end telcon
Summary of Action Items
[NEW] ACTION: Alex to Implement trimesh gradients using phong
shading model [recorded in
[46]http://www.w3.org/2010/09/06-svg-minutes.html#action06]
[NEW] ACTION: Cyril to propose new wording for the spec for
ISSUE-2368 [recorded in
[47]http://www.w3.org/2010/09/06-svg-minutes.html#action01]
[NEW] ACTION: Doug to Add the idea of processing children of unknown
elements in the SVG namespaces to the integration specification
[recorded in
[48]http://www.w3.org/2010/09/06-svg-minutes.html#action08]
[NEW] ACTION: Doug to contact the CSS WG about a
transition-attribute property or equivalent [recorded in
[49]http://www.w3.org/2010/09/06-svg-minutes.html#action02]
[NEW] ACTION: Doug to spec out SVG point [recorded in
[50]http://www.w3.org/2010/09/06-svg-minutes.html#action11]
[NEW] ACTION: Doug to Start a write up page on
shape-flow-container-galley property [recorded in
[51]http://www.w3.org/2010/09/06-svg-minutes.html#action07]
[NEW] ACTION: Doug to Talk to Andreas about shapes on path and
stroke patterns about drawing up use case and requirements [recorded
in [52]http://www.w3.org/2010/09/06-svg-minutes.html#action09]
[NEW] ACTION: Erik to prepare a draft about the relationships
between CSS transitions and SVG [recorded in
[53]http://www.w3.org/2010/09/06-svg-minutes.html#action04]
[NEW] ACTION: Erik to see what implementations are doing with
regards to CSS transitions and SMIL sandwich models [recorded in
[54]http://www.w3.org/2010/09/06-svg-minutes.html#action03]
[NEW] ACTION: Tav to draft report on Coons patches [recorded in
[55]http://www.w3.org/2010/09/06-svg-minutes.html#action05]
[NEW] ACTION: Tav to Extract the maths from Inkscape for path on
path and write a report [recorded in
[56]http://www.w3.org/2010/09/06-svg-minutes.html#action10]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [57]scribe.perl version 1.135
([58]CVS log)
$Date: 2010/09/06 16:01:07 $
_________________________________________________________
[57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[58] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [59]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/CSS properties/CSS properties I would think/
Succeeded: s/support animations of gradients/support CSS transitions of
CSS gradients/
Succeeded: s/there is no active editor/there doesn't seem to be recent
editing activity/
Succeeded: s/PDF/The litterature/
Succeeded: s/this aspects/these aspects/
Succeeded: s/shap/shape/
Succeeded: s/APIs/APIs (GDI)/
Succeeded: s/arrrr/ahhhhh/
Succeeded: s/srapping/wrapping/
Succeeded: s/We tried to walk into subtrees we don't understand/opera c
uts off subtrees that are rooted by unknown elements (in both svg and o
ther namespaces)/
Succeeded: s/did an/did only one/
Succeeded: s/list far/list for/
Succeeded: s/minuting of/minuting of a resolution for/
Succeeded: s/orientation/orientation of a marker/
Found Scribe: Cyril
Inferring ScribeNick: cyril
Found ScribeNick: Cyril
Found Scribe: anthony
Inferring ScribeNick: anthony
Found ScribeNick: anthony
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Scribes: Cyril, anthony, Jonathan Watt
ScribeNicks: cyril, anthony, jwatt
WARNING: No "Present: ... " found!
Possibly Present: AD AG CC CL ChrisL DS ISSUE JW TB anthony cyril cyril
_ ed joined jwatt left scribenick shepazu svg tbah trackbot xhttp
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 06 Sep 2010
Guessing minutes URL: [60]http://www.w3.org/2010/09/06-svg-minutes.html
People with action items: alex cyril doug erik tav
[60] http://www.w3.org/2010/09/06-svg-minutes.html
End of [61]scribe.perl diagnostic output]
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm