Re: [OpenType] Re: Clarification of some aspect of opentype SVG spec

Hi,

Splicing separate svgDoc seems overly complicated; but on the other hand, one gigantic svgDoc for all glyphs have a number of disadvantages - latency, robustness against minor corruptions, etc. What would be really useful for the sort of thing that Miguel tries to do, is to extend the OT SVG spec slightly to cater for one svgdoc for a number of glyphs not in contiguous id range. For example, one might like to keep to a glyph Id order, Adobe Japanese Supplement 5, say, but have all the various 'a' with diacritics in one doc, all the 'e', e', e~, etc in another; and grouping CJK ideograms by radicals (i.e. entire top/bottom/left/right half of a glyph). That kind of grouping is not possible under the current spec without reorder the glyph ids.

Hin-Tak
--------------------------------------------
On Thu, 2/18/16, Sairus Patel <sppatel@adobe.com> wrote:
 
 What Behdad is suggesting
 is the idea of a glyph being rendered using more
 than one SVG doc from the ‘SVG ’ table.
 
 I didn’t think this was
 within the intent or perhaps even capability of an
 SVG rendering system, since these are isolated
 SVG docs. That would be
 akin to an image
 being split across two PNG files, for example.
 
 Could Cam, Chris Lilley, or
 others weigh in? Perhaps there is a concept of
 concatenating or combining SVG docs that is
 natural to an SVG system.
 
 If one wants any glyph in the font to share
 something with any other glyph
 in the font,
 having all glyphs be defined in the same SVG doc would be
 the
 way to go (or some other very
 coarse-grained chunking into SVG docs), with
 the current spec. The alternative, having the
 font software manually
 splice separate SVG
 docs (perhaps by stripping starting and ending
 portions?) to pass them to the SVG renderer
 seems complicated.
 
 Sairus

Received on Friday, 19 February 2016 22:51:49 UTC