W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2010

Minutes Paris F2F day 2 (September 6, 2010)

From: Jonathan Watt <jwatt@jwatt.org>
Date: Mon, 06 Sep 2010 18:05:00 +0200
Message-ID: <4C85112C.50604@jwatt.org>
To: www-svg <www-svg@w3.org>


      [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



          Cyril, anthony, Jonathan Watt


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


   <cyril> ISSUE-2368?

   <trackbot> ISSUE-2368 -- Problems with grammars for numbers --

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

   <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

   <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

   <trackbot> Created ACTION-2844 - Contact the CSS WG about a
   transition-attribute property or equivalent [on Doug Schepers - due

   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

   <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

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


   <trackbot> ISSUE-2369 -- Define CSS3+SMIL behaviour for 'inherit' --

   <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

   <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

   <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

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


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

   <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
   ... instead of multiple weights
   ... so if you have a font with 6 weights, you will still only get

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

   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

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


     [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

   <scribe> ACTION: Doug to Start a write up page on
   shape-flow-container-galley property [recorded in

   <trackbot> Created ACTION-2849 - Start a write up page on
   shape-flow-container-galley property [on Doug Schepers - due

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

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

   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

   <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

   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

   CL: So if the mathematics in the deformation defined on how it

   TB: If you want the formula I can extract it


     [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

   <trackbot> Created ACTION-2852 - Extract the maths from Inkscape for
   path on path and write a report [on Tavmjong Bah - due 2010-09-13].


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




   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


   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

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

   resolution: add SVG point to the connectors spec, to possibly be
   moved later

   <scribe> ACTION: Doug to spec out SVG point [recorded in

   <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
   [NEW] ACTION: Cyril to propose new wording for the spec for
   ISSUE-2368 [recorded in
   [NEW] ACTION: Doug to Add the idea of processing children of unknown
   elements in the SVG namespaces to the integration specification
   [recorded in
   [NEW] ACTION: Doug to contact the CSS WG about a
   transition-attribute property or equivalent [recorded in
   [NEW] ACTION: Doug to spec out SVG point [recorded in
   [NEW] ACTION: Doug to Start a write up page on
   shape-flow-container-galley property [recorded in
   [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
   [NEW] ACTION: Erik to see what implementations are doing with
   regards to CSS transitions and SMIL sandwich models [recorded in
   [NEW] ACTION: Tav to draft report on Coons patches [recorded in
   [NEW] ACTION: Tav to Extract the maths from Inkscape for path on
   path and write a report [recorded in

   [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

     [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
Received on Monday, 6 September 2010 16:05:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:44 UTC