- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Tue, 24 Feb 2009 07:47:46 -0800
- To: Cameron McCormack <cam@mcc.id.au>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
I hadn't thought about it before but if you are going to require color management in SVGPrint (or SVG Color Management) you will need to add a few more constructs to the language and the rendering model in order to better handling transparency - most specifically the "transparency blending space" and the ability to set that at both the <g> and <svg> level.
Leonard
-----Original Message-----
From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Cameron McCormack
Sent: Monday, February 23, 2009 6:34 PM
To: public-svg-wg@w3.org
Subject: Minutes Sydney 2009 F2F day 5
http://lists.w3.org/Archives/Public/www-archive/2009Feb/att-0104/19-svg-minutes.html
and below as text.
W3C
- DRAFT -
SVG Working Group Teleconference
19 Feb 2009
See also: IRC log
Attendees
Present
Cameron, Erik, Doug, Anthony, Jonathan, VirtualChris
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron, Erik
Contents
• Topics
1. Layout requirements continued
2. SVG Print
3. Creating collaborative testsuite
• Summary of Action Items
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<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
Summary of Action Items
[NEW] 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]
[NEW] 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]
[End of minutes]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Minutes formatted by David Booth's scribe.perl version 1.134 (CVS log)
$Date: 2008-11-14 12:03:15 $
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 24 February 2009 15:48:40 UTC