SVG Working Group Teleconference -- 30 Jun 2011

<trackbot> Date: 30 June 2011

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals

<vhardy> ScribeNick: vhardy

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals

ED: Topic: reminder to add agenda requests to agenda proposal
... Today is the last day to propose topics. However, we can extend the deadline because we do not have enough topics.
... 1 week more?

CM: yes, that is fine.

ED: I would like people to add longer descriptions for the topics.

CL: which CSS modules will CSS2 depend on? Can you add a placeholder on the F2F agenda?

ED: yes.
... done.

CL: Reminder that SVG 1.1 2nd edition is still a PR, but we do not have enough AC rep responses. It would be better to get more responses. Please remind your AC reps if they have not responded yet.

<heycam> http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

VH: who responded?

CM: http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

ED: there is a formal objection from INNOVIMAX.

CL: Is that a formal objection.

ED: It looks like a formal objection.

Tav: there is comments on incorrect references.

CL: Did the DTD change with 2nd edition?

ED: very, very slightly. We had some small fixes. I am not sure if that was for 2nd edition or if it was released before.

CL: I'll look at the objections and respond.

<scribe> ACTION: CL to respond to the SVG 1.1 2nd edition objections at http://www.w3.org/2002/09/wbs/33280/svg11-2011/results [recorded in http://www.w3.org/2011/06/30-svg-minutes.html#action01]

<trackbot> Created ACTION-3057 - Respond to the SVG 1.1 2nd edition objections at http://www.w3.org/2002/09/wbs/33280/svg11-2011/results [on Chris Lilley - due 2011-07-07].

<scribe> ACTION: ED to send an email reminder to people to add their agenda requests to http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals. Also add a placeholder for the F2F schedule. [recorded in http://www.w3.org/2011/06/30-svg-minutes.html#action02]

<trackbot> Created ACTION-3058 - Send an email reminder to people to add their agenda requests to http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals. Also add a placeholder for the F2F schedule. [on Erik Dahlström - due 2011-07-07].

ED: Topic: Joint FX deliverables.

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0169.html

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/att-0169/FX_Task_Force_and_Related_CSS___SVG_Specifications_and_Drafts.html

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/att-0172/FX_Task_Force_and_Related_CSS___SVG_Specifications_and_Drafts.html

RESOLUTION: work on a single consolidated specification for 2D and 3D transforms that apply to CSS and SVG

VH: the next one is similar. It captures the last exchange on the mailing list.

CM: sounds right.

RESOLUTION: a) Work on the CSS Animation and CSS Transitions specifications in the FX task-force. Make sure they work for SVG properties and attributes. b) Have a specification for defining timing, synchronisation and scripting API. It is not yet decided where that specification would live. This specification would be referenced by SVG 2.0 and whatever other CSS-syntax animation specifications exist.

ED: next one is on advanced text layout.

VH: I do not think we had a discussion on this, or at least I do not recall.

CL: what does that mean?

VH: wrapping text to a shape, sizing shapes to fit text, vertical text.

CM: we already support vertical text.

CL: there was support in ASV. But the CSS WG is now working on the css-writing-mode module. We should probably align with that.

ED: there was not many tests on vertical text in the test suite.

CM: I agree we should follow what the CSS WG defines on vertical text. It seems from a different thing than the other topics.

RESOLUTION: The SVG WG would like to align future editions of the SVG specification with CSS writing modes for vertical text layout.

CL: We had some feature on wrapping text in shapes in SVG 1.2. I know XSL was interested in it but they had a different way to go about it. They did not want to use our line breaking.
... I have not heard things about that in CSS.

VH: There is a draft in the CSS WG called CSS Exclusions: http://dev.w3.org/csswg/css3-exclusions/

DS: Is this assuming a line-breaking algorithm? Or does it define it? Or is it implementation dependent.

VH: the current draft does not define a line breaking algorithm.

DS: Does CSS specify this?

VH: yes, there is discussion about breaking in the CSS specification.

DS: there were criticism in the past that line breaking in SVG was incompatible with CSS.
... however, I never got a precise explanation of how it was incompatible.
... Is the line-breaking somewhat implementation dependent?

CM/VH: yes, we think so.

VH: it would be difficult not to have some dependencies.
... there are issues such as control character processing that are difficult to get consistent across implementations.

CL: yes, we had similar problems in some of the SVG algorithms (e.g., curve intersections). I am not surprised that getting some implementation dependence is allowed.

DS: Is there a way to specify some level of tolerance?
... this would help authors to get content to look the same across implementations?

CL: we have a 1px tolerance in SVG and not a 0.5 pixel because of implementation variations.

CM: In the text-wrapping case, even a 1px difference can impact line breaking and result in a bigger visual difference.

VH: I think that the issue of turning characters into glyph vectors and the issue of breaking lines into paragraphs or line segments for shape fitting should be aligned with CSS.

CM: I agree with that. You can always insert line breaks if needed.

DS: I agree too.

CM: It is a valid concern to know and control where breaks go.
... if you align a text that is slightly larger than expected, it should be possible to scale the line to fit in the expected length.

CL: Boeing pointed out recently that implementers do not honor textLength which allow this feature.

DS: there is also the issue of having text that adapts to the size of a box and boxes that adapt to the text content. Are there properties to put ellipses when text overflow?

CL: yes, there is.

DS: then we should think about this interacts with textLength.

VH: the CSS Exclusion spec. should allow pointing to an SVG shape.

Tav: the current draft does not allows wrapping an SVG text element in a shape.

VH: yes, that is right. If you needed a text wrapped in a shape, you would use a <foreignObject> with a div to create the effect (unless we add more integration features).

DS: did you say that SVG does not have a use case to wrap around shape?

Tav: you can make the effect of an exclusion with a wrap inside.

DS: yes, you can do that, but it may be simpler with a wrap-around shape.

Tav: yes, but that is more than what 1.2 was doing.
... I do not want to have a foreignObject in order to have text in a shape.

DS: we could apply the same CSS rules to some other elements than divs.

RESOLUTION: The SVG WG would like to have coordination on the CSS Floats/CSS Exclusion effort so that text wrapping inside or outside arbitrary shapes can be done on SVG elements and exclusions can be defined by SVG elements.

CM: The important thing is to use the same text layout model, and that is where the difficulty lies.
... we do not want SVG to require a different text layout engine.
... this is similar to what VH was saying before.

VH: the third item on text was 'sizing shapes to fit text'.

CM: Is that being addressed in CSS?

DS: CSS can already sort of do that based on the box model. This is important for SVG.

CM: it depends on what we mean by shapes.
... boxes or arbitrary shapes?

DS: yes, is it constraints?

VH: I think the CGPM spec. had some thoughts in that direction?

CL: yes, there was some work in that area, for the print space.
... for constraints systems, it is hard to get something satisfying or efficient.
... it is not an easy problem.

VH: Should we ask this to be a requirement for CSS Floats?

CL: it is reasonnable to ask.

CM: there is not a lot of enthusiasm to work on this at the moment, so may be we should not work on it right now.

DS: yes, we have other problems to work on.

VH: This could be a requirement for CSS Floats. I can see use cases.

CM: There are different options, like the SVG textLength feature or using scripting.

CL: I think it is easier to say upfront that it should be considered as a requirement. If we do not ask, we will not get it.

VH: agree.

CM: is that for sizing text or shapes?

VH: both.

RESOLUTION: the SVG WG would like the CSS Float/Exclusions effort to consider the ability to size text to fit in a particular shape or to size a shape to accommodate for a particular text flow.

<scribe> ACTION: VH to update FX worksheet and send to SVG and CSS working groups. [recorded in http://www.w3.org/2011/06/30-svg-minutes.html#action03]

<trackbot> Created ACTION-3059 - Update FX worksheet and send to SVG and CSS working groups. [on Vincent Hardy - due 2011-07-07].

ED: Topic: SVG Fonts inside of OpenType.

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Jun/0042.html

CL: it is interesting, because it uses all the good things of OpenType and uses SVG for glyph definitions. It is based on the SVG full syntax for fonts, not SVG tiny. That is good. It also deals with some of the browser vendors objections to use SVG.
... the way CFF was put inside OpenType is that all of OpenType1 was put in the format. It was useful but may be wasteful. We do not need that solution for SVG. It would be better to just have glyph collection. For example, we would use the open type kerning tables, not SVG's. I think this approach is nice, and we should do it.
... this is unlikely to happen in the SVG WG. It has a chance to happen in OpenType and it provides benefits.

ED: would that include defining an SVG Full font module? Could it be based on 1.1?

CL: I think it could be based on 1.1
... there are some issues to resolve. I think the people who want to use SVG need to coordinate with us.

ED: yes, there are issues around coordinate systems that we would need to discuss.

CM: one advantage of including the whole SVG document is that you have an obvious place to put shared resources, like gradients and patterns. This would allow implementations to reuse a lot of machinery.

VH: Is there a request from the group?

CL: not really. This is more a discussion. The person who sent the email is a font designer.
... They work for the company that does the main font design tool.

CM: I felt slight opposition from ED. Can you explain?

ED: I have an objection. One benefit with the SVG fonts we have is that you can build them easily by DOM operations and use them right away. It would be more difficult if you had to write out a binary blob with an open type container. It would be harder to make dynamic updates to it.

CL: I agree, but that is not unmanageable. But the open type implementation will do the unpacking, but we could specify that the glyphs get exposed as DOM. OpenType people use programming quite a bit. The ability to access the glyphs through scripts may be seen as a good thing.

ED: ok, it can be solved, but it is one of the things that is possible today and I'd like the same features to be met.

CM: I agree that building a binary stream is making things harder.
... using OpenType also simplifies things, and that may be worth it.

ED: I agree that using OpenType would simplify and the existing tables would be nice. Would give us more features for SVG fonts. In that respect it is a good proposal.

CM: someone was working on an XML serialization of OpenType. But this way is probably better.
... I think leaving things in the OpenType font is cleaner.

ED: I am not sure if that was clear in the proposal: would it be possible to make composite fonts, with some glyphs from SVG and others not.

CM: Yes, I think that was the intention.
... It has the advantage of being backward compatible. If the implementation does not support SVG, it falls back on glyphs in the regular tables

ED: the other thing I mentioned is that they are asking if it would be useful to have scripts running in the font?
... I do not really have an objection.

VH: this would be a security concern.

CM: SMIL animations would be good.

CL: yes, definitely.

CM: the font should have its own timeline. Otherwise, the font would have to be instantiated for each document using it.

ED: yes, this is also an argument to have an SVG container in there.

CM: yes. you would have to say, if no container, that a container needs to be synthesize, so we might as well require the container.

CL: Yes, but that will need to be explained.

CM: The shared resources should be clear. There needs to be a place for the shared resources.

ED: another concern is the use of external resources. The SVG could reference videos, images, fonts, etc... I guess you would want to not have external references.

CL: that is a reasonnable requirement.

CM: in that case, you probably do not want base64, but binary encoding.

(discussion on multi-part MIME).

ED: what has been the reception on the font mailing list.

CL: it was cross posted and some people responded.
... the responses have been split all over the place.

CM: colors seems to be a valid concern that was raised.
... I saw somebody else ask about parametrization (for different highlight colors).
... seems like SVG parameters could help.
... some of the issues that were brought up are things we should resolve (e.g., you can't easily stroke SVG font glyphs because they are in a different coordinate system).

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

CL: we've got currentColor
... and vector effects can reference currentFill, currentStroke
... so I think we could generalise those out to be used elsewhere
... if you have a 4 colour font, you should be able to parameterise it
... instead of passing in a single colour like you currently do, you pass in 4 colours

ED: what about the cases where you want the gradient fill on some text, and you have a few multi coloured glyphs
... I would assume the gradient wouldn't be applied to those fancy glyphs
... but that's what would happen if we went with how it's defined currently

CL: I think there's a need to mix defined colours and parameterised or normal paints
... an example I've used before is the sort of font you saw in jurassic park
... there's a red part in the middle, and a yellow bit that could be other colours
... so whatever colour you chose, tehre'd be red in the middle
... a keyword like textColor could be used

- DRAFT -

SVG Working Group Teleconference

30 Jun 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output