- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 13 Feb 2009 09:45:51 +1100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
http://www.w3.org/2009/02/12-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 Feb 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0128.html
See also: [3]IRC log
[3] http://www.w3.org/2009/02/12-svg-irc
Attendees
Present
ed___, [IPcaller], heycam, shepazu, anthony, ChrisL
Regrets
Chair
Erik
Scribe
anthony
Contents
* [4]Topics
1. [5]Vector Effects
2. [6]Sydney F2F action priorities
3. [7]Issue 2002
4. [8]ISSUE-2021
5. [9]ISSUE-2182
6. [10]CSS integration issues
7. [11]ISSUE-2049
* [12]Summary of Action Items
_________________________________________________________
<trackbot> Date: 12 February 2009
<shepazu> sigh
<shepazu> stupid bots
<shepazu> \me ' flight leaves at 10:30 pm
<shepazu> Thu 12 Feb, 2009
<shepazu> Qantas
<shepazu> Los Angeles to Sydney
<shepazu> flight: QF12
<shepazu> depart: 22:30
<shepazu> arrive: 08:10, 14 Feb 09 (Sat)
<scribe> Scribe: anthony
Vector Effects
CL: Got it out just about 30 mins
... will give time to for people to look at it
Sydney F2F action priorities
ED: I was wondering if there are some particular actions that should
be looked at before the F2F
... I have about 30-40 actions
... I might do some while travelling
... currently I'm thinking I'll do a bit of HTML 5 reading and a few
of the filter spec actions
... or if anyone else has any actions they want to priorities
CL: They sound like good priorities
ED: I just made a few minor updates to the F2F page
<ed___> [13]http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009
[13] http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009
ED: Mostly stuff to get minuted resolutions
... as a reminder for us
... HTML5 + SVG is something we have to complete soon
... as well as Full 1.1 errata
... and modules
Issue 2002
ISSUE-2002
ISSUE-2002?
<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster
images used in the <image> element -- RAISED
<trackbot> [14]http://www.w3.org/Graphics/SVG/WG/track/issues/2002
[14] http://www.w3.org/Graphics/SVG/WG/track/issues/2002
ED: I committed a proposal for viewBax attribute on raster images
... CMC sent an email saying there is something similar in CSS3
... 'crop' property
... I put in a couple of test cases
... and I think batik and all of the other browsers except for I.E.
produce similar results
... which is ignore it
... I'm wondering if the 'crop' might be good for us?
CL: Question is why do they ignore viewBox
ED: I think the spec is quite unclear, it doesn't say you can't use
it for viewBox
... I guess this could qualify as an errata item, but it's more like
a future feature
... I didn't find a viewer that did something else with it
CL: And this is just for raster images?
ED: Yes
... for SVG images the viewBox will effect the image
... I was going to put a test for it
... wont be too difficult to make
... It is quite simple to put on top of what we have anyway
CL: Where does it really make a difference?
... miss match in aspect ratio?
... putting xMid, yMid?
... what are we missing
ED: We are missing the capability to select a certain part of the
image
CL: If you are talking about errata you could put that in with an
example
... if you have an image with a vewBox then the image should be blah
... this sort of clarification could be an errata
<shepazu> since we are looking at <image>, I would also like to
consider allowing @stroke properties on <image>
<shepazu> it's a new feature, so we shouldn't add it to SVG 1.1
ED: Should we make an errata or should we address it in Core 2.0?
<shepazu> we should also look at this in terms of the clipPath
CL: It's not a new feature is it?
ED: It's definitely vague in the text, but I didn't find anything
that explicitly overrides the viewBox for raster images
DS: I think it's a clarification it's new behaviour
... because it changes conformance
... you are saying that you can use the viewBox on the image
element?
ED: It does give you an example, but it doesn't explicitly say can't
override it
<ed___> ED: also it doesn't say that if you specify a viewBox on a
raster it should use pixel units
<shepazu> shepazu: if 1.1 says you can't override it, we shouldn't
change that in 1.1, but we could reexamine if that's useful in 2.0
<ed___> ED: as in actual raster image pixels
ED: SVG 1.1 says the image element has a viewBox and you can
reference something
<shepazu> url?
ED: it doesn't tell you exactly how to treat viewBoxes on raster
iamges
<ed___> [15]http://www.w3.org/TR/SVG11/struct.html#ImageElement
[15] http://www.w3.org/TR/SVG11/struct.html#ImageElement
<ChrisL> An 'image' element establishes a new viewport for the
referenced file as described in Establishing a new viewport. The
bounds for the new viewport are defined by attributes x, y, width
and height. The placement and scaling of the referenced image are
controlled by the preserveAspectRatio attribute on the 'image'
element.
ED: The next paragraph after that one explains how you handle it
when you reference an SVG image
CL: The next bit after that says you have to make the image as large
as possible while preserving the aspect ratio
... If you specify explicitly it's the same as the SVG case, it
covers all of it but has bits left over or it covers the edges
... if I have a viewBox 0 0 60 30
<ChrisL> suppose i have an explicit viewbox 0 0 60 30 ie a 2x1
rectangle
<ChrisL> and my raster image is 400x400 pixels
<ChrisL> its clear from the text how to fit that raster into that
viewbox
<ChrisL> depending in the value of other attributes
<ChrisL> the only unclear part is where the viewBox is *not*
explocitly stated
<ChrisL> in which case, i propose an erratum that says (for that
image) its 0 0 400 400
<ChrisL> is that clearer?
ED: If you what you're saying is correct, then we might need to put
something else in for
... what I was proposing
<ChrisL> the reference viewbox cannot be overidden
ED: So I will withdraw the proposal, in which case the 'crop'
property seems like a pretty good idea
... the problems it intends to solve are unaddress, i.e the issue is
still open
AG: The spec doesn't have any crop feature at all
... that will be a new feature
ED: So is this something we will have clarify in 1.1 then?
... So the question is should I open a new issue?
... or keep it there
CL: I think keep it there
... so we know how we arrived at that
ISSUE-2021
ISSUE-2021?
<trackbot> ISSUE-2021 -- Bounding box of <image> subject to
aspect-ratio preservation undefined -- RAISED
<trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2021
[16] http://www.w3.org/Graphics/SVG/WG/track/issues/2021
ED: That's already on Core 2.0
... the question was raised by CMC
CMC: Long time since I looked at this one
... to be honest I haven't looked at the call
... it's look like I've tested a couple of UAs to see what they do
currently
... the comment about determining the aspect ratio using script - I
do that at the moment
ED: There could be other ways of solving that problem
... exposing the width and height of the image
CMC: Exposing the width and height of the image would solve the
problem
ED: I agree it would be very nice to have
... when I do this currently I do it in HTML
CL: The viewBox will determine the width and height of the image
... can't you query that?
CMC: Are you saying to look at the viewBox property and get the
width and height from that?
CL: Yes
<ed___>
[17]http://www.w3.org/TR/SVG11/types.html#InterfaceSVGFitToViewBox
[17] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGFitToViewBox
<ed___>
[18]http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGImageElement
[18] http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGImageElement
ED: I don't see that interface
<ed___> [19]http://www.w3.org/TR/SVG11/idl.html
[19] http://www.w3.org/TR/SVG11/idl.html
AG: You can query the viewBox but you may not get the original image
width and height
... because if the viewBox doesn't match the image aspect ratio then
... one of the dimensions will be wrong
CMC: Preserve aspect ratio is on SVG Image element and on SVG Fit to
View Box interface
... looks like it was left out somehow
... I can't think why you wouldn't want to expose that
ED: So if the viewBox was exposed would it be enough to solve the
problem completely?
CMC: It wouldn't solve the case of getting the original width and
height of the image
ED: So I still think when you define the viewPort and use viewPort
fill you will perhaps use the space that is not covered by an image
CMC: Not sure, but it's a good test for Tiny
... If you have a circle and the fill is none the stroke is none
then the bounding box is still the circle and not nothing
<ed___> safari also says 0,0,400,400 btw
CMC: maybe if theviewPort fill is not none then maybe the whole area
is the BBox, but it may make BBox less useful.
ED: I think there are other things about image that make it less
useful
... for example wanting to display images at their native resolution
regardless of scaling
... it is in a way related
... if you are able to get the dimensions of such images
... I think exposing the viewBox property would be useful
... even though it would be less useful than exposing the intrinsic
width and height
... CMC do you want to propose something?
<scribe> ACTION: Cameron to Propose a number of different solutions
to solving the problem of extracting the width and height of an
image in ISSUE-2021 [recorded in
[20]http://www.w3.org/2009/02/12-svg-minutes.html#action01]
<trackbot> Created ACTION-2455 - Propose a number of different
solutions to solving the problem of extracting the width and height
of an image in ISSUE-2021 [on Cameron McCormack - due 2009-02-19].
ISSUE-2182
ISSUE-2182?
<trackbot> ISSUE-2182 -- Consider adding new interface for easier
use of positional properties -- RAISED
<trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2182
[21] http://www.w3.org/Graphics/SVG/WG/track/issues/2182
ED: It's about adding new positional properties
... so this suggests adding a new interface on event called
'getPosition'
... it's not exactly clear what's this suggesting
<shepazu> ISSUE-2182?
<trackbot> ISSUE-2182 -- Consider adding new interface for easier
use of positional properties -- RAISED
<trackbot> [22]http://www.w3.org/Graphics/SVG/WG/track/issues/2182
[22] http://www.w3.org/Graphics/SVG/WG/track/issues/2182
DS: We talked about this before, this is the idea of doing drag and
drop for example
... you might want to get the actual position
... even with get client and BBox you don't get all the information
you want
... what you want is the relative position of the mouse
... you really want to know where it appears on the screen
... you could also get things like transform which is a combination
of CTM and other information
... I guess the key is the first part
... but it would be useful to have it all in one place
ED: So something to automatically convert from client space to user
space?
<shepazu> yeah, more or less
CMC: Was there anything other than X,Y that you want to expose on
that?
<shepazu> I can't think of anything other than x/y right now?
CMC: or do you want to take the X,Y and do the transformation
automatically
... Ok
<shepazu> I will write a proposal into the 2.0 kitchensink doc
ED: Do you want the option to go the other way in the same
interface?
CMC: I think if you can go one way you can do the the calculations
ED: So DS if you can write something up in spec that would be good
<shepazu> ACTION: shepazu to write a proposal for inuitive x/y
method [recorded in
[23]http://www.w3.org/2009/02/12-svg-minutes.html#action02]
<trackbot> Created ACTION-2456 - Write a proposal for inuitive x/y
method [on Doug Schepers - due 2009-02-19].
<shepazu> er... intuitive
<heycam>
[24]http://lists.w3.org/Archives/Member/w3c-tools/2009JanMar/0002.ht
ml
[24] http://lists.w3.org/Archives/Member/w3c-tools/2009JanMar/0002.html
CSS integration issues
ED: I collected a bunch of issues
... there are two relating to CSS whitespace ISSUE-2039 and
ISSUE-2172
... which are quite similar
CMC: They are quite similar
ED: I was thinking of closing the older one and just having one of
them
... we could close the old one and link back to the new one if we
need to
CMC: On the face of it seems like a good idea
... but I haven't looked at it closely either
ED: That's the overall issue though, is looking at other CSS
properties that we could integrate into SVG
CMC: I think it would be good to go through all the properties we
don't use and see if we can use some of them
... bit of a jump
ED: It probably makes sense to break it down a bit
... A good starting point is to look at what is widely supported and
currently not in SVG
... My starting point would be to go through the Opera code to see
what we have
... the look at FireFox and Surfari
<ed___> s/surfari/surfin' safari/
CL: The problem with the whitespace property is it mixes in a few
different things
... which is not helpful
... which is why XSL split it into a few sub properties
ED: So which of the properties did they split it into?
<ChrisL> [25]http://www.w3.org/TR/xsl/#white-space-treatment
[25] http://www.w3.org/TR/xsl/#white-space-treatment
<ChrisL> [26]http://www.w3.org/TR/xsl/#white-space-collapse
[26] http://www.w3.org/TR/xsl/#white-space-collapse
<ChrisL> [27]http://www.w3.org/TR/xsl/#wrap-option
[27] http://www.w3.org/TR/xsl/#wrap-option
CL: At least 3
... white-space-treatment, white-space-collapse, wrap-option
... line-feed-treatment
<ChrisL> 7.31.23 "white-space"
<ed___> [28]http://www.w3.org/TR/xsl/#white-space
[28] http://www.w3.org/TR/xsl/#white-space
CL: It takes the values from CSS2 and says how it maps to the XSL
ones
... we don't really have wrap in SVG
... it's very HTML centric. All the things are good but you may want
to do them in combination
ED: I guess we don't have much of this problem yet
... line wrapping is very simplistic so far
... I guess it's a question of what we put in to the next major spec
... I'm wondering if you can use xml:space
... I guess you could. It would be kind of strange
... this seems like an area for further study
CL: I don't think it's directly applicable
... I think if we were to split it up like XSL we would come up with
different combinations
... that suit SVG
ED: Is it worth asking the CSS WG to adopt new properties/behaviour?
CL: I guess for specs after 2.1
ED: I looked at whitespace in SVG it is rather messy
<ed___> <text>foo<tspan>bar</tspan></text>
<ed___> is there a space or not between foo and bar?
ED: It also has an effect on underlining and overlining
... some examples were sent a long time ago to the working group
list
CL: Maybe you can add a pointer to those examples
... in the Issue, if you find them again
ED: So maybe we can leave this issue open for now
... that could be something some can do which is to go through the
whitespace section
ISSUE-2049
CL: I thought we added href to style?
... I'm surprised to see it again
... what I think discussed it and agreed on it
... just never propagated to where it's suppose to be
... this was a long time ago
... this is when we decided to add a href to script
... but anyway, it's seems an obvious thing to do
... it seems easy enough to do, and brings us inline with HTML
ED: I know there is a link element, but I haven't seen anything
exactly the same
CL: The only thing you need to discuss is the order of inclusion for
CSS
ED: I think in my opinion that would take us further from HTML
... I think having a link element in SVG would be more useful
... because you could link to other resources
<ed___>
[29]http://dev.w3.org/html5/spec/Overview.html#the-style-element
[29] http://dev.w3.org/html5/spec/Overview.html#the-style-element
CL: In some ways that is a better way - to use import
ED: That is useful for somethings, and I have had cases where I
needed the link element
DS: I actually made an experiment that brings the xhtml:link element
in SVG and it allows you to bring in CSS style sheets in SVG
CL: In the XHTML name space I'm guessing?
ED: Yes
CL: So adding it to the SVG is of value why?
DS: You don't need to use name spaces
CL: The down side is old content breaks. It becomes interoperable
DS: So when people use it in HTML content it would just work
... it would be closer to what HTML does
... it would be trivial for the browsers to add this
CL: I'm worried that they might come back and say we have something
already
DS: I think we should ask them
<scribe> ACTION: Doug to Email the public list and representatives
of the major browsers and ask if having a link element would be
useful for them [recorded in
[30]http://www.w3.org/2009/02/12-svg-minutes.html#action03]
<trackbot> Created ACTION-2457 - Email the public list and
representatives of the major browsers and ask if having a link
element would be useful for them [on Doug Schepers - due
2009-02-19].
Summary of Action Items
[NEW] ACTION: Cameron to Propose a number of different solutions to
solving the problem of extracting the width and height of an image
in ISSUE-2021 [recorded in
[31]http://www.w3.org/2009/02/12-svg-minutes.html#action01]
[NEW] ACTION: Doug to Email the public list and representatives of
the major browsers and ask if having a link element would be useful
for them [recorded in
[32]http://www.w3.org/2009/02/12-svg-minutes.html#action03]
[NEW] ACTION: shepazu to write a proposal for inuitive x/y method
[recorded in
[33]http://www.w3.org/2009/02/12-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [34]scribe.perl version 1.133
([35]CVS log)
$Date: 2009/02/12 21:05:43 $
_________________________________________________________
[34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[35] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [36]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/9for/(for/
Succeeded: s/then>/then?/
Succeeded: s/tiny/Tiny/
FAILED: s/surfari/surfin' safari/
Succeeded: s/thigns/things/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed___, [IPcaller], heycam, shepazu, anthony, ChrisL
Present: ed___ [IPcaller] heycam shepazu anthony ChrisL
Agenda: [37]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMa
r/0128.html
Found Date: 12 Feb 2009
Guessing minutes URL: [38]http://www.w3.org/2009/02/12-svg-minutes.html
People with action items: cameron doug shepazu
[37] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0128.html
[38] http://www.w3.org/2009/02/12-svg-minutes.html
End of [39]scribe.perl diagnostic output]
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 12 February 2009 22:46:35 UTC