- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Thu, 18 Feb 2016 22:59:21 +0000
- To: Sairus Patel <sppatel@adobe.com>, "opentype-list@indx.co.uk" <opentype-list@indx.co.uk>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Sarius - agreed that glyphs should NOT be sharing things across individual files. If they need to do that, then use a single SVG doc for all glyphs. Leonard On 2/18/16, 5:45 PM, "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 > > >-----Original Message----- >From: Behdad Esfahbod <behdad@behdad.org> >Reply-To: "opentype-list@indx.co.uk" <opentype-list@indx.co.uk> >Date: Thursday, February 18, 2016 at 1:46 AM >To: "listmaster@indx.co.uk" <listmaster@indx.co.uk> >Subject: Re: [OpenType] Re: Clarification of some aspect of opentype SVG >spec > >>Message from OpenType list: >> >> >>>****** Attachments to this email message have been removed ****** >> >>On Sat, Feb 13, 2016 at 9:28 AM, Sairus Patel <sppatel@adobe.com> wrote: >> >> >>> 3. Alignment, order and re-use of svgDoc: I don’t see reusing entire SVG >>> docs are being useful (multiple SVG doc index entries pointing to the >>>same >>> svg doc), >> >> >>It is useful, indeed required, if glyphs that want to share things are not >>in a continuous range. Ie. in your example below, glyphs 2, 3, 4 share >>some stuff. If glyphs 2, 3, 15 wanted to share some stuff, pointing to >>share stuff, pointing to save SVG doc from multiple doc index entries is >>needed. >> >>behdad >> >> >> >>> since each SVG doc contains an id=“glyph<gid>” so reusing in >>> that way doesn’t make sense (we want only one glyph definition per >>> glyph!). >> >> >> >>> However, as Miguel pointed out, reusing within an SVG doc makes >>> total sense: this is SVG-in-OT’s way of “subroutinizing.” In the extreme >>> case, all glyphs will share a single SVG doc (just as, for example, a >>> single CFF contains all glyphs and any shared subroutines. >>> >>> I’m working on an actual SVG doc example and accompanying image to add >>>to >>> the spec, since this would be really helpful. It will include an example >>> of sharing; for example to have glyphs 2, 3 & 4 share the same paths, >>>say: >>> >>> <svg> >>> >>> <defs> >>> <g id="glyphToShare"> ...actual paths... >>> </g> >>> </defs> >>> >>> <g id="glyph2”> >>> <use xlink:href="#glyphToShare" /> >>> </g> >>> >>> <g id="glyph3"> >>> <use xlink:href="#glyphToShare" /> >>> </g> >>> >>> <use id="glyph4" xlink:href="#glyphToShare" /> >>> >>> </svg> >>> >>> >>> Miguel & I tested the approach above in Firefox’s impl & it works great. >>> Note that glyphs 2 & 3 above can add additional elements to their <g> if >>> needed. This example may not squeeze into this round of comments (the >>> above is not a full-fledged, correctly formed SVG doc), but I’ll have it >>> out for review in a week or two & it will get into the spec when it gets >>> into the spec. >>> >>> Re. alignment, I think it was when we added cmap subtable format 14 >>> (UVSes) to the spec -- note its UINT24 data type -- that we dispensed >>>with >>> trying to have 4-byte boundaries for data structures within new OT >>>tables.. >>> (And of course CFF never had such an alignment model.) I don’t think the >>> lack of alignment warrants any specific note in the SVG table. >>> >>> Best, >>> >>> Sairus >>> >>> -----Original Message----- >>> From: Hin-Tak Leung <htl10@users.sourceforge.net> >>> Reply-To: "opentype-list@indx.co.uk" <opentype-list@indx.co.uk> >>> Date: Friday, January 29, 2016 at 10:17 AM >>> To: "listmaster@indx.co.uk" <listmaster@indx.co.uk> >>> Subject: [OpenType] Clarification of some aspect of opentype SVG spec >>> >>> >Message from OpenType list: >>> > >>> > >>> >Hi, >>> > >>> >I think a call for addendum of the 2015 spec is up soon; in any case >>>I'd >>> >like to mention a few things about SVG in opentype that I thought >>>about, >>> >while adding SVG functions to Microsoft Font Validator in the past few >>> >weeks. >>> > >>> >- compression: The wording in the OT spec is a bit vague - SVG itself >>> >supports gzip and deflate delivery and the OT spec says only gzip is >>> >required for compliant implementation. I think bare deflate stream is a >>> >bad idea in OT - can we be a bit more explicit about avoiding it? >>> > >>> >- encoding: I added support to UTF16/UTF32 both endian and utf8. But I >>> >imagine one day somebody will want random favorite encodings of theirs >>> >for their XML, just because it isn't disallowed. Can something be said >>> >about that? Actually supporting UTF32 already seems overkill, since >>> >presumably most want to optimize for data size, so utf8 would be the >>>best >>> >choice. >>> > >>> >- alignment, order and re-use of svgDoc: all the ones I have seen so >>>far >>> >are contiguous (i.e. The next svgDoc starts exactly where the last one >>> >finishes), in order (svgDoc's are stored exactly in the order as listed >>> >in the index), and no re-use. I don't see a reason for re-use, but some >>> >drafts and earlier proposals mentions that. Also, the rest of OT specs >>> >tend to align to 4-byte for any sizeable structure so I was a bit >>> >surprised when I looked at the first font for clarifying this in actual >>> >use. A few words can be added about alignment, order and re-use. >>> > >>> >Hin-Tak >>> > >>> > >>> > >>> >List archive: http://www.indx.co.uk/biglistarchive/ >>> > >>> >subscribe: opentype-subscribe@indx.co.uk >>> >unsubscribe: opentype-unsubscribe@indx.co.uk >>> >messages: opentype-list@indx.co.uk >>> > >>> > >>> >>> >>> >>> >>> List archive: http://www.indx.co.uk/biglistarchive/ >>> >>> subscribe: opentype-subscribe@indx.co.uk >>> unsubscribe: opentype-unsubscribe@indx.co.uk >>> messages: opentype-list@indx.co.uk >>> >>> >>> >> >> >>-- >>behdad >>http://behdad.org/ >> >> >> >>>****** Attachments to this email message have been removed ****** >> >> >> >>List archive: http://www.indx.co.uk/biglistarchive/ >> >>subscribe: opentype-subscribe@indx.co.uk >>unsubscribe: opentype-unsubscribe@indx.co.uk >>messages: opentype-list@indx.co.uk >> >> >
Received on Thursday, 18 February 2016 22:59:52 UTC