[mpeg-OTspec] OFF with glyphs only in 'SVG ' table?

[Sairus Patel]

> Because it means that the browser (or some other consumer of that content) can’t convert the content into some other format (say, PDF) without losing all the important parts of the content being text – searching, indexing, etc.

Actually, all semantics (searching, indexing, etc) will be able to be perfectly preserved in a webpage->PDF conversion, since the OSVG will contain a cmap. In OFF/OT, the cmap and not the glyph descriptions contain the semantics (Unicode-to-glyph ID mapping).

Sairus

From: Leonard Rosenthol <lrosenth at adobe.com<mailto:lrosenth at adobe.com>>
Date: Saturday, November 22, 2014 at 12:00 PM
To: Sairus Patel <sppatel at adobe.com<mailto:sppatel at adobe.com>>, "list.adam at twardoch.com<mailto:list.adam at twardoch.com>" <list.adam at twardoch.com<mailto:list.adam at twardoch.com>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Cc: "public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>" <public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>>
Subject: Re: [mpeg-OTspec] OFF with glyphs only in 'SVG ' table?

>It would certainly be useful for embedded systems or other situations where the font wouldn’t be exposed to legacy (i.e. non–SVG-in-OT–savvy) engines.
>
On a completely closed system, that’s perfectly reasonable and I can see that.

However…

>Here’s a very concrete example: I use an SVG-in-OT font as a webfont for my website’s banner, but construct my page so that if the browser is not >Firefox, an equivalent graphic is shown instead of SVG-in-OT text. Why should I burden that web font with CFF or TT outlines when they will never be >used?
>
Because it means that the browser (or some other consumer of that content) can’t convert the content into some other format (say, PDF) without losing all the important parts of the content being text – searching, indexing, etc.

It’s one of the reasons that OSVG was killed in the first place and should NEVER be allowed in the real world.  It would be great if the SVG-in-OT would clearly spell out the evils of this concept and specifically make any such implementations as invalid.

Leonard

From: Sairus Patel <sppatel at adobe.com<mailto:sppatel at adobe.com>>
Date: Saturday, November 22, 2014 at 12:01 AM
To: "list.adam at twardoch.com<mailto:list.adam at twardoch.com>" <list.adam at twardoch.com<mailto:list.adam at twardoch.com>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Cc: "public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>" <public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>>
Subject: Re: [mpeg-OTspec] OFF with glyphs only in 'SVG ' table?
Resent-From: "public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>" <public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>>
Resent-Date: Saturday, November 22, 2014 at 12:02 AM

In initial discussions, ‘OSVG’ was to be the sfnt signature for SVG-in-OT fonts that did not require a CFF or glyf table also to be present:

   http://lists.w3.org/Archives/Public/public-svgopentype/2012Jun/0003.html

Of course SVG could still optionally be present for ‘OTTO’ (CFF) and 1.0/’true’ TT fonts as well. But the ‘OSVG’ thing was scrapped because it was too controversial.

It would certainly be useful for embedded systems or other situations where the font wouldn’t be exposed to legacy (i.e. non–SVG-in-OT–savvy) engines. Here’s a very concrete example: I use an SVG-in-OT font as a webfont for my website’s banner, but construct my page so that if the browser is not Firefox, an equivalent graphic is shown instead of SVG-in-OT text. Why should I burden that web font with CFF or TT outlines when they will never be used?

’OSVG’ can always be proposed (again) at some point in the future, and I have a feeling that that will happen. Note that engines shouldn’t be required to support ‘OSVG’ just as they aren’t required to support the SVG table, or COLR/CPAL, or  the ‘name’ table (a PDF renderer for example may never need to read a ‘name’ table), or the entire TT hinting system. I know of CFF-only and TT-only engines as well.

Sairus

From: "'Adam Twardoch ' list.adam at twardoch.com<mailto:list.adam at twardoch.com> [mpeg-OTspec] (List)" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Reply-To: "list.adam at twardoch.com<mailto:list.adam at twardoch.com>" <list.adam at twardoch.com<mailto:list.adam at twardoch.com>>
Date: Friday, November 21, 2014 at 12:20 AM
To: "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>
Cc: "public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>" <public-svgopentype at w3.org<mailto:public-svgopentype at w3.org>>
Subject: [mpeg-OTspec] OFF with glyphs only in 'SVG ' table?



Simple question: does the OFF spec allow an OFF font where the glyph images would only be hosted using the 'SVG ' table, without 'glyf' or 'CFF '?

AFAIK, the spec permits to only have 'EBDT'/'EBLC', without any outline data, so my guess 'SVG ' only would also be permitted. Correct?

If that is the case, what would be the first four bytes? \00\01\00\00? I.e. is my understanding correct that 'OTTO' is only to be used if the 'CFF ' table is present, while any other glyph flavors ('glyf', 'SVG ', 'EBDT'/'EBLC' and possibly others) mandate \00\01\00\00?

Best,
Adam



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141124/6f652480/attachment.html>