Re: SVG Fonts inside of OpenType fonts? [Cross-post from www-font@w3.org]

I don't  think the 'smap' table is a hard requirement. It was just a first
pass suggestion. It would be fine to have just a single cmap and for those
applications that understand the newer SVG extension to hook in at the
'sloc' table. This then pushes the diverging point for looking up the glyphs
from the two different formats to the loca table or multiple loca-like
tables. There are two alternatives about the glyph ids when intermixing new
format SVG glyphs and TT format glyphs. Would we require unique glyph ids or
would we let the SVG glyph ids overlap with the TT outline glyph ids? Both
choices have advantages.

1) Allow overlap of SVG and TT glyph ids
This option would enable font creators to have both an SVG glyph and a TT
outline glyph with the same id. So, software that doesn't understand the SVG
extension would be able to use the font and only see the TT glyphs. Software
that understands the SVG extension would look at the SVG glyphs first (or
based on user settings) and use those glyphs if they exist and if not fall
back through to the TT glyphs. The interaction between the glyphs could be
controlled as is now with all of the existing OT features but there would be
no way to allow features to select between TT and SVG glyphs.

2) Maintain a unique glyph id space
In this option the glyph ids would be required to be unique across both the
TT and SVG glyphs. This would allow layout features to select between TT
glyphs and SVG glyphs. This would enable a number of interesting uses
including optical sizing choices between the different outline formats. This
could be done by having the two parallel loca tables (loca and sloc) and
requiring aware software to look in the sloc first. However, you would waste
the space of a whole table, put requirements to maintain uniqueness on the
font tools (and dealing with cases where the uniqueness wasn't maintained)
and still hard coding glyph table lookup ordering.

In this second option it might be useful to consider an expanded loca
(xloc?) table that would include not only the offset location of the glyph
but which table to look into for it. A font could still contain a
traditional loca table in addition to the newer xloc table. So, perhaps this
option would give all the benefits of the first - allowing fallback to to TT
outlines always for older software - while still allowing newer software
more advanced options for layout. The only cost would be the addition of
another new table format (xloc) in addition to a new table to hold new
format glyphs (SVG).

Stuart

On Thu, Jun 30, 2011 at 11:52 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> I don't think we should have a separate "smap" table. That would add
> complexity to character lookup paths. A large sparse sloc table would
> probably be OK; if not, use a different representation that more efficiently
> represents gaps.
>
>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>