- From: Sairus Patel <sppatel@adobe.com>
- Date: Fri, 19 Feb 2016 23:03:01 +0000
- To: Hin-Tak Leung <htl10@users.sourceforge.net>, "opentype-list@indx.co.uk" <opentype-list@indx.co.uk>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Hin-Tak, You can indeed do what you suggest below. See Behdad’s response earlier today. Behdad thanks for spelling out the specific example, which utilized both kinds of “sharing”: sharing an SVG doc as well as, within that SVG doc, sharing of common portions via <use>. Both kinds of sharing need to be used to pull this off. Sairus -----Original Message----- From: Hin-Tak Leung <htl10@users.sourceforge.net> Reply-To: Hin-Tak Leung <htl10@users.sourceforge.net> Date: Friday, February 19, 2016 at 2:51 PM To: "opentype-list@indx.co.uk" <opentype-list@indx.co.uk>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>, Sairus Patel <sppatel@adobe.com> Subject: 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 23:03:34 UTC