SVG fonts in OpenType (was: minutes, 26 January 2012 SVG WG telcon)

All,

in last week's meeting, there was a discussion on the state of OpenType
fonts that contain SVG glyphs.
I pinged Sairus Patel from Adobe on his status. He told me that he's
participating in the community group (
http://www.w3.org/community/svgopentype) and will provide a more detailed
proposal at the Fed 6-10 MPEG meeting.

Rik

On Thu, Jan 26, 2012 at 1:56 PM, Rik Cabanier <cabanier@adobe.com> wrote:

> Hello, please find below the minutes from the SVG WG telcon.****
>
> ** **
>
> http://www.w3.org/2012/01/26-svg-minutes.html****
>
> ** **
>
>    [1]W3C****
>
> ** **
>
>       [1] http://www.w3.org/****
>
> ** **
>
>                                - DRAFT -****
>
> ** **
>
>                    SVG Working Group Teleconference****
>
> ** **
>
> 26 Jan 2012****
>
> ** **
>
>    [2]Agenda****
>
> ** **
>
>       [2]
> http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html****
>
> ** **
>
>    See also: [3]IRC log****
>
> ** **
>
>       [3] http://www.w3.org/2012/01/26-svg-irc****
>
> ** **
>
> Attendees****
>
> ** **
>
>    Present****
>
>           +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Tav,****
>
>           ChrisL, [Microsoft]****
>
> ** **
>
>    Regrets****
>
>    Chair****
>
>           ed****
>
> ** **
>
>    Scribe****
>
>           cabanier****
>
> ** **
>
> Contents****
>
> ** **
>
>      * [4]Topics****
>
>          1. [5]CSS Transforms and the behavior of SVG DOM****
>
>          2. [6]OpenType and SVG****
>
>          3. [7]SVG2 Requirements****
>
>          4. [8]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements***
> *
>
>             _Input#text-align****
>
>          5. [9]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements***
> *
>
>             _Input#xml:id****
>
>          6. [10]role, rel, rev, about, content, datatype, property,****
>
>             resource, typeof****
>
>          7. [11]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirement***
> *
>
>             s_Input#display-align****
>
>          8. [12]buffered rendering****
>
>      * [13]Summary of Action Items****
>
>      _________________________________________________________****
>
> ** **
>
>    <trackbot> Date: 26 January 2012****
>
> ** **
>
>    <krit> Zakim: and me?****
>
> ** **
>
>    <krit> Zakim: who's here****
>
> ** **
>
>    <scribe> scribenick: cabanier****
>
> ** **
>
> CSS Transforms and the behavior of SVG DOM****
>
> ** **
>
>    <ed>****
>
>    [14]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issue***
> *
>
>    s****
>
> ** **
>
>      [14]
> http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues****
>
> ** **
>
>    krit: I'm working on the merged css transform specification****
>
> ** **
>
>    <krit> [15]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms****
>
> ** **
>
>      [15] http://www.w3.org/Graphics/fx/wiki/Merged_Transforms****
>
> ** **
>
>    krit: I found some possible SVG DOM issues****
>
>    ... issue 11****
>
> ** **
>
>    Issue 11: Interaction of SVG DOMs SVGTransformList and SVGTransform****
>
>    to the CSS property****
>
> ** **
>
>    On transforming the SVG attribute transform' to a presentation****
>
>    attribute, the interaction of SVG DOM with CSSOM must be clarified.****
>
>    While an SVG attribute has a one-dimensional hierarchy where the****
>
>    value can just be influenced by the unique SVGTransformList, CSS had***
> *
>
>    different cascading. Like described for CSSOm above, it is difficult***
> *
>
>    to map cascading to the one-dimensional hierarchy, since different****
>
> ** **
>
>    style sheets can affect the style of an element and there for can****
>
>    have different affects to computed style. Computed itself style****
>
>    doesn't allow modifications.****
>
> ** **
>
>    krit: how can SVG DOM work with CSS?****
>
>    ... my proposal is to add a new stylesheet****
>
> ** **
>
>    <krit> Follow other presenattion attributes with transform****
>
> ** **
>
>    <krit> Creating new Author style sheet****
>
> ** **
>
>    <krit> the hierarchy of the author style sheet is after UA style****
>
>    sheets and before other author style sheets****
>
> ** **
>
>    <krit> SVG DOM should reflect the new created style sheet****
>
> ** **
>
>    heycam: this is just make the SVG DOM expose the stylesheet****
>
> ** **
>
>    <heycam> the style sheet for the presentation attributes (the low****
>
>    specificity one) that is****
>
> ** **
>
>    heycam: on first reading this sounds reasonable****
>
>    ... people might be confused that CSS rules are not reflected in SVG***
> *
>
>    DOM****
>
>    ... we had a discussion that make the base value the initial value****
>
> ** **
>
>    <ed> it was "inline style" not "initial value", no?****
>
> ** **
>
>    <ChrisL> yes****
>
> ** **
>
>    heycam: reading out the value would get you the animated transform****
>
> ** **
>
>    chrisl: animval is the computed val?****
>
> ** **
>
>    <ChrisL> so the base value reflects the presentation attribute and****
>
>    the animval reflects the computed value****
>
> ** **
>
>    heycam: basevalue and animval can reflect different thing****
>
> ** **
>
>    krit: animval is the computed value****
>
> ** **
>
>    ed: that makes most sense but I'm concerned about whether that means***
> *
>
>    a flattened matrix, or if it's a list of matrices****
>
> ** **
>
>    krit: that is not defined at the moment****
>
>    ... it makes most sense to have a list of animated values as well****
>
> ** **
>
>    <ChrisL> agree a tranfrom list is more useful****
>
> ** **
>
>    heycam: it is more useful to inspect to have a list of transform****
>
>    item rather than a flat matrix****
>
> ** **
>
>    chrisl: you can always create a matrix, but no the other way round****
>
> ** **
>
>    cyril: why is this so different?****
>
>    ... is it because of the cascade?****
>
> ** **
>
>    kris: yes, the transform property has the cascade****
>
> ** **
>
>    heycam: transform is now becoming a presentation attribute and we****
>
>    have to figure out what that means for the SVG DOM****
>
>    ... there is no access to the CSS dom from SVG. There is no .fill****
>
>    attribute****
>
> ** **
>
>    krit: there is no animval/baseval to fill****
>
> ** **
>
>    heycam: I agree with Dirk's proposal. It matches what I was thinking***
> *
>
>    of.****
>
> ** **
>
>    <heycam> I prefer Dirk's suggestion because if you don't use****
>
>    transform in style="" or in CSS style sheets, then the SVG DOM for****
>
>    transform works the same as it always has.****
>
> ** **
>
>    heycam: it also works with the animval****
>
>    ... by having animval reflect the computed style, it will looks the****
>
>    same as before****
>
> ** **
>
>    cyril: does patrick's proposal to turn some attributes into****
>
>    properties has the same problem ? If so, is the current solution****
>
>    also applicable?****
>
> ** **
>
>    heycam: yes, we would want a consistent solution****
>
> ** **
>
>    ed: what does 'works with animval' mean?****
>
> ** **
>
>    <ChrisL> yes we do****
>
> ** **
>
>    <ed> issue 12****
>
> ** **
>
>    krit: can we do 3d transform on SVGTransformList?****
>
>    ... we would need new interfaces for perspective, etc****
>
> ** **
>
>    <ChrisL> yes, we would****
>
> ** **
>
>    krit: do we want to extend SVG interfaces to access 3d transforms?****
>
>    ... we would have to specify everything that is in CSS, in SVG as****
>
>    well****
>
> ** **
>
>    heycam: I don't think it's that much work, since it pretty simple****
>
>    ... otherwise we would have to specify what happens when you read****
>
>    out the transformlist****
>
> ** **
>
>    krit: I would specify that it's unresolvable. SVG DOM would just****
>
>    return undefined****
>
>    ... you would access everything with CSS and this would make things****
>
>    backward compatible****
>
> ** **
>
>    heycam: I guess we'll have similar issue with other issues****
>
>    ... ie by using 'calc' in css****
>
> ** **
>
>    krit: yes, it is a general issue****
>
>    ... I would not develop SVG DOM for these use cases****
>
> ** **
>
>    heycam: yes, maybe we'll use the CSSOM to manipulate****
>
>    ... if we improve the SVG DOM, should we target transform or should****
>
>    we do that in CSS?****
>
> ** **
>
>    krit: just do it in CSS****
>
> ** **
>
>    heycam: ie accessing width/height of a rectangle****
>
> ** **
>
>    krit: if you have SVG length, you can drop the 'px' but not in CSS****
>
>    ... I think the group should work on allowing that in CSS****
>
> ** **
>
>    heycam: in CSS you can using units, while in SVG you can't****
>
>    ... ie you can use '%' in CSS while in SVG you can't****
>
> ** **
>
>    krit: maybe we should resolve % to pixel in SVG****
>
> ** **
>
>    heycam: that would be possible****
>
>    ... I'm OK with returning unknown type****
>
> ** **
>
>    ed: in practice, people will use the CSSOM****
>
>    ... since if you use the CSS feature, you will want to use that****
>
>    interface anyway****
>
>    ... we should try to make the CSSOM as good as possible****
>
> ** **
>
>    krit: yes****
>
>    ... I would like to have the same features in CSSOM that we have in****
>
>    SVG now****
>
>    ... make the CCSS interface such as transformlist live****
>
> ** **
>
>    heycam: does the combined transforms spec define any CSSOM****
>
>    interfaces?****
>
> ** **
>
>    krit: we have not specified transformlist but have css matrix****
>
> ** **
>
>    heycam: so if you use getcomputedstyle you will get them back?****
>
> ** **
>
>    krit: changes to cssmatrix are reflected in css transform as well.****
>
>    ... css transforms are more complicated than other css features****
>
> ** **
>
>    heycam: this is more a question for the CSS people****
>
> ** **
>
>    chrisl: it's not clear who is editing that.****
>
> ** **
>
>    heycam: glenn is supposed to be editing that****
>
> ** **
>
>    resolution: for issue 11 and 12, we will accept the recommended****
>
>    solutions (see:****
>
>    [16]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_iss***
> *
>
>    ues)****
>
> ** **
>
>      [16]
> http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_issues)****
>
> ** **
>
> OpenType and SVG****
>
> ** **
>
>    krit: the problem are not willing to implement SVG fonts****
>
> ** **
>
>    chrisl: I proposed that we implement only WOFF****
>
>    ... it's very clear that mozilla and microsoft are not going to****
>
>    implement this****
>
>    ... there is a proposal to add SVG fonts to OpenType****
>
>    ... my feeling is that is longer term than SVG2****
>
> ** **
>
>    heycam: we have an intern working on this.****
>
>    ... SVG glyphs inside OpenType****
>
> ** **
>
>    chrisl: there is no consensus how this format will look like****
>
> ** **
>
>    <krit> [17]https://wiki.mozilla.org/SVGOpenTypeFonts****
>
> ** **
>
>      [17] https://wiki.mozilla.org/SVGOpenTypeFonts****
>
> ** **
>
>    heycam: let me give you a link to the bug****
>
> ** **
>
>    <heycam> [18]https://bugzilla.mozilla.org/show_bug.cgi?id=719286****
>
> ** **
>
>      [18] https://bugzilla.mozilla.org/show_bug.cgi?id=719286****
>
> ** **
>
>    heycam: I have never seen that page before****
>
> ** **
>
>    chrisl: me neither****
>
> ** **
>
>    heycam: this looks more like brainstorming****
>
> ** **
>
>    chrisl: this page should be updated with pointers to mailing lists,****
>
>    etc****
>
> ** **
>
>    heycam: the idea for the intern is to see how this works and report****
>
>    back****
>
> ** **
>
>    chrisl: I'm worried that the message will be that we already figured***
> *
>
>    it out****
>
>    ... experimentation is great though. I'm very pleased****
>
>    ... sairus from Adobe is working on this****
>
> ** **
>
>    cabanier: I believe Sairus has a proposal. I can ping him.****
>
> ** **
>
>    <heycam> [19]http://www.w3.org/community/svgopentype/****
>
> ** **
>
>      [19] http://www.w3.org/community/svgopentype/****
>
> ** **
>
>    dirk: we need to find a way to have a public discussion ie by a****
>
>    mailing list****
>
> ** **
>
>    chrisl: I started the community group because people were emailing****
>
>    many groups****
>
> ** **
>
>    <heycam> [20]http://lists.w3.org/Archives/Public/public-svgopentype/***
> *
>
> ** **
>
>      [20] http://lists.w3.org/Archives/Public/public-svgopentype/****
>
> ** **
>
>    chrisl: have a central location that is archived is important****
>
>    ... woff encapsulates OpenType****
>
>    ... CSS3 also mandates OT****
>
>    ... we are also going that way****
>
> ** **
>
>    <ChrisL> so if opentype adds this, svg will use it. discussion****
>
>    should be on the community group****
>
> ** **
>
>    resolution: any discussion should happen on the SVG OpenType group****
>
>    ([21]http://www.w3.org/community/svgopentype/)****
>
> ** **
>
>      [21] http://www.w3.org/community/svgopentype/)****
>
> ** **
>
> SVG2 Requirements****
>
> ** **
>
>    <ed>****
>
>    [22]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input****
>
> ** **
>
>      [22] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input**
> **
>
> ** **
>
>    cyril: I will edit the wiki page****
>
> ** **
>
>    <cyril>****
>
>    [23]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#t***
> *
>
>    he_.3CsolidColor.3E_element****
>
> ** **
>
>      [23]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3CsolidColor.3E_element
> ****
>
> ** **
>
>    [24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#s***
> *
>
>    olid-color****
>
> ** **
>
>      [24]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#solid-color
> ****
>
> ** **
>
>    chrisl: it's a single element gradient****
>
>    ... it's for paint servers, that are pointed to by a url****
>
> ** **
>
>    krit: can't this be done with CSS right now?****
>
> ** **
>
>    <ed> <solidColor id="solidMaroon" solid-color="maroon"****
>
>    solid-opacity="0.7"/> <rect fill="url(#solidMaroon)" .../>****
>
> ** **
>
>    chrisl: not sure. by having the same class and style rule****
>
> ** **
>
>    chris: css animation would select a class, right?****
>
> ** **
>
>    krit: yes****
>
>    ... if you use a selector that is less specific, does the animation****
>
>    not happen?****
>
>    ... regardless of using this in CSS, people today are working around***
> *
>
>    this with gradients.****
>
> ** **
>
>    tav: inkscape has a horrible patch to do this with a one stop****
>
>    gradient****
>
> ** **
>
>    chrisl: a solid color is really what you want to do. SVG 1.1 had it****
>
>    in there. It seems like a solid feature****
>
> ** **
>
>    <ChrisL> and 1.2T had it too****
>
> ** **
>
>    tav: inkscape would have a much simpler solution if it was in there****
>
> ** **
>
>    <ChrisL> and inkscape needs it****
>
> ** **
>
>    cyril: could inkscape define a color palette with CSS classes?****
>
> ** **
>
>    <ed> so essentially it transforms <linearGradient><stop****
>
>    stop-color="foobar"/></linearGradient> into <solidColor solid-color****
>
>    and solid-opacity property="foobar"/>...****
>
> ** **
>
>    tav: inkscape doesn't do classes****
>
> ** **
>
>    <heycam> I think it you couldn't just do this with CSS, since you****
>
>    either need to have various different style rules for different****
>
>    properties, so you lose the ability to change the colour in a single***
> *
>
>    place.****
>
> ** **
>
>    heycam: CSS variables seems to be solving the same use case****
>
> ** **
>
>    chrisl: having named colors****
>
> ** **
>
>    is one of the primary reason for them. This is a very useful****
>
>    feature.****
>
> ** **
>
>    <ChrisL> it regularises the syntax so that you can use a paint****
>
>    server for solid as well as radient and pattern fills.****
>
> ** **
>
>    heycam: CSS variables is still far away but it would be good to****
>
>    avoid the same feature twice****
>
> ** **
>
>    <ChrisL> also, you can animate the url to go from a solid to a****
>
>    gradient ad back****
>
> ** **
>
>    <ChrisL> its very flexible****
>
> ** **
>
>    ed: this is very simple to implement. It doesn't add much code****
>
> ** **
>
>    resolution: we will add solidColor element to SVG2****
>
> ** **
>
> [25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text***
> *
>
> -align****
>
> ** **
>
>      [25]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text-align*
> ***
>
> ** **
>
>    <cyril>****
>
>    [26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#x***
> *
>
>    ml:id****
>
> ** **
>
>      [26]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id****
>
> ** **
>
> [27]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:***
> *
>
> id****
>
> ** **
>
>      [27]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id****
>
> ** **
>
>    chrisl: we should drop it****
>
> ** **
>
>    everyone: agreed****
>
> ** **
>
>    resolution: drop XML:id****
>
> ** **
>
> role, rel, rev, about, content, datatype, property, resource, typeof****
>
> ** **
>
>    chrisl: was added to support RDFa and microdate, but hasn't seen****
>
>    much use but it is used in HTML****
>
> ** **
>
>    heycam: doesn't exactly match with what HTML5 has since they start****
>
>    with item****
>
> ** **
>
>    krit: I think it's great but should match HTML5****
>
> ** **
>
>    heycam: HTML5 doesn't require RDFA and microdata****
>
>    ... microdata came with a set of DOM interfaces that we want to****
>
>    support****
>
> ** **
>
>    chrisl: yes****
>
> ** **
>
>    heycam: scanning the HTML5 spec, I don't see where RDFA is required.***
> *
>
>    ... maybe there is a seperate spec****
>
> ** **
>
>    chrisl: RDFlite is I believe****
>
>    ... it could be that the spec hasn't been updated****
>
> ** **
>
>    resolution: for RDFa and microdata follow what HTML does****
>
> ** **
>
> [28]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#disp***
> *
>
> lay-align****
>
> ** **
>
>      [28]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#display-align
> ****
>
> ** **
>
>    <ed> this depends on <textArea>****
>
> ** **
>
>    chrisl: this is moot since we're following CSS****
>
>    ... not textarea****
>
> ** **
>
>    <ChrisL> its tied to f the 'textArea' element. which we are not****
>
>    using****
>
> ** **
>
>    resolution: we won't display-align since we won't have textarea****
>
> ** **
>
> buffered rendering****
>
> ** **
>
>    [29]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#b***
> *
>
>    uffered-rendering****
>
> ** **
>
>      [29]
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering
> ****
>
> ** **
>
>    ed: it's a hint to cache as much as possible****
>
>    ... it's not a requirement****
>
> ** **
>
>    cabanier: this is very useful****
>
> ** **
>
>    krit: I'm fine with it****
>
> ** **
>
>    heycam: I'm concerned about these hints****
>
>    ... like filter-region****
>
> ** **
>
>    ed: I agree****
>
> ** **
>
>    <ed> s/agree/share your concern about misuse of this property, but****
>
>    it's sometimes needed for specific devices/scenarios/****
>
> ** **
>
>    resolution: after implementor feedback, we agree that buffer****
>
>    rendering hints are needed****
>
> ** **
>
>    heycam: with CSS transform, you can get pixelated buffers****
>
>    ... would we have a requirement that they should rerender****
>
> ** **
>
>    ed: in most cases you don't want pixels****
>
> ** **
>
> Summary of Action Items****
>
> ** **
>
>    [End of minutes]****
>
>      _________________________________________________________****
>
> ** **
>
> ** **
>
>     Minutes formatted by David Booth's [30]scribe.perl version 1.136****
>
>     ([31]CVS log)****
>
>     $Date: 2012/01/26 21:38:29 $****
>
>      _________________________________________________________****
>
> ** **
>
>      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm***
> *
>
>      [31] http://dev.w3.org/cvsweb/2002/scribe/****
>
> ** **
>
> Scribe.perl diagnostic output****
>
> ** **
>
>    [Delete this section before finalizing the minutes.]****
>
> This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43****
>
> Check for newer version at [32]http://dev.w3.org/cvsweb/~checkout~/2002***
> *
>
> /scribe/****
>
> ** **
>
>      [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/****
>
> ** **
>
> Guessing input format: RRSAgent_Text_Format (score 1.00)****
>
> ** **
>
> Succeeded: s/priority/specicicity/****
>
> Succeeded: s/specicicity/specificity/****
>
> Succeeded: s/baseline/base value/****
>
> Succeeded: s/that makes most sense/that makes most sense but I'm concer***
> *
>
> ned about whether that means a flattened matrix, or if it's a list of m***
> *
>
> atrices/****
>
> Succeeded: s/patrick's proposal has the same proplem/does patrick's pro***
> *
>
> posal to turn some attributes into properties has the same problem ? If***
> *
>
> so, is the current solution also applicable?/****
>
> Succeeded: s/on SVG as well/on SVGTransformList/****
>
> Succeeded: s/stop developing/not develop/****
>
> Succeeded: s/do it will/define a color palette with/****
>
> Succeeded: s/wouldn't work with CSS/you couldn't just do this with CSS/***
> *
>
> Succeeded: s/solid-color/solidColor/****
>
> Succeeded: s/solid-color/solid-color and solid-opacity property/****
>
> Succeeded: s/hasn't seen much use/was added to support RDFa and microda***
> *
>
> te, but hasn't seen much use/****
>
> Succeeded: s/scannig/scanning/****
>
> WARNING: Bad s/// command: s/agree/share your concern about misuse of t***
> *
>
> his property, but it's sometimes needed for specific devices/scenarios/***
> *
>
> Succeeded: s/we should/would we have/****
>
> Succeeded: s/have have/have/****
>
> Succeeded: s/get/want/****
>
> Found ScribeNick: cabanier****
>
> Inferring Scribes: cabanier****
>
> Default Present: +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Ta***
> *
>
> v, ChrisL, [Microsoft]****
>
> Present: +1.206.734.aaaa ed cabanier heycam krit cyril Tav ChrisL [Micr***
> *
>
> osoft]****
>
> Agenda: [33]http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMa***
> *
>
> r/0038.html****
>
> Found Date: 26 Jan 2012****
>
> Guessing minutes URL: [34]http://www.w3.org/2012/01/26-svg-minutes.html***
> *
>
> People with action items:****
>
> ** **
>
>      [33]
> http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html****
>
>      [34] http://www.w3.org/2012/01/26-svg-minutes.html****
>
> ** **
>
> WARNING: Input appears to use implicit continuation lines.****
>
> You may need the "-implicitContinuations" option.****
>
> ** **
>
> ** **
>
>    End of [35]scribe.perl diagnostic output]****
>
> ** **
>
>      [35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm***
> *
>
> ** **
>