- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 1 Jul 2011 09:36:57 +1200
- To: www-svg@w3.org
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]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
30 Jun 2011
[2]Agenda
[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
Attendees
Present
ed, +1.415.832.aaaa, heycam, ChrisL, tbah, shepazu
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
* [5]Summary of Action Items
_________________________________________________________
<trackbot> Date: 30 June 2011
<ed>
[6]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_pr
oposals
[6] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals
<vhardy> ScribeNick: vhardy
<ed>
[7]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_pr
oposals
[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
yet.
<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
[11]http://www.w3.org/2011/06/30-svg-minutes.html#action01]
[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
[13]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_p
roposals. Also add a placeholder for the F2F schedule. [recorded in
[14]http://www.w3.org/2011/06/30-svg-minutes.html#action02]
[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
[15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_p
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.
<ed>
[16]http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/016
9.html
[16] http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0169.html
<ed>
[17]http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/att
-0169/FX_Task_Force_and_Related_CSS___SVG_Specifications_and_Drafts.
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
<ed>
[18]http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/att
-0172/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
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:
[19]http://dev.w3.org/csswg/css3-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
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
[20]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>
[21]http://lists.w3.org/Archives/Public/www-svg/2011Jun/0042.html
[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
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).
<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
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
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
[24]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_p
roposals. Also add a placeholder for the F2F schedule. [recorded in
[25]http://www.w3.org/2011/06/30-svg-minutes.html#action02]
[NEW] ACTION: VH to update FX worksheet and send to SVG and CSS
working groups. [recorded in
[26]http://www.w3.org/2011/06/30-svg-minutes.html#action03]
[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