RE: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group

Thanks for all the responses! I'll reply as briefly as I can, using
Leonard's first response as a starting point:

Leonard wrote:
>In term of indexing - so indexing will be by simple numeric index (aka
>glyph ID/GID)?

>From the OT engine's point of view, yes. If the SVG renderer really
cannot accept an identifier that's a number (thanks for the pointer,
Cameron, I'd tried to find the spec for 'id' and hadn't appreciated it
couldn't be a number) then a mechanism that maps the id to a name can be
used. Options:

a. The OT 'post' table already maps glyph IDs to glyph names (names
   aren't required to be unique but we can require that for OT SVG
   fonts), so that could be used for id values if we must come up with
   font vendor-specified glyph names.

b. Alternatively, a simple "g<glyphID>" e.g. "g0", "g1" scheme can be
   specified to create the id value. This will be one less lookup that
   needs to be done (i.e. the 'post' table lookup) which helps execution
   speed. The font vendor is authoring the SVG OT font as an entirety
   and requiring a certain pattern for the id name shouldn't be
   burdensome, IMO.

c. Chris threw out the possibility of introducing a new "glyphID" or
   equivalent element in SVG. It would be nice to minimize any changes
   needed to the SVG spec for this project, IMO.

Other than requiring one less lookup, another reason not to allow font
vendor-specified id names is that CFF and TT glyph names have been and
still are used to encapsulate the semantics of the glyph by broken
workflows that lose the original text semantics. This has caused no end
of complains and problems and updates to elaborate glyph naming schemes
such as the Adobe Glyph List, none of which ever work since the cmap is
a many-to-one mapping and going from gid->code is thus ambiguous. It
would be good to get out of the glyph naming business for this project;
if we allow vendors to have descriptive id names, such semantics schemes
will start happening again. (If the SVG document has internal names,
that would be fine with me. I'd just rather the OT engine wasn't exposed
to these names.)

>Any/all mapping from GID->CID/Unicode will happen using standard OT cmaps, yes?

All Unicode->GID mappings will happen in the OT cmaps, yes. For SVG OT
fonts, no CIDs will be involved. A GID->Unicode mapping usually
indicates a broken workflow wherein the original text backing store was
lost (see previous comment).

> So the SVG can't be processed standalone (aka
> outside the OT wrapper)?   (not saying this is a bad thing, just trying to
> understand).

Outside the OT wrapper, the SVG document should be valid enough to be
consumable by an SVG engine, but won't be required to be usable by any
process other than an OT engine. Whether vendors want to repurpose
existing SVG fonts so that they can be inserted into an OT 'SVG ' table
is their choice, so long as the SVG document allows for the required
interface with the OT engine.

> As I certainly don't want to be drawing a glyph at (x,y) and have it
> drawing all over my page...Who is responsible for ensuring that the
> SVG "glyph" doesn't draw outside of the bounding box defined for it by
> the hmtx? Would you expect the OT engine to setup clipping? Is the SVG
> code required to "draw inside the lines"?

(The main point of my little interface sketch-up was that the SVG engine
will only be queried by element id and not by character code, BTW, but
I'm glad we're starting to discuss all the rest of the aspects of the
interface!)

In my mind there are two aspects to this, glyph bounds and compositing
with the rest of the page:

- Glyph bounds:

  The OT *font* bbox ('head' table xMin, etc) will indicate a rect which
  no glyph, including its animation, must extend beyond. An OT engine or
  application can examine this bbox and if it's too big can introduce
  clipping or reject the font (as is the case today with CFF or TT).
  While this may restrict font vendor creativity, it's what comes with
  the OT model.

  Just last week we received a bug report wherein a "bar code" font was
  being clipped in Acrobat because it had glyphs 13 ems tall. OT font
  rasterizers usually balk at anything more than a few ems.

  Now, each TT *glyph* has its own explicit bbox (in the 'glyf' table),
  but CFF has no such concept. Thus, the CFF rasterizer has a
  get-glyph-bbox interface which walks the charstring to determine the
  glyph bbox on the fly. This can be inefficient, so for a while a few
  years ago we were considering a new 'BBOX' table that would record
  explicit glyph bboxes, but it wasn't considered worth it at the time.

  If needed, this table could be invented for SVG OT fonts (and
  optionall usable for CFF OT fonts as well) so that the OT engine can
  examine glyphs on a per-glyph basis to see if its bounds were
  acceptable. Another option is to have the SVG renderer return the bbox
  of an id (a get-element-bounds interface), but since that may mean
  rendering it off-screen it may be inefficient as well. Or we could
  require that an id element store an explicit bbox value (does SVG have
  that already?).

- Compositing with the rest of the page:

  My interface sketch-up did indicate to rasterize a glyph at a
  particular (x,y) location but was silent on whether it should be
  composited. My feeling is that compositing should happen if we can get
  away with a simple enough model. What is done for SVG images placed on
  an HTML page today in browsers? Does compositing happen?

  In the CFF and TT model, the rasterizer returns an alpha map that is
  then composited into the rest of the page.

> So what is the purpose of the boolean for animation? Do you propose a
> separate "static" <g> and an animated <g>?

I agree with Cameron and Vlad that the boolean should belong at document
"start" time.

At the SVG WG face2face a few weeks ago we discussed having both static
and animated version wrapped up in the same element, allowing for
sharing. Someone said something about SVG already allowing for an
arbitrary timeline snapshot for the static version, but I don't
rememeber the details.

> Are you expecting support for a scripting system in glyph processing?
> (I am hoping not since there should be no script execution in glyph
> rendering)

No.

Sairus

Received on Wednesday, 23 November 2011 20:06:19 UTC