Re: SVG in OpenType proposal

(Forwarded with permission from public-svg-wg.)

Thanks for the issue summary.  Some comments below.

On 2/02/13 12:21 AM, Leonard Rosenthol wrote:
> On 1/31/13 8:08 PM, "Cameron McCormack" <cam@mcc.id.au> wrote:
>> Would you be able to enumerate the problems for me, with pointers back
>> to your mails that you brought them up in (which I am sure you have
>> already done)?
>>
>
> I don't know that I can find the original emails, but I can certainly
> bring the main issue up again for discussion.
>
> Your design/specification presumes (assumes?) that the SVG-based glyphs
> will be rendered inside of a "web context".  This is extremely problematic
> not just for the potential uses of these glyphs in a variety of non-web
> contexts. Let me call out three such examples:
>
> - alternate document formats (eg. PDF, ODF or OOXML)
> - operating systems (eg. Windows, Mac OS, iOS, Android)
> - authoring environment (eg. Word, DreamWeaver, iBooks Author)
>
> In each of these cases, the parent context is not "the web". This raises
> issues in two areas - animation and inheritance.
>
> The animation issues are addressed in the Adobe proposal by providing a
> way to have each glyph identified as animated or not (without requiring
> parsing the SVG) so that a non-animated renderer or one that isn't running
> on a web context can choose the static one (either a static SVG or the
> classic glyph).  However, neither specification adequately addresses the
> "animating outside the glyph's bounding box" problem that was raised in
> email discussions earlier.  This will need to be called out/addressed, in
> some fashion, in the final specification.

I think it is reasonable to worry about what the "context text object" 
means for non-Web content and what it would mean for the context fill 
styles from that non-Web context to be used in the glyph.

For animation, I continue to disagree that a separate animated glyph 
definition is required.  Our proposal states that when glyphs are 
rendered in situations where animation is not possible, then the SVG 
animation elements just do not apply.  This is the same behaviour as if 
you took an animated SVG document and opened it in an SVG user agent 
that does not support animation (such as Internet Explorer).  It is 
simple enough to construct your content such that the static view is 
what you would see if the animation elements were not present.

I will need to read that thread about bounding boxes.

> Regarding inheritance, your proposal introduces the "context-XXXX"
> attribute values but in doing so (and in the examples provided) assumes
> that the glyphs are being rendered inside of a web-context. No
> consideration is given for a context that has completely different and/or
> incompatible attributes. This is why the Adobe proposal specifically
> leaves these for a future specification during which time the complex
> issues can be evaluated and (hopefully) resolved.

I think these are context-XXX values are important to support.

We could add some wording explaining how non-SVG colours and patterns 
from the context would be handled when rendering the glyph.  We would 
need to have a more abstract definition of the paints that can come in 
from the context -- let's say, a solid colour of a type that corresponds 
to one of the kinds of colours you can specify in SVG 2 -- or a fixed 
size pattern/bitmap, which would be handled just like an SVG pattern.

Let me know if there are specific problems that a high level description 
like that would not solve.

> A smaller issue, which may simply be something missing in your text (vs. a
> design choice) is how the glyph position/layout is accomplished.  In the
> Adobe specification, it specifically calls out that glyph sizes are the
> same for SVG-glyphs as they are for classic glyphs - thus not requiring
> any changes to the line layout algorithms (and enabling the same content
> to appear w/o reflow when switching glyph types).  We (Adobe) believe this
> is an extremely important aspect of the specification.

Yes, this might not be stated as explicitly as it should be.  There's a 
single sentence in the propsal at the moment:

   All other metrics are defined in the usual OpenType manner.

So the intention is that all of the standard ways that you would specify 
metrics for OpenType glyphs would also apply to the SVG glyphs.  So the 
OpenType outline glyph for a particular glyph ID would have the same 
advance as the SVG glyph, etc.

Received on Sunday, 3 February 2013 11:29:37 UTC