minutes, 30 June 2011 SVG WG telcon

The minutes from today’s SVG WG telcon are at
http://www.w3.org/2011/06/30-svg-minutes.html and below as plain text.


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

30 Jun 2011


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0171.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/30-svg-irc


          ed, +1.415.832.aaaa, heycam, ChrisL, tbah, shepazu




     * [4]Topics
     * [5]Summary of Action Items

   <trackbot> Date: 30 June 2011


      [6] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals

   <vhardy> ScribeNick: vhardy


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

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

      [8] http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

   VH: who responded?

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

      [9] 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 [10]http://www.w3.org/2002/09/wbs/33280/svg11-2011/results
   [recorded in

     [10] http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

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

     [12] http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

   <scribe> ACTION: ED to send an email reminder to people to add their
   agenda requests to
   roposals. Also add a placeholder for the F2F schedule. [recorded in

     [13] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals.

   <trackbot> Created ACTION-3058 - Send an email reminder to people to
   add their agenda requests to
   roposals. Also add a placeholder for the F2F schedule. [on Erik
   Dahlström - due 2011-07-07].

     [15] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals.

   ED: Topic: Joint FX deliverables.


     [16] http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0169.html


     [17] http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/att-0169/FX_Task_Force_and_Related_CSS___SVG_Specifications_and_Drafts.html


     [18] 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

   CL: what does that mean?

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

   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:

     [19] 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

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

   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

   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

   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

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

   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

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


     [21] 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

   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

   (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).

   <ed> hmm... <text fill="blue"
   font-family="coolanimated-colorful-font">how does this look?</text>

   <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
   ... 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
   ... but that's what would happen if we went with how it's defined

   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

Summary of Action Items

   [NEW] ACTION: CL to respond to the SVG 1.1 2nd edition objections at
   [22]http://www.w3.org/2002/09/wbs/33280/svg11-2011/results recorded
   in [23]http://www.w3.org/2011/06/30-svg-minutes.html#action01]
   [NEW] ACTION: ED to send an email reminder to people to add their
   agenda requests to
   roposals. Also add a placeholder for the F2F schedule. [recorded in
   [NEW] ACTION: VH to update FX worksheet and send to SVG and CSS
   working groups. [recorded in

     [22] http://www.w3.org/2002/09/wbs/33280/svg11-2011/results
     [24] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals.

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 30 June 2011 21:37:33 UTC