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

> Where is the actual glyph description that would go into the PDF in a standard OTF/TFF?

Any number of options spring to mind (each of which will have pros and cons). Here’s some inspiration for further fleshing out:
- choose the fallback CSS font-family in the list or the UA’s default font
- make it so that PDF’s substitution font facility kicks in
- embed as Type 3 (preserves color and scalability of the OSVG)
- rasterize the SVG glyphs in color and embed the bitmaps as Type 3
- rasterize the SVG glyphs in monochrome and embed the bitmaps in PDF
- of course, an OSVG will not be prohibited from having a CFF or glyf table in addition to the SVG; if these are present use them
- embed as SVG OT (if/when PDF decides to support it). I list this here for completeness!

All of the above, of course, would be subject to the fonts’ licensing considerations.

> It’s one of the reasons that OSVG was killed in the first place and should NEVER be allowed in the real world.

Your point that a webpage using webfonts isn’t a completely closed system is a good one.

However, I don’t see webpage->PDF conversions working well for the limited set of pages and situations I try it on; these webpages use existing standards. The webpages shouldn’t be prohibited from using those facilities (nor the standards from standardizing those facilities) just because a particular workflow doesn’t (yet) support them: that should be a decision made by the owner of the website, similar to “should I use xxx on my webpages because it’s not supported in older versions of yyy browser?” and it should be supported by a clear versioning/fallback scheme.

In any case, completely (or adequately) closed systems are an excellent reason for OSVG, but it’s not a proposal that’s on the table for right now.

Best,
Sairus

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

But a mapping is useless without an actual glyph?!?!   Where is the actual glyph description that would go into the PDF in a standard OTF/TFF?

Leonard

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

> 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@adobe.com<mailto:lrosenth@adobe.com>>
Date: Saturday, November 22, 2014 at 12:00 PM
To: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, "list.adam@twardoch.com<mailto:list.adam@twardoch.com>" <list.adam@twardoch.com<mailto:list.adam@twardoch.com>>, "mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>" <mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>>
Cc: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@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@adobe.com<mailto:sppatel@adobe.com>>
Date: Saturday, November 22, 2014 at 12:01 AM
To: "list.adam@twardoch.com<mailto:list.adam@twardoch.com>" <list.adam@twardoch.com<mailto:list.adam@twardoch.com>>, "mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>" <mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>>
Cc: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: [mpeg-OTspec] OFF with glyphs only in 'SVG ' table?
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@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@twardoch.com<mailto:list.adam@twardoch.com> [mpeg-OTspec] (List)" <mpeg-OTspec-noreply@yahoogroups.com<mailto:mpeg-OTspec-noreply@yahoogroups.com>>
Reply-To: "list.adam@twardoch.com<mailto:list.adam@twardoch.com>" <list.adam@twardoch.com<mailto:list.adam@twardoch.com>>
Date: Friday, November 21, 2014 at 12:20 AM
To: "mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>" <mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>>
Cc: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@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


__._,_.___
________________________________
Posted by: "Adam Twardoch (List)" <list.adam@twardoch.com<mailto:list.adam@twardoch.com>>
________________________________
Reply via web post<https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1258;_ylc=X3oDMTJxNzlhaDEwBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRtc2dJZAMxMjU4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQxNjU1ODA2MQ--?act=reply&messageNum=1258>     •       Reply to sender <mailto:list.adam@twardoch.com?subject=Re%3A%20OFF%20with%20glyphs%20only%20in%20%27SVG%20%27%20table%3F>       •       Reply to group <mailto:mpeg-OTspec@yahoogroups.com?subject=Re%3A%20OFF%20with%20glyphs%20only%20in%20%27SVG%20%27%20table%3F>   •       Start a New Topic<https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/newtopic;_ylc=X3oDMTJmdmd2YmQ1BF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0MTY1NTgwNjE->     •       Messages in this topic<https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/topics/1241;_ylc=X3oDMTM1dWRwdnYxBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRtc2dJZAMxMjU4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQxNjU1ODA2MQR0cGNJZAMxMjQx> (6)
Visit Your Group<https://groups.yahoo.com/neo/groups/mpeg-OTspec/info;_ylc=X3oDMTJmb3BtcDNsBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0MTY1NTgwNjE->

[Yahoo! Groups]<https://groups.yahoo.com/neo;_ylc=X3oDMTJlaDAybjc0BF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQxNjU1ODA2MQ-->
• Privacy<https://info.yahoo.com/privacy/us/yahoo/groups/details.html> • Unsubscribe<mailto:mpeg-OTspec-unsubscribe@yahoogroups.com?subject=Unsubscribe> • Terms of Use<https://info.yahoo.com/legal/us/yahoo/utos/terms/>

.


__,_._,___

Received on Wednesday, 26 November 2014 23:37:58 UTC