[mpeg-OTspec] comments re SVG table in the OFF draft

Tue Mar 11 21:36:21 CET 2014

Ok, thanks. Changing the hierarchy of the subclause and updating the title makes sense. I think that since we don't have much to add to rendering restrictions - I would rather adopt the first subclause hierarchy you proposed.

Thank you,
Vlad

From: Sairus Patel [mailto:sppatel at adobe.com]
Sent: Tuesday, March 11, 2014 4:12 PM
To: Levantovsky, Vladimir; Jonathan Kew; OTspec <mpeg-OTspec at yahoogroups.com>
Subject: Re: [mpeg-OTspec] comments re SVG table in the OFF draft

Hi Vlad,

Yes, I was wondering about that as well. I didn't think that mixing mention of external references and foreignObject in the same subsection would look too odd. However, the title of the subsection should reflect that.

The subsection title could read: "Security considerations and other glyph rendering restrictions" instead of just "Security". And it should be a sub-section of the "Glyph rendering" section, and not a parallel section as in the draft. This is because security is achieved by restricting how the glyph is rendered. Also, the contents of the UA style sheet are related to the restrictions for security (and for text elements/foreignObject).

I'm also fine if you prefer having a second sub-section after "Security considerations" that reads "Other rendering restrictions" with content: "Rendering of the glyphs must ignore any SVG text elements and foreignObjects encountered."

So the section/subsection hierarchy should be:

Glyph rendering
- Security considerations and other glyph rendering restrictions

Or

Glyph rendering
- Security considerations
- Other rendering restrictions

Thanks,
Sairus

From: <Levantovsky>, Vladimir Levantovsky <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>
Date: Tuesday, March 11, 2014 at 12:46 PM
To: Sairus Patel <sppatel at adobe.com<mailto:sppatel at adobe.com>>, Jonathan Kew <jfkthame at gmail.com<mailto:jfkthame at gmail.com>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Subject: RE: [mpeg-OTspec] comments re SVG table in the OFF draft

Hi Sairus,

I am a bit hesitant to mix the security consideration and rendering restrictions in the same paragraph. While the end result we want to achieve may seem to be the same - i.e., we don't want to see something happen - the reasons for not allowing something to happen are quite different and don't mix well. I'd rather keep rendering limitations away from security considerations and vice versa. (This is my personal opinion only, I am very much open to other suggestions from the group.)

Thank you,
Vlad

From: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: Tuesday, March 11, 2014 3:39 PM
To: Jonathan Kew; Levantovsky, Vladimir; OTspec <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Subject: Re: [mpeg-OTspec] comments re SVG table in the OFF draft

Thanks, Vlad and Jonathan, for moving these changes forward (these changes were brought up after the final report of the W3C was published).

The "Glyph rendering" section's "Security" sub-section already describes the current restrictions on the glyphs:

>>>
It is required that all rendering of SVG glyphs be done in the "secure animated mode" or "secure static mode" specified in the W3C document SVG Integration<https://svgwg.org/specs/integration/>. These modes permit no script execution, external references, interactivity, or link traversal.
<<<

So that seems the right place to indicate these additional restrictions.

I propose that the following be added to the end of that sub-section:

>>>
In addition, rendering of the glyphs must ignore any SVG text elements and foreignObjects encountered.
<<<

That should suffice for indicating that text elements and foreignObjects are not allowed, and also addresses Jonathan's point about what the impl should do if it encounters them.

Thanks,
Sairus

From: Jonathan Kew <jfkthame at gmail.com<mailto:jfkthame at gmail.com>>
Date: Tuesday, March 11, 2014 at 9:05 AM
To: Vladimir Levantovsky <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Subject: Re: [mpeg-OTspec] comments re SVG table in the OFF draft

On 11/3/14 15:53, Levantovsky, Vladimir wrote:
> Thank you Jonathan,
>
> What you're proposing makes perfect sense but I also wonder if, in
> light of the changes proposed by Cameron for UA style sheet we should
> also extend the language of your proposed second sentence to say that
> "The use of SVG text elements _and/or SVG foreign objects_ within
> these glyph descriptions is prohibited."

Sounds good to me. We should certainly mention the foreignObject
prohibition somewhere, and this seems a logical place to include it.

JK

>
> Best regards, Vladimir
>
>
>> -----Original Message----- From: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>
>> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Jonathan Kew
>> Sent: Tuesday, March 11, 2014 11:37 AM To: OTspec
>> <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>> Subject: [mpeg-OTspec] comments re
>> SVG table in the OFF draft
>>
>> A few comments on the current 3rd ed. working draft:
>>
>> - - - - -
>>
>> First, the opening sentence in section "5.5.1 SVG - The SVG
>> (Scalable Vector Graphics) table" seems problematic to me:
>>
>> <quote> This table contains SVG [16] descriptions for some or all
>> of the glyphs in the font, the use of SVG text elements for outline
>> fill is prohibited. </quote>
>>
>> This would read much better if split into two sentences, not joined
>> by a comma. And second, shouldn't the use of SVG text elements be
>> prohibited for -any- purpose within the glyphs (not only for
>> outline fill)? If we want to avoid glyph descriptions referring to
>> external fonts, we can't allow SVG text elements to be stroked or
>> used as clipping paths, for example.
>>
>> So I suggest changing this to something like:
>>
>> <proposed> This table contains SVG [16] descriptions for some or
>> all of the glyphs in the font. The use of SVG text elements within
>> these glyph descriptions is prohibited. </proposed>
>>
>> - - - - -
>>
>> Further, we should specify what happens if an SVG text element is
>> found (despite being prohibited): is that element ignored, but the
>> remainder of the glyph rendered normally, or do we consider the
>> entire glyph description invalid, and ignore it, falling back to a
>> TrueType or CFF glyph?
>>
>> Offhand, I'm inclined to favor the former: require the renderer to
>> ignore the SVG text element(s), but proceed to do its best to
>> render any other content. So I'd suggest an additional sentence
>> such as:
>>
>> <proposed> If any SVG text element is encountered within a glyph
>> description, it MUST be ignored by the renderer. </proposed>
>>
>> - - - - -
>>
>> Finally, forwarding a comment from Cameron McCormack regarding the
>> description of "Glyph Rendering":
>>
>> <forwarded> I don't think that added rule in the UA style sheet,
>>
>> :root { font-size: 0 !important; }
>>
>> is sufficient, since font-size can be specified on an element in
>> the document. The importance of the rule doesn't inherit.
>>
>> Instead, I think this would work:
>>
>> @namespace svg url(http://www.w3.org/2000/svg);
>>
>> svg|text, svg|foreignObject { display: none !important; }
>>
>> Using |display: none| seems like a clearer description of what's
>> going on, and should have the same effect as |font-size: 0|.
>> </forwarded>
>>
>> This seems like a good change we should make to the draft.
>>
>>
>> JK
>>
>>
>> ------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20140311/fc969f9d/attachment.html>