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