proposals to tweak SVG section wording and to clarify the normative status of referenced W3C documents

[Cameron McCormack]

Hi,

Sorry for leaving this to the last minute, but I have some suggestions 
for wording improvements in the SVG section.  I'll include them all in 
this email.



Regarding the referencing of the SVG Integration specification, after 
discussing with Vlad it seems that we are unable to do so normatively 
since that document is not a W3C Recommendation yet.  I think this is 
unfortunate, as it means that any updates to the SVG Integration 
document we make in the future are technically not required to be 
implemented in a conforming OFF engine that supports the SVG table. 
Given this, I retract my suggestion of removing the User Agent style 
sheet from the OFF spec and instead suggest that section 5.5.5 Glyph 
Rendering have an additional paragraph added to its end:

   It is strongly suggested that OFF engines that support the SVG
   table follow the requirements for processing the SVG documents
   as "font documents" as described in the latest version of the
   SVG Integration specification. [a]  The requirements in that
   specification might be updated as the SVG language evolves.

   [a] http://www.w3.org/TR/svg-integration/

The example use of color0 is missing some quotes, so it should be:

   <path fill="var(--color0)" d="..."/>

I suggest the following rewording of the Security Considerations section 
to make it clearer that we are not relying on a normative reference of 
SVG Integration:

   Processing of SVG glyph documents MUST be done with script execution,
   external references and interactivity disabled.  If the font engine
   is rendering SVG glyphs with animation, then declarative animations
   MUST be enabled; if it is rendering glyphs statically, then
   declarative animations MUST disabled.

   These requirements correspond to the "secure animated" and "secure
   static" processing modes that the SVG Integration document requires
   font documents to be run in.  It is again strongly suggested that
   the requirements in the latest version of the SVG Integration
   specification for "font documents" be followed. [a]

And the final paragraph in that section could do with some tweaking too:

   The use of SVG <text> and <foreignObject> elements within the SVG
   glyph descriptions is prohibited.  Any SVG <text> and <foreignObject>
   elements within a glyph description are ignored and not rendered, due
   to the corresponding rules in the User Agent style sheet.

(I removed the "MUST" since there is already a "MUST" to apply the UA 
style sheet.  Though perhaps that is a lowercase "must" that should 
become a "MUST".)



I suggest replacing the second paragraph of section 5.5.2 Color Palettes 
with the following text:

   Color variables are made available for use in the SVG glyph
   descriptions by the font engine setting CSS custom properties[b]
   in a User Agent style sheet.  The custom properties names are of
   the form "--color<num>", where <num> is a parameter index in the
   range [0, numPaletteEntries-1], inclusive, expressed as a non-zero-
   padded decimal number.  numPaletteEntries is defined in the CPAL
   table.  See the “Glyph rendering” section below for exactly how the
   values are to be passed in to the SVG document.

   Font engines that support the SVG table and color palettes are
   strongly suggested to implement the CSS Custom Properties for
   Cascading Variables specification[1], as this is required for the
   palette entries to be passed into the SVG document.

and then adding this to the Bibliography:

   [b] http://www.w3.org/TR/css-variables/

I think that's a more precise explanation of what's going on, and again 
includes some wording to work around our lack of ability to normatively 
reference the CSS Variables spec.



Finally, I think we need some text to say what version of SVG is to be 
used and to work around the fact that the keywords used in the User 
Agent style sheet are only defined in the in-development SVG 2.  I 
suggest the following text be added to the end of section 5.5.5 Glyph 
Rendering:

   SVG documents MUST be interpreted according to at least version 1.1
   of the SVG specification[c].  Font engines are not prohibited from
   interpreting SVG documents according to later versions of SVG, such
   as the in-development SVG 2, and indeed are encouraged to.

   The following new values for any CSS property that takes an SVG paint
   value MUST be supported:

     context-fill
     context-stroke
       These values mean the same paint as the computed value of the
       'fill' or 'stroke' property, respectively, of the context
       element, which is the element in the outer document that
       is using the SVG glyphs.  If the referenced paint is a
       gradient or a pattern, then the coordinate space to use and the
       object used for any 'objectBoundingBox'-relative values are the
       same as those of the context element.

   The following new values for the 'fill-opacity', 'stroke-opacity' and
   'opacity' CSS properties MUST be supported:

     context-fill-opacity
     context-stroke-opacity
       These values mean the same as the computed value of the
       'fill-opacity' or 'stroke-opacity' property, respectively,
       of the context element.

   The following new value for the 'stroke-width', 'stroke-dasharray'
   and 'stroke-dashoffset' CSS properties MUST be supported:

     context-value
       This value means the same as the computed value of the
       corresponding property of the context element, but scaled so
       that it has the same size when used in the coordinate system
       of the root <svg> element of the SVG glyph document.  For
       example, if the context element has 'stroke-width' set to
       2px and the SVG glyph document is rendered with a coordinate
       system such that 2048 user units corresponds to 16px in the
       context element's coordinate space, then using context-value
       for 'stroke-width' in the glyph definition will have the
       same visual effect as using 256 user units.

   Font engines that support SVG glyphs are strongly suggested to
   implement the context-fill, context-fill-opacity, context-stroke,
   context-stroke-opacity and context-value property values according
   to the definitions found in SVG 2[d], as these definitions may be
   more precise than those described in this document above.

   [c] http://www.w3.org/TR/2011/REC-SVG11-20110816/
   [d] http://www.w3.org/TR/svg2/



I hope these suggestions provide the best way forward for complying with 
the requirements to not normatively reference draft documents while 
encouraging implementers to follow the latest available versions of the 
relevant SVG and CSS specifications.

Thanks,

Cameron