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

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:45:33 UTC