IRC log of svg on 2009-02-19

Timestamps are in UTC.

22:17:15 [RRSAgent]
RRSAgent has joined #svg
22:17:15 [RRSAgent]
logging to http://www.w3.org/2009/02/19-svg-irc
22:17:17 [trackbot]
RRSAgent, make logs public
22:17:17 [Zakim]
Zakim has joined #svg
22:17:19 [trackbot]
Zakim, this will be GA_SVGWG
22:17:19 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
22:17:20 [trackbot]
Meeting: SVG Working Group Teleconference
22:17:20 [trackbot]
Date: 19 February 2009
22:17:31 [ChrisL]
rrsagent, this meeting spans midnight
22:17:44 [ChrisL]
zakim, remind us in 8 hours to go home
22:17:44 [Zakim]
ok, ChrisL
22:18:16 [ChrisL]
Meeting: SVG f2f meeting, Sydney
22:26:56 [heycam]
heycam has joined #svg
22:27:37 [heycam]
RRSAgent, pointer?
22:27:37 [RRSAgent]
See http://www.w3.org/2009/02/19-svg-irc#T22-27-37
22:27:56 [heycam]
http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html
22:30:10 [ed__]
ed__ has joined #svg
22:34:07 [heycam]
Topic: Layout requirements continued
22:34:14 [jwatt]
jwatt has joined #svg
22:36:53 [heycam]
Scribe: Cameron
22:36:57 [heycam]
ScribeNick: heycam
22:37:01 [heycam]
CL: R4 is worded a bit strangely
22:37:14 [heycam]
ED: i like a goal for the layout stuff to be usable outside SVG too
22:37:17 [heycam]
ED: e.g. in CSS/HTML
22:38:04 [heycam]
CM: yes i think it would be good
22:38:09 [shepazu]
shepazu has joined #svg
22:38:23 [heycam]
ED: so if it's generic, but still can handle some SVG specifics, that would be fine
22:38:27 [heycam]
ED: depends on what conclusions we come to
22:38:46 [heycam]
DS: it could be that we spin out this into a layout spec that isn't svg
22:38:54 [heycam]
DS: hopefully it doesn't take that [to be accepted by others]
22:39:38 [heycam]
AG: a separate layout language that uses svg layout would be possible
22:40:03 [heycam]
CM: that still might not be acceptable to some
22:40:18 [heycam]
CM: but there would still need to be some svg-specific language anyway
22:47:31 [ed__]
ED: R10, is that the right word to use, shouldn't it be using "intrinsic size"?
22:47:55 [ed__]
...also I'm wondering why it's needed, why do you need to be able to derive the intrinsic size based on the layout?
22:48:10 [ed__]
...the document dimensions would implictly be 100%x100% anyway
22:48:28 [ed__]
CM: you don't always want to specify the size on the object element in html
22:49:03 [ed__]
...just like modifying the width and height on the svg element with script should change the intrinsic size of the document
22:49:24 [ed__]
...so you could have the layout change those attributes
22:49:51 [ed__]
JW: i'm wondering the opposite, why whould you like to derive the viewbox?
22:50:25 [ed__]
...since that's only describing how the svg should scale, and not the way of sizing or positioning the viewport relative to the edges of other elements (parents, siblings etc)
22:50:25 [heycam]
heycam has joined #svg
22:51:06 [ed__]
CM: sometimes you don't know how much content there'll be, depending on the layout
22:52:43 [ed__]
...if you don't specify the viewbox what does that imply?
22:54:06 [ed__]
JW: that there will be no additional transformation for it
22:54:31 [ed__]
CM: so [0 0 width height] will be the viewbox implicitly (derived from the widht and height9
22:55:47 [ed__]
JW: so if you have an overflowing layout then sometimes you mihgt not want to squeeze everything with viewbox, you might only want part of it
22:56:25 [ed__]
CM: the use-case is mostly for browsers, svg in html
22:57:41 [ed__]
...the usecase is mainly for making the replaced element bigger for fitting more content depending on the layout
23:00:11 [ed__]
...so maybe we don't need to derive the viewbox based on the layout
23:00:46 [ed__]
JW: sometimes you wnat to change the size, but sometimes you want to reach a maximum, and use the viewbox for making sure things look correct
23:01:46 [ed__]
CM: maybe we'd need something like viewbox-maximum or viewport-maximum that you could do layout from
23:03:47 [ed__]
...to get the two kinds of sizing, sometimes grow the height but leave the viewbox implicit
23:03:59 [ed__]
...gives no scaling because of viewbox
23:04:41 [ed__]
...in other cases you might want to limit the height in pixels for example, and if you do that you could choose to either have the document scale or limit the space to have the layout reflow inside the svg document
23:05:02 [ed__]
...so how do you do that using html/css/svg is the question
23:05:35 [ed__]
JW: for R10 i think we agree that deriving document size and viewbox are both useful
23:06:03 [ed__]
...there should be use-cases for controlling both document size and viewbox
23:07:10 [ed__]
ED: R11, would rotation be included in here?
23:07:33 [ed__]
...like for putting images along a circle and having them automatically rotated
23:07:59 [ed__]
CM: this perhaps is covered by R15
23:39:46 [ed__]
[coffeebreak, and discussion on gridlayout]
23:55:33 [ed__]
CM: no consensus on R11 so far
23:55:55 [ed__]
...R12, couldnt think of anything specific, maybe remove?
23:56:28 [ed__]
ED: perhaps already met by R4?
23:57:12 [ed__]
CM: yeah, maybe if R4 looked at baselines...
23:57:24 [ed__]
DS: CSS already does this, right?
23:57:27 [ed__]
CM: yes
23:58:57 [ed__]
...will flesh out R12 with examples, noting that it may be solved by CSS
00:01:54 [ed__]
JW: possibly we should have a connection-points property
00:02:11 [ed__]
...where connecting lines snap to the nearest connectionpoint
00:02:32 [heycam]
heycam has joined #svg
00:02:56 [ed__]
...i prefer that to having multiple connectionpoint elements inside of shapes
00:04:03 [ed__]
ED: R13, wondering about the relation to vectoreffects here
00:04:22 [ed__]
CM: circles easy yes, but ellipses more difficult
00:05:29 [ed__]
...R11 you might have defined keypoints, R13 is automatically determining the closest point of a shape
00:05:40 [ed__]
JW: not very clear from R13
00:06:59 [ed__]
CM: R13 no consensus yet either, relates to R11
00:07:49 [ed__]
ED: R14, why doesn't it mention relative to viewport, or to arbitrary other numbers?
00:08:21 [ed__]
JW: you could have connectionspoints-units property which could be objectBoundingBox
00:09:12 [ed__]
CM: ok, so i can see the need for relative to viewport
00:09:20 [ed__]
...could be handled by simple addition of lengths
00:10:23 [ed__]
JW: maybe we're being to specific in the requirements
00:11:26 [ed__]
CM: we should collapse the support-positioning-of-objects requirements into one requirement, and list use-cases
00:12:02 [ed__]
DS: R16 missing?
00:13:36 [ed__]
ED: R18, isn't mentioning XBL a bit unnecessary / too specific?
00:15:23 [ed__]
CM: ok, consider how this might work with other webtechnologies, and also move this requirement up to the top
00:15:36 [heycam]
heycam has joined #svg
00:15:48 [heycam]
RRSAgent, pointer?
00:15:48 [RRSAgent]
See http://www.w3.org/2009/02/19-svg-irc#T00-15-48
00:16:37 [ed__]
ED: R22, is this really in scope?
00:17:14 [ed__]
CM: had a discussion with someone from metacity, and he wanted to use svg as the way to skin windows
00:17:34 [ed__]
...he wanted a way to describe this in svg
00:17:58 [ed__]
...mobiles often use svg for skins etc
00:18:59 [ed__]
ED: wonder if we really need to have it here
00:19:40 [ed__]
AG: could be useful for printing
00:19:55 [ed__]
...flow text into the template
00:20:14 [ed__]
CM: the print spec doesn't do that already?
00:20:34 [ed__]
AG: it's a static layout currently
00:20:50 [ed__]
CM: sounds a bit like xsl:fo
00:21:04 [ed__]
...we could change it to be a maybe requirement
00:21:42 [ed__]
ED: yes, let's do that, it's a nice to have if we can do it easily
00:22:18 [ed__]
CM: are we agreed on the nongoals?
00:22:31 [ed__]
ED: yeah, those are ok
00:23:06 [ed__]
CM: they're things that might be too big to put in anyway
00:23:27 [ed__]
...people might expect to do these things, but these are difficult problems
00:25:45 [ed__]
DS: i don't think we should completely reject the idea of automatic graph layout
00:27:51 [ed__]
CM: the extensibility requirements (scripts) could deal with this problem
00:30:00 [ed__]
DS: i like the idea of extensibility for layout
00:30:26 [ed__]
JW: the nongoals should go to the top
00:30:36 [ed__]
...to make it clear from the start
00:30:49 [ed__]
DS: should we have anti-goals?
00:31:01 [ed__]
CM: that's sort of the non-goals are
00:31:17 [ed__]
DS: ok, we could clarify what we mean with nongoals
00:31:28 [ed__]
...explicit things we will not support
00:31:32 [ed__]
JW: and say why
00:35:40 [ed__]
CM: ok, i'll make changes as indicated and add notes for the ones where we have no consensus
00:39:24 [ed__]
JW: I have reservations against some of the requirements, but it's useful to go ahead with discussions so go ahead with the publication
00:41:33 [ed__]
RESOLUTION: we will publish the SVG Layout Requirements as soon as heycam has edited the document to include the conclusions in these minutes (and from the previous day)
00:43:14 [ChrisL]
yay
00:44:58 [ChrisL]
ok
00:51:21 [ed__]
ACTION: heycam to edited the SVG Layout Requirements document to include the conclusions in these minutes (and from the previous day) and to proceed with the publication of it
00:51:21 [trackbot]
Created ACTION-2478 - Edited the SVG Layout Requirements document to include the conclusions in these minutes (and from the previous day) and to proceed with the publication of it [on Cameron McCormack - due 2009-02-27].
00:52:01 [ed__]
scribeNick: ed__
00:52:07 [ed__]
Topic: SVG Print
00:52:47 [ed__]
http://dev.w3.org/SVG/modules/print/master/SVGPrint.html
00:53:00 [ed__]
http://dev.w3.org/SVG/modules/print/master/SVGPrintPrimer.html
00:53:26 [ed__]
http://dev.w3.org/SVG/modules/print/master/SVGPrintReqs.html
00:53:50 [ed__]
AG: we'll start with the language spec
00:54:25 [ed__]
...think the stylesheet is missing
00:55:04 [ed__]
CL: there's no style directory under master
00:55:15 [ed__]
...maybe it wasn't moved over from the old cvs location?
00:56:05 [ed__]
DS: there's a 'styles' directory, but not a 'style'
00:57:05 [ed__]
CL: would it be good to move the editors to an acknowledgements section
00:57:13 [ed__]
DS: or maybe authors sections
00:57:24 [ed__]
CL: or perhaps add dates
00:58:11 [ed__]
AG: not many changes lately
00:58:24 [ed__]
CL: do we have outstanding issues still?
00:58:34 [ed__]
AG: yes, there are some action items
00:58:40 [ChrisL]
action-1?
00:58:40 [trackbot]
ACTION-1 does not exist
00:58:51 [ChrisL]
action-123?
00:58:51 [trackbot]
ACTION-123 does not exist
00:59:00 [ed__]
AG: that resulted from the LC that we had
00:59:28 [ed__]
CM: are these actions in the old tracker?
00:59:33 [heycam]
trackbot, url?
00:59:33 [trackbot]
Sorry, heycam, I don't understand 'trackbot, url?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
00:59:42 [ChrisL]
action-2112?
00:59:42 [trackbot]
ACTION-2112 -- Cameron McCormack to testing " and ' and < and > -- due 2008-07-31 -- CLOSED
00:59:42 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/actions/2112
01:00:09 [ed__]
CL: we don't have print as a product in tracker
01:00:15 [ed__]
...adding it now
01:00:35 [ed__]
AG: have fixed the stylesheets problem now
01:00:39 [ChrisL]
http://www.w3.org/Graphics/SVG/WG/track/products/17
01:02:19 [ed__]
CL: the logo is nice, but it needs to be moved to the bottom of the document (w3 pubrules)
01:03:34 [ed__]
AG: we define conformance classes in the intro section, we're told to change the names of them
01:03:45 [ed__]
DS: print preview agent etc?
01:03:47 [ed__]
AG: yes
01:05:00 [ed__]
CL: there were some issues about foreground and master pages
01:05:12 [ed__]
AG: in "printing pages"
01:05:34 [ed__]
CM: should you use camelcase for attribuets?
01:05:45 [ed__]
DS: some people don't like it
01:06:48 [ed__]
CL: historic reasons based on feedback from css and [fill-in-blank] working groups
01:07:17 [ed__]
...will changing it have any impact on deployed implementions?
01:07:28 [ed__]
AG: probably not
01:07:36 [ChrisL]
s/[fill-in-blank]/DOM/
01:08:19 [ed__]
CL: we've had interest from inkscape and scribus
01:09:04 [ed__]
...flowtext was an example where changing had a real impact on implementations
01:09:29 [ed__]
AG: i've hyphenated the values of the attributes
01:10:24 [ed__]
ED: css property names with hyphens seem consistent with what we have already
01:10:55 [ed__]
AG: [draws example of how masterpages work]
01:11:18 [ChrisL]
looking for feedback from dec 2007 last call
01:11:19 [ChrisL]
http://lists.w3.org/Archives/Public/public-svg-print/2007Dec/0001.html
01:11:49 [ChrisL]
several here http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/
01:12:44 [ChrisL]
an apache fop developer indicating interest in implementing http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0000.html
01:14:31 [ed__]
CM: for the masterpage attribute it seems that you can say that you can have it in the document, or in an external document
01:14:34 [ChrisL]
more comments - from css http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0003.html
01:15:05 [ChrisL]
comments from XSL http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html
01:15:12 [ed__]
...if the attribute didin't exist you'd the the current masterpage
01:15:29 [ed__]
s/the the/get the/
01:16:25 [ed__]
CM: has some definitions gone into the primer that should be in the language spec?
01:16:31 [ed__]
AG: checking
01:17:00 [ed__]
CM: how do you reference pages in external documents?
01:17:08 [ed__]
CL: with a url I think
01:17:18 [ed__]
CM: on the page element xlink:href?
01:17:22 [ed__]
CL: yes
01:17:42 [ed__]
CM: not sure it's deifned
01:17:49 [ed__]
AG: that needs to be more clearly defined
01:19:21 [ed__]
CM: i'd like to know the use-cases for using external masterpages if you can reference other pages from other documents
01:19:58 [ed__]
AG: i agree it's not defined
01:20:15 [ed__]
CL: we haven't got a disposition of comments document
01:20:50 [ed__]
CM: so we need to do that
01:21:15 [ed__]
ACTION: AG to create a disposition of comments document for the SVG Print lastcall
01:21:15 [trackbot]
Created ACTION-2479 - Create a disposition of comments document for the SVG Print lastcall [on Anthony Grasso - due 2009-02-27].
01:22:09 [heycam]
http://www.w3.org/Graphics/SVG/1.2/Tiny/dc.html -- SVG Tiny 1.2 disposition of comments
01:22:10 [ed__]
CL: we do need to reply to all the comments before publishing SVG Print again
01:23:01 [ed__]
AG: the next thing down was the print-display attribute, changed it from bool
01:23:23 [ed__]
...also a comment to say maybe replace it with css media
01:23:40 [ed__]
CL: xsl made the same comment
01:23:50 [ed__]
CM: if you're fine with requiring support for stylesheets
01:24:23 [ed__]
...maybe if this was implemented in a printer you'd like to avoid having a css implemention
01:24:37 [ed__]
AG: is it possible to borrow just that property from css?
01:24:39 [ed__]
CM: not really
01:24:46 [ed__]
...since it's an at-rule
01:25:11 [ed__]
...should you explicitly outlaw stylesheets?
01:25:26 [ed__]
...tiny doesn't support stylesheets, and it builds on top of tiny
01:25:45 [ed__]
CL: this might be implemented in xsl
01:25:55 [ed__]
...so not depend on one feature
01:26:09 [ed__]
AG: we do have a section in the primer about css for page scoping
01:26:48 [ed__]
CM: if you want interop between svg printers, either disallow stylesheets or require them
01:27:07 [ed__]
CL: there's an @color-profile
01:27:19 [ed__]
...the css wg has dropped it from css3 color module
01:27:30 [ed__]
...we have an xml version of it
01:28:19 [ed__]
...we should delete that piece on @color-profile because you can do the same thing in xml
01:28:33 [ed__]
...i think it should allow support for CSS but not require it
01:28:52 [ed__]
CM: then you shouldn't generate CSS in the content
01:29:11 [ed__]
AG: in that case should we not replace the printdisplay attr with css media?
01:29:22 [ed__]
CM: that'd be an argument for keeping it yes
01:29:58 [ed__]
...nothing saying what types of generators of content, saying that if you target a specific user agent then don't do this and so on
01:30:15 [ed__]
...oh, we have a conformance class for content
01:30:23 [ed__]
CL: right, but doesn't say anything about css currently
01:31:18 [ed__]
CM: are we close to publishing again?
01:31:28 [ChrisL]
xsl comments http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html
01:31:29 [ed__]
CL: we have a number of unanswered questions from the LC still
01:32:12 [ed__]
...let's go through the email and discuss the comments
01:32:49 [ed__]
CL: first thing is about user agents
01:33:13 [ed__]
...we could say a user agent could offer that functionality
01:34:00 [ed__]
CM: what's the differences between a print preview agent and a print user agent?
01:34:08 [ed__]
AG: there are some minor things
01:36:07 [ed__]
CL: the xsl wg is asking if are going to have features like a table of contents, which can link to pages etc
01:36:32 [ed__]
AG: might be more of conformance criteria for print preview UAs
01:36:42 [ed__]
CM: only two reqs differ, just checked
01:37:02 [heycam]
http://dev.w3.org/SVG/modules/print/master/SVGPrint.html#user-agents
01:37:28 [ed__]
CM: not sure what it's saying...should it pop up a window for setting print options?
01:37:34 [ed__]
CL: yes
01:37:42 [ed__]
CM: is that really something we need to require?
01:38:04 [ed__]
CL: there are existing printer control languages but we don't want to require any of them
01:38:36 [ed__]
...the intent is that you should be able to print e.g pages 3 - 6
01:39:03 [ed__]
CM: it doesn't seem like something people will forget about or not do if we don't say it
01:39:11 [ed__]
...because it's such a basic thing
01:39:32 [ed__]
DS: i'm questioning if we should be doing this work
01:40:50 [ed__]
CL: there are features like color management
01:41:12 [jwatt]
CL: there are two parts to this: proper color, and pages
01:42:25 [ed__]
CM: the way the spec is worded is for printers...but pages and colors are things like scribus and inkscape want to have
01:42:31 [ed__]
...that is, non-printer uses
01:43:45 [ed__]
CL: in svg1.1 color management was optional
01:43:59 [ed__]
...svg print makes it mandatory
01:44:03 [ed__]
...so that it's testable
01:44:32 [ed__]
CM: that's good, but the wording makes it sounds like it's more for a niche case
01:44:49 [ed__]
...makes it sound more printer-specific than it actually is
01:46:10 [ed__]
DS: what pdfxml and this spec is trying to solve are two different problems
01:54:19 [shepazu]
DS: I suggest we split this into SVG Pages and SVG Color Management, and move them forward independently
01:54:28 [ChrisL]
I agree that the two main features are pretty much orthogonal, so splitting is fine by me
01:54:36 [ChrisL]
colour could probably move faster
01:57:08 [shepazu]
scribenick: shepazu
01:58:43 [shepazu]
RESOLUTION: Pending approval by Canon, we will split SVG Print into SVG Pages and SVG Color Management
03:09:29 [ed__]
ed__ has joined #svg
03:45:31 [ed__]
Topic: Creating collaborative testsuite
03:56:23 [heycam]
JW: in principle it would be good if all implementors could share the same test format
03:56:35 [heycam]
JW: for automated testing
03:56:58 [heycam]
... because when we get to tens of thousands of tests, it becomes impractical for new implementors to hand tweak all the tests to their own framework if we don't do that
03:57:05 [heycam]
... which would put off new implementors and slow them down
03:57:21 [heycam]
DS: also, we know how horrible it was doing test fests at F2Fs
05:11:24 [jwatt]
jwatt has joined #svg
05:15:42 [heycam]
heycam has joined #svg
05:15:50 [jwatt]
jwatt has joined #svg
05:15:52 [ed__]
jwatt: latest test template: http://dev.w3.org/SVG/profiles/1.1F2/test/templates/
05:16:03 [heycam]
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-dom-01-f.svg
05:37:32 [heycam]
JW: so you make basic assumptions such as 'rectangles are drawn correctly'
05:37:32 [heycam]
... and you build upon previous assumptions
05:37:32 [heycam]
... so say you wanted to test the <path> element, you might draw what would look like a rectangle with the path
05:37:32 [heycam]
... render that, then in the reference document you draw a <rect>, you're assuming rectangles draw correctly
05:37:32 [heycam]
... and check that they paint the same (pixel for pixel)
05:37:34 [heycam]
AG: you could do calibration with that method
05:37:36 [heycam]
... render a 100x100 red rectangle
05:37:38 [heycam]
... compare it against the reference rendering
05:37:40 [heycam]
... then look at the pixel differences, and use that as a calibration
05:37:42 [heycam]
... in printers you do colour calibration
05:37:44 [heycam]
ED: would you be able to calibrate if you had something that does alignment to a pixel grid for example?
05:37:46 [heycam]
... but off the pixel grid it might not be exactly the same?
05:37:48 [heycam]
DS: even so, calibration is a good idea
05:37:50 [heycam]
ED: probably JW's suggestion here is going to be more accurate
05:37:52 [heycam]
[jonathan shows some tests]
05:37:54 [heycam]
RRSAgent, pointer?
05:37:54 [RRSAgent]
See http://www.w3.org/2009/02/19-svg-irc#T05-37-54
05:40:30 [heycam]
DS: we need to be careful that we don't get consumed in working on tests to the detriment of work on other things
06:17:44 [Zakim]
ChrisL, you asked to be reminded at this time to go home
06:44:58 [anthony_]
anthony_ has joined #svg
06:55:05 [heycam]
heycam has joined #svg
06:57:43 [ed__]
http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
07:27:43 [Zakim]
Zakim has left #svg