SVG Working Group Teleconference -- 04 May 2009

<trackbot> Date: 04 May 2009

<heycam> Scribe: Anthony

<shepazu> http://www.w3.org/News/2009#item66

<heycam> ScribeNick: anthony

Tighten up the implicit lineto commands in the path syntax

<heycam> ISSUE-2268?

<trackbot> ISSUE-2268 -- Tighten up the implicit lineto commands in the path syntax -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2268

<heycam> DS: I think there are two sensible answers to this

<heycam> ... one, they're always absolute

<heycam> ... (or relative, but absolute makes more sense)

<heycam> ED: i tested a few implementations

<heycam> ... if you have a relative 'm', then you have relative 'l's

<heycam> ... and if you have an absolute 'M', then you have absolute 'L's

<heycam> DS: that's the second sensible one

CM: Erik, you were saying that the first line to is absolute?

ED: Even if it's lower case 'm' it will be absolute

CM: All the subsequent implicit line-to's

ED: That's what the test cases showed

CM: I guess that makes sense
... You can always not use implicit lines if you want particular behavior

ED: I couldn't find any implementation that behaved differently
... but I didn't test ASV

DS: Implementations, the first 'm' whether capital is not is always absolute then everything after is absolute
... need to have a lower case 'm' after the first to make line-to commands relative

CM: Are we going to errata this for 1.1F and 1.2T?

ED: Yes we should

<scribe> ACTION: Anthony to Create an errata of the implicit line to problem mentioned on the list [recorded in http://www.w3.org/2009/05/04-svg-minutes.html#action01]

<trackbot> Created ACTION-2542 - Create an errata of the implicit line to problem mentioned on the list [on Anthony Grasso - due 2009-05-11].

Update on 1.1F 2nd Edition

CM: All of the main chapters are now building properly
... really for the building side of things is to get the element and attribute appendix building
... and to get the element summaries automatically generated from the RNG
... Just need to be careful about updating things
... what I'll do next is generate diffs
... against the current 1.1
... so I get an idea of what's changed
... then can start folding in the errata
... are we going to publish the errata again
... before 1.1F 2nd Edition is published?

CL: If it hasn't gone in we probably should

ED: Would be good to encourage feedback
... before it goes in

CM: I believe it only goes to AC for review

CL: That's right
... normally the Errata gets published
... then people have a chance to comment

CM: So there are changes I've made that aren't in the errata document
... I can still generate a change long to put in the spec

CL: It depends what class of thing
... is being fixed as we go
... are you saying we should have 2nd sitting in the wings
... then produce a big errata thing from that?

CM: I guess that's my question
... if the change long is enough
... then generating a change long doesn't seem a good use of time

AG: I've added some errata in from ages ago

CM: From your commit log I'll check
... the diff logs
... so may be after Anthony puts this errata in
... then publish the errata
... from then on just make changes to the actual check
... rather then put them in the errata
... so this errata publication will be the last errata publication
... does that seem reasonable?

ED: The 2nd edition spec is public
... so people can see the changes

CM: Should we email the list for feedback before we start?

ED: We have to I think

CM: So Anthony do you want to let me know once you've put the errata in?

AG: Yes

DS: That said about the winder review, it might be good to get wider review
... now that we're not caught up in doing SVG Tiny 1.2
... it might be useful to get real feedback from implementors and others

CL: We've already had real feedback
... I don't want to sort of give the message that we are going to do a whole lot more changes
... once the errata gets a bit long
... you put it all in
... then start a new errata

Some questions Heycam had about SVG Fonts

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0084.html

CM: As I was going through 1.1F
... I noticed there was differences between SVG Fonts between 1.1F and 1.2T
... in 1.1F the Font face element has children font-face-src and definition-src
... font-face-src is the matching properties
... and that inside that you have a number of font-face-uri elements
... that point to the actual font file
... and font-name elements
... that point to local
... fonts installed on the system
... in 1.2T name wasn't there
... and was it deliberate?

CL: It was

<ChrisL> i am trying to respond to your question

CL: So, In CSS 2, the idea was, you could have both local aliases and remote aliases
... so I could say font-face=foo corresponds to bar
... for Tiny we felt this was too complex
... and not needed
... we just chopped it down to a single URI to make it more simple
... you could have multiple URI that are a combination of multiple fonts
... so when we put it down to a single URI the container wasn't needed anymore
... definition-src

CM: I thought that definition-src was you could set up a font and reuse it

CL: At one point we talked about constructing composite fonts and you point off to the fonts and give it a name
... but I don't think we tested the composite part in Tiny
... this was moved over to CSS 3

CM: Can we drop definition-src from 1.1?

CL: Yes
... the original idea was apart from downloading fonts, you might synthesize them

CM: The difference between the content models?

CL: I'm not sure that was deliberate

CM: I think it would be ok to change 1.1F to say 0 or 1 definition-src
... and 1 or more font-face-src

CL: 1.1. was incorrect because theoretically you could say a local font and not give a URI for it
... there has to be at least one font-face-src

CM: So 1 or more or just 1?

CL: Just 1

CM: Then for Tiny where it says 0 or more should we update to say 1 or more or 1 exactly?

CL: So basically it should have exactly 1

<scribe> ACTION: Cameron to Fix and align the font elements regarding font-face-src and definition-src in SVG 1.1F and SVG 1.2T [recorded in http://www.w3.org/2009/05/04-svg-minutes.html#action02]

<trackbot> Created ACTION-2543 - Fix and align the font elements regarding font-face-src and definition-src in SVG 1.1F and SVG 1.2T [on Cameron McCormack - due 2009-05-11].

CM: Need to see if there is a test for the units-per-em problem where the default is 1000

CL: There isn't one

<scribe> ACTION: Cameron to Make a test for default units per em value [recorded in http://www.w3.org/2009/05/04-svg-minutes.html#action03]

<trackbot> Created ACTION-2544 - Make a test for default units per em value [on Cameron McCormack - due 2009-05-11].

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0087.html

CL: There are not media types
... and there is not likely to be
... they should be quoted

CM: My suggestion with the quoted properties
... is that the format you want to support?
... are they going to have spaces in them?

CL: they're not going to have spaces in them more so different formats will have different URI
... since its separate now
... it's awkward to pair them up
... so really what we want to have is an attribute
... on font-face-uri
... and it's a separate child which means you can't group them
... so if you have multiple font-face-uris and font-face-formats
... you can't say how they pair up

ED: So if you have multiple font-face-uri elements with multiple formats I don't think we say how we handle them

CM: The string attribute exists already

CL: We actually called it string?

CM: Having an attribute on font-face-uri might be better

CL: And we can say that brings it closer to existing practices
... to what CSS does

CM: At the moment we don't have any tests that have font-face-format in them

ED: Not sure if it's testable

CL: I think it was susceptible to having multiple formats
... I'd rather have it as an attribute
... the question becomes what do we do for 1.2T

CM: I think you're correct it's not in 1.2T

CL: There is one other complication
... what happens if you say it's a type 1 font, but then when it comes back and it's Open type font
... so it said it's something it wasn't
... [reads section in CSS3 about format hint]

CM: so you can provide more than one
... that's the really why I was asking the question about the syntax
... because of the list inside the attribute

CL: Especially for Open Type you can sub types.
... You can actually point to a single font file that can have multiple formats
... I think it's still a bad design to have a format child

DS: I can see Doug's point about this

CL: Although making a change in an untested part of the spec brings us in to line with XSL

DS: I don't object to us starting to have wording that defines this better, but this seems to be a strong difference
... if it were up to me we would work on this for SVG 2.0

CL: We can define it but it'll look ugly

ED: Since tiny doesn't have font-face-format
... another solution is to drop it from 1.1F
... and add it to 2.0

CL: I'm even less happy with that one
... I'd rather keep the CSS and XSL serialisations as close as possible

CM: The only issue at the moment is it's not defined
... I think it would look a bit cleaner as an attribute

CL: It's a bit more clunky than what it needs to be

CM: Keep it as an element?

CL: ok

CM: Change the tests
... to have the quotes inside the format

CL: So ED Opera 10 does look at it?

ED: Yes it does
... I think if you leave off the quotes
... it would ignore the whole thing
... because it wouldn't parse correctly
... I locally fixed some of the tests

CL: Can you check those in please

ED: Sure

<scribe> ACTION: Erik to Commit his local copy of the font tests that have the fixed quotes [recorded in http://www.w3.org/2009/05/04-svg-minutes.html#action04]

<trackbot> Created ACTION-2545 - Commit his local copy of the font tests that have the fixed quotes [on Erik Dahlström - due 2009-05-11].

CM: I guess it would be hard to test, if we are copying the CSS behavior as being a should

CL: Should makes it a bit untestable

CM: You could construct a test that has two possible renderings

ED: Depends on how hard you are on the parsing of the rule
... if it's not correct grammar then you should ignore it

CL: Right, and we don't have that
... about dropping the whole rule
... that argues with the tight coupling

DS: I think you can test it
... like you said
... having two different paths
... but each path being specific about what it tests

CM: Yeah, if the glyph comes out as a circle or a square then it passes

DS: Right
... have strict criteria about the pass
... or about it not downloading it

CL: So the issue is you don't have to download it, but if you do then that's ok

Heycam asking about references in 1.1F 2nd

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0090.html

CL: In 1.1F we use DOM 2 because that was the current one at the time
... in 1.2T we started reference DOM 3 events
... is it possible to point to DOM 3 core but only reference the DOM 2 parts
... if you update the reference are you asking if we have to do all that stuff?

CM: Yes
... compared to other references where it's just bug fixes

CL: BCP-47

CM: Is reference it a good idea?

CL: Yes it is
... XML already made that change
... if you can point to the latest version
... I agree we should not add a reference XML 1.1

DS: XML 1.1 is mostly being folded in to XML 1.0

CL: I think eventually we'll have to errata Tiny and reference XML 1.0

CM: So there is a paragraph about XSLT 2
... they are referenced as informative things
... and Tiny references them to be a bit more complete
... alright I'll do those changes

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2009May/0015.html

foreignObject and position:fixed children

CL: He has a good point
... yes it should
... establish a new containing block

CM: My feeling is like foreignObject is like object in HTML

ED: I agree

<scribe> ACTION: Chris to Respond to Jonathan's email regarding foreignObject [recorded in http://www.w3.org/2009/05/04-svg-minutes.html#action05]

<trackbot> Created ACTION-2546 - Respond to Jonathan's email regarding foreignObject [on Chris Lilley - due 2009-05-11].

DS: Regrets for me on Weds

CL: Same for me and the following week

ED: Do we want to cancel the Wed telcon?

CM: I don't mind

DTD in 1.1F 2nd

CM: We already decided to down play them
... I had already taken out the sections for the content set
... which do mapping
... that might have been over done
... because sections say chapters can be put in to a module

CL: I think we should down play it
... doesn't think it adds any value in practice

CM: The organisation is going to be there in the DTD
... in the introduction there is a section where it talks about these modules

<heycam> http://www.w3.org/TR/SVG11/intro.html#Modularization

CL: I don't really want to drive people down that path

CM: I can do without the RNG for now
... getting the attribute and element appendix published, I'll need the RNG for that
... so in the intro there's a bit about the collections
... in the main chapters

<heycam> http://www.w3.org/TR/SVG11/shapes.html#shape-mod

CL: There's a horrible thing there
... it is an error to include a subset and superset of the same group
... I don't think we should say that

CM: I think it's going to fall out to be an error

CL: Maybe we should change the wording to say that
... "Including a superset and a subset of the same group will produce an error"

CM: in the main chapters it includes some parts of the DTD
... I've taken them out
... but I'm just wondering if that's ok, because of the module structure

ED: I think 1.1T references those tables
... so I think they still have to be there
... otherwise we'll have to change them to point somewhere else

<ed> http://www.w3.org/TR/SVGMobile11/

ED: plenty of links there to those type of modules

CM: The only reason I wanted to remove them

<ed> s/1.1T/1.1 Mobile (basic/tiny)/

CM: was because they were cluttering up the chapters

<ChrisL> Suggest changing the title from, say, 9.9 Shape Module to 9.9 Shape DTD Module

CM: If you validate for DTD doesn't guarantee conformance
... and the same for the RNG

CL: So I suggest changing the name of the section heading
... For adding new stuff, I'll try to conform that module structure

<ed> s/1.2T and//

CL: I'm a little bit concerned that how to be sure that everything that was previous valid to the DTD
... is now valid to the RNG
... I think there are tools that let you take a DTD that generates random content that conforms to it
... I'm wondering if it will create a bunch of weird things

CM: So there are various things that couldn't be expressed in the DTD that we want in the RNG

CL: But if something is invalid to the DTD it should also be invalid to the RNG

CM: The DTD and the schema can show that you have something that doesn't conform

- DRAFT -

SVG Working Group Teleconference

04 May 2009

Attendees

Contents