<trackbot> Date: 19 February 2009

<ChrisL> Meeting: SVG f2f meeting, Sydney

<heycam> http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html

Layout requirements continued

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

CL: R4 is worded a bit strangely

ED: i like a goal for the layout stuff to be usable outside SVG too
... e.g. in CSS/HTML

CM: yes i think it would be good

ED: so if it's generic, but still can handle some SVG specifics, that would be fine
... depends on what conclusions we come to

DS: it could be that we spin out this into a layout spec that isn't svg
... hopefully it doesn't take that [to be accepted by others]

AG: a separate layout language that uses svg layout would be possible

CM: that still might not be acceptable to some
... but there would still need to be some svg-specific language anyway

ED: R10, is that the right word to use, shouldn't it be using "intrinsic size"?
... also I'm wondering why it's needed, why do you need to be able to derive the intrinsic size based on the layout?
... the document dimensions would implictly be 100%x100% anyway

CM: you don't always want to specify the size on the object element in html
... just like modifying the width and height on the svg element with script should change the intrinsic size of the document
... so you could have the layout change those attributes

JW: i'm wondering the opposite, why whould you like to derive the viewbox?
... 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)

CM: sometimes you don't know how much content there'll be, depending on the layout
... if you don't specify the viewbox what does that imply?

JW: that there will be no additional transformation for it

CM: so [0 0 width height] will be the viewbox implicitly (derived from the widht and height9

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

CM: the use-case is mostly for browsers, svg in html
... the usecase is mainly for making the replaced element bigger for fitting more content depending on the layout
... so maybe we don't need to derive the viewbox based on the layout

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

CM: maybe we'd need something like viewbox-maximum or viewport-maximum that you could do layout from
... to get the two kinds of sizing, sometimes grow the height but leave the viewbox implicit
... gives no scaling because of viewbox
... 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
... so how do you do that using html/css/svg is the question

JW: for R10 i think we agree that deriving document size and viewbox are both useful
... there should be use-cases for controlling both document size and viewbox

ED: R11, would rotation be included in here?
... like for putting images along a circle and having them automatically rotated

CM: this perhaps is covered by R15

[coffeebreak, and discussion on gridlayout]

CM: no consensus on R11 so far
... R12, couldnt think of anything specific, maybe remove?

ED: perhaps already met by R4?

CM: yeah, maybe if R4 looked at baselines...

DS: CSS already does this, right?

CM: yes
... will flesh out R12 with examples, noting that it may be solved by CSS

JW: possibly we should have a connection-points property
... where connecting lines snap to the nearest connectionpoint
... i prefer that to having multiple connectionpoint elements inside of shapes

ED: R13, wondering about the relation to vectoreffects here

CM: circles easy yes, but ellipses more difficult
... R11 you might have defined keypoints, R13 is automatically determining the closest point of a shape

JW: not very clear from R13

CM: R13 no consensus yet either, relates to R11

ED: R14, why doesn't it mention relative to viewport, or to arbitrary other numbers?

JW: you could have connectionspoints-units property which could be objectBoundingBox

CM: ok, so i can see the need for relative to viewport
... could be handled by simple addition of lengths

JW: maybe we're being to specific in the requirements

CM: we should collapse the support-positioning-of-objects requirements into one requirement, and list use-cases

DS: R16 missing?

ED: R18, isn't mentioning XBL a bit unnecessary / too specific?

CM: ok, consider how this might work with other webtechnologies, and also move this requirement up to the top

ED: R22, is this really in scope?

CM: had a discussion with someone from metacity, and he wanted to use svg as the way to skin windows
... he wanted a way to describe this in svg
... mobiles often use svg for skins etc

ED: wonder if we really need to have it here

AG: could be useful for printing
... flow text into the template

CM: the print spec doesn't do that already?

AG: it's a static layout currently

CM: sounds a bit like xsl:fo
... we could change it to be a maybe requirement

ED: yes, let's do that, it's a nice to have if we can do it easily

CM: are we agreed on the nongoals?

ED: yeah, those are ok

CM: they're things that might be too big to put in anyway
... people might expect to do these things, but these are difficult problems

DS: i don't think we should completely reject the idea of automatic graph layout

CM: the extensibility requirements (scripts) could deal with this problem

DS: i like the idea of extensibility for layout

JW: the nongoals should go to the top
... to make it clear from the start

DS: should we have anti-goals?

CM: that's sort of the non-goals are

DS: ok, we could clarify what we mean with nongoals
... explicit things we will not support

JW: and say why

CM: ok, i'll make changes as indicated and add notes for the ones where we have no consensus

JW: I have reservations against some of the requirements, but it's useful to go ahead with discussions so go ahead with the publication

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)

<ChrisL> yay

<ChrisL> ok

<scribe> 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 [recorded in http://www.w3.org/2009/02/19-svg-irc]

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

<scribe> scribeNick: ed__

SVG Print

http://dev.w3.org/SVG/modules/print/master/SVGPrint.html

http://dev.w3.org/SVG/modules/print/master/SVGPrintPrimer.html

http://dev.w3.org/SVG/modules/print/master/SVGPrintReqs.html

AG: we'll start with the language spec
... think the stylesheet is missing

CL: there's no style directory under master
... maybe it wasn't moved over from the old cvs location?

DS: there's a 'styles' directory, but not a 'style'

CL: would it be good to move the editors to an acknowledgements section

DS: or maybe authors sections

CL: or perhaps add dates

AG: not many changes lately

CL: do we have outstanding issues still?

AG: yes, there are some action items

<ChrisL> action-1?

<trackbot> ACTION-1 does not exist

<ChrisL> action-123?

<trackbot> ACTION-123 does not exist

AG: that resulted from the LC that we had

CM: are these actions in the old tracker?

<heycam> trackbot, url?

<trackbot> Sorry, heycam, I don't understand 'trackbot, url?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<ChrisL> action-2112?

<trackbot> ACTION-2112 -- Cameron McCormack to testing " and ' and < and > -- due 2008-07-31 -- CLOSED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2112

CL: we don't have print as a product in tracker
... adding it now

AG: have fixed the stylesheets problem now

<ChrisL> http://www.w3.org/Graphics/SVG/WG/track/products/17

CL: the logo is nice, but it needs to be moved to the bottom of the document (w3 pubrules)

AG: we define conformance classes in the intro section, we're told to change the names of them

DS: print preview agent etc?

AG: yes

CL: there were some issues about foreground and master pages

AG: in "printing pages"

CM: should you use camelcase for attribuets?

DS: some people don't like it

CL: historic reasons based on feedback from css and DOM working groups
... will changing it have any impact on deployed implementions?

AG: probably not

CL: we've had interest from inkscape and scribus
... flowtext was an example where changing had a real impact on implementations

AG: i've hyphenated the values of the attributes

ED: css property names with hyphens seem consistent with what we have already

AG: [draws example of how masterpages work]

<ChrisL> looking for feedback from dec 2007 last call

<ChrisL> http://lists.w3.org/Archives/Public/public-svg-print/2007Dec/0001.html

<ChrisL> several here http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/

<ChrisL> an apache fop developer indicating interest in implementing http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0000.html

CM: for the masterpage attribute it seems that you can say that you can have it in the document, or in an external document

<ChrisL> more comments - from css http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0003.html

<ChrisL> comments from XSL http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html

CM: if the attribute didin't exist you'd get the current masterpage
... has some definitions gone into the primer that should be in the language spec?

AG: checking

CM: how do you reference pages in external documents?

CL: with a url I think

CM: on the page element xlink:href?

CL: yes

CM: not sure it's deifned

AG: that needs to be more clearly defined

CM: i'd like to know the use-cases for using external masterpages if you can reference other pages from other documents

AG: i agree it's not defined

CL: we haven't got a disposition of comments document

CM: so we need to do that

<scribe> ACTION: AG to create a disposition of comments document for the SVG Print lastcall [recorded in http://www.w3.org/2009/02/19-svg-irc]

<trackbot> Created ACTION-2479 - Create a disposition of comments document for the SVG Print lastcall [on Anthony Grasso - due 2009-02-27].

<heycam> http://www.w3.org/Graphics/SVG/1.2/Tiny/dc.html -- SVG Tiny 1.2 disposition of comments

CL: we do need to reply to all the comments before publishing SVG Print again

AG: the next thing down was the print-display attribute, changed it from bool
... also a comment to say maybe replace it with css media

CL: xsl made the same comment

CM: if you're fine with requiring support for stylesheets
... maybe if this was implemented in a printer you'd like to avoid having a css implemention

AG: is it possible to borrow just that property from css?

CM: not really
... since it's an at-rule
... should you explicitly outlaw stylesheets?
... tiny doesn't support stylesheets, and it builds on top of tiny

CL: this might be implemented in xsl
... so not depend on one feature

AG: we do have a section in the primer about css for page scoping

CM: if you want interop between svg printers, either disallow stylesheets or require them

CL: there's an @color-profile
... the css wg has dropped it from css3 color module
... we have an xml version of it
... we should delete that piece on @color-profile because you can do the same thing in xml
... i think it should allow support for CSS but not require it

CM: then you shouldn't generate CSS in the content

AG: in that case should we not replace the printdisplay attr with css media?

CM: that'd be an argument for keeping it yes
... 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
... oh, we have a conformance class for content

CL: right, but doesn't say anything about css currently

CM: are we close to publishing again?

<ChrisL> xsl comments http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html

CL: we have a number of unanswered questions from the LC still
... let's go through the email and discuss the comments
... first thing is about user agents
... we could say a user agent could offer that functionality

CM: what's the differences between a print preview agent and a print user agent?

AG: there are some minor things

CL: the xsl wg is asking if are going to have features like a table of contents, which can link to pages etc

AG: might be more of conformance criteria for print preview UAs

CM: only two reqs differ, just checked

<heycam> http://dev.w3.org/SVG/modules/print/master/SVGPrint.html#user-agents

CM: not sure what it's saying...should it pop up a window for setting print options?

CL: yes

CM: is that really something we need to require?

CL: there are existing printer control languages but we don't want to require any of them
... the intent is that you should be able to print e.g pages 3 - 6

CM: it doesn't seem like something people will forget about or not do if we don't say it
... because it's such a basic thing

DS: i'm questioning if we should be doing this work

CL: there are features like color management

<jwatt> CL: there are two parts to this: proper color, and pages

CM: the way the spec is worded is for printers...but pages and colors are things like scribus and inkscape want to have
... that is, non-printer uses

CL: in svg1.1 color management was optional
... svg print makes it mandatory
... so that it's testable

CM: that's good, but the wording makes it sounds like it's more for a niche case
... makes it sound more printer-specific than it actually is

DS: what pdfxml and this spec is trying to solve are two different problems

<shepazu> DS: I suggest we split this into SVG Pages and SVG Color Management, and move them forward independently

<ChrisL> I agree that the two main features are pretty much orthogonal, so splitting is fine by me

<ChrisL> colour could probably move faster

<shepazu> scribenick: shepazu

RESOLUTION: Pending approval by Canon, we will split SVG Print into SVG Pages and SVG Color Management

Creating collaborative testsuite

JW: in principle it would be good if all implementors could share the same test format
... for automated testing
... 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
... which would put off new implementors and slow them down

DS: also, we know how horrible it was doing test fests at F2Fs

<ed__> jwatt: latest test template: http://dev.w3.org/SVG/profiles/1.1F2/test/templates/

http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-dom-01-f.svg

JW: so you make basic assumptions such as 'rectangles are drawn correctly'
... and you build upon previous assumptions
... so say you wanted to test the <path> element, you might draw what would look like a rectangle with the path
... render that, then in the reference document you draw a <rect>, you're assuming rectangles draw correctly
... and check that they paint the same (pixel for pixel)

AG: you could do calibration with that method
... render a 100x100 red rectangle
... compare it against the reference rendering
... then look at the pixel differences, and use that as a calibration
... in printers you do colour calibration

ED: would you be able to calibrate if you had something that does alignment to a pixel grid for example?
... but off the pixel grid it might not be exactly the same?

DS: even so, calibration is a good idea

ED: probably JW's suggestion here is going to be more accurate

[jonathan shows some tests]

DS: we need to be careful that we don't get consumed in working on tests to the detriment of work on other things

<ed__> http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html