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