<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 12 Sep 2020 at 01:45, Renzhi Li <<a href="mailto:Renzhi.Li@microsoft.com">Renzhi.Li@microsoft.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div style="margin:0px;font-size:12pt;font-family:Calibri,Arial,Helvetica,sans-serif;background-color:rgb(255,255,255);color:black"><ul style="font-family:Calibri,Arial,Helvetica,sans-serif"><ul style="font-family:Calibri,Arial,Helvetica,sans-serif"><li style="font-family:Calibri,Arial,Helvetica,sans-serif">Format is mostly like TT but allowing "shape fragments" for data sharing. A shape fragment could be a contour, or a<span style="font-family:Calibri,Arial,Helvetica,sans-serif"> </span><i style="font-family:Calibri,Arial,Helvetica,sans-serif">part</i> of a contour, like a serif shape.</li><li style="font-family:Calibri,Arial,Helvetica,sans-serif">No composite glyphs and components, shape sharing is completely transparent.</li></ul></ul></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Shape fragments are already sort of implemented in some font editors (e.g. FontLab 7) and also you can view CFF(2) subroutines as such shape fragments. I can easily see how they can be beneficial, especially in variable scenarios. </div><div dir="auto"><br></div><div dir="auto">There may be a piece of contour that not only looks the same in many glyphs but it also varies in the same way in all the glyphs. Associating the variations with it and the re-using the whole part may be good for size. </div><div dir="auto"><br></div><div dir="auto">On the other hand, with VFs, there may also be “false friends” — sub-contours that look the same in a particular master but vary differently, at least in some portion of the design space.</div><div dir="auto"><br></div><div dir="auto">I think it’d be beneficial to check the actual size benefits in a good sample of quality VFs for these situations, before drafting that proposal. </div><div dir="auto"><br></div><div dir="auto">CFF subroutine compression has been around for a long time, so it could be used as a metric. In real life, what's the current size benefit of subroutinized vs. non-subroutinized? </div><div dir="auto"><br></div><div dir="auto">A.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br><br></div><br><br><div id="m_-2272857026103094818appendonsend"></div><br><br><hr style="display:inline-block;width:98%"><br><br><div id="m_-2272857026103094818divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b style="font-family:Calibri,sans-serif">From:</b> mpeg-otspec <<a href="mailto:mpeg-otspec-bounces@lists.aau.at" target="_blank" style="font-family:Calibri,sans-serif">mpeg-otspec-bounces@lists.aau.at</a>> on behalf of Dave Crossland <<a href="mailto:dcrossland@google.com" target="_blank" style="font-family:Calibri,sans-serif">dcrossland@google.com</a>><br><br><br><b style="font-family:Calibri,sans-serif">Sent:</b> Friday, September 11, 2020 16:34<br><br><br><b style="font-family:Calibri,sans-serif">To:</b> Adam Twardoch (Lists) <<a href="mailto:list.adam@twardoch.com" target="_blank" style="font-family:Calibri,sans-serif">list.adam@twardoch.com</a>><br><br><br><b style="font-family:Calibri,sans-serif">Cc:</b> mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" style="font-family:Calibri,sans-serif">mpeg-otspec@lists.aau.at</a>></font></div></div><div dir="ltr"><div id="m_-2272857026103094818divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><br><br><br><b style="font-family:Calibri,sans-serif">Subject:</b> [EXTERNAL] Re: [MPEG-OTSPEC] Co-existence of glyph rendering source types</font><br><br><div> </div><br><br></div><br><br><div><br><br><div dir="auto">I'm not sure "political reasons" is a good principle. The political reasons have a technical basis, right?</div><br><br><br><br><br><div><br><br><div dir="ltr">On Fri, Sep 11, 2020, 7:23 PM Adam Twardoch (Lists) <<a href="mailto:list.adam@twardoch.com" target="_blank">list.adam@twardoch.com</a>> wrote:<br><br><br></div><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br><br><div dir="auto">Ps. In my world, OFF2 would bring down the number of flavors to just 4: glyf (TT, optionally also cubic), CFF2 (for political reasons), SVG and sbix.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Drop EBDT, CBDT and CFF. </div><br><br><div><br><br><br><div><br><br><div dir="ltr">On Sat, 12 Sep 2020 at 00:43, Adam Twardoch (Lists) <<a href="mailto:list.adam@twardoch.com" rel="noreferrer" target="_blank">list.adam@twardoch.com</a>> wrote:<br><br><br></div><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br><br><div><br><br><div><br><br><div><br><br><div dir="auto">OpenType currently has provisions for multiple sources for glyph rendering: </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">1. Outlines</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">- glyf (optionally with fvar)</div><br><br><div dir="auto">- CFF</div><br><br><div dir="auto">- CFF2 (with or without variations)</div><br><br><div dir="auto">- SVG</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">2. Bitmaps</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">- EBDT</div><br><br><div dir="auto">- CBDT (uses PNG)</div><br><br><div dir="auto">- sbix (also uses PNG)</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">In the spec, the relationship between these seven flavors is extremely convoluted, and sometimes contradictory.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fcbdt&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659402348&sdata=2tVhDUno4%2BBq9k9urcb2BB7tOO58cW4Mnm32PQJ95ZQ%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt</a><br><br> says nothing about whether some other glyph rendering source (e.g. glyf) must or may be present in the font or not.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fsbix&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659412342&sdata=cvWOLEkXBDom9oxwml8h4YHTFbT%2BJEjrJK4VzpHrKg4%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/sbix</a><br><br> says that the font "may also" contain glyf or CFF, but makes no mention of SVG, CBDT or CFF2.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fsvg&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659412342&sdata=Ijuy%2FRnfMOLVW96Tsauigv6ZxpB8pUu%2FWTZPDc%2B67hY%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/svg</a><br><br> says »For every SVG glyph description, there must be a corresponding TrueType, CFF or CFF2 glyph description in the font.« No mention of sbix or CBDT.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fotff&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659422339&sdata=W%2Fcc%2B8V6UQjb7YLaZbjJMrWlEDocifHSlygiIdBzcLo%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/otff</a><br><br> says » An OpenType font file contains data, in table format, that comprises either a TrueType or a Compact Font Format (CFF) outline font. « By this, one might read that am sbix-only SFNT or a CBDT-only SFNT or an EBDT-only SFNT or perhaps even a CFF2-only<br><br> SFNT is not an OpenType font.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">The same page says » OpenType fonts that contain TrueType outlines should use the value of 0x00010000 for the sfntVersion. OpenType fonts containing CFF data (version 1 or 2) should use 0x4F54544F ('OTTO', when re-interpreted as a Tag) for sfntVersion.«<br><br> Here CFF is used as “1 or 2”, while in the SVG spec, CFF is named separately from CFF2 so it must mean "1". Again, no guidance for sbix-only, CBDT-only or EBDT-only fonts.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Same document: » Required Tables. Whether TrueType or CFF outlines are used in an OpenType font« Again, no word on non-outline fonts (sbix-only, CBDT-only, EBDT-only).</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Same document: » OpenType fonts may also contain bitmaps of glyphs, in addition to outlines.« But the sbix table says outlines are optional. Contradiction? </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">In the same document 'maxp' is listed as required in the same way as 'head' is but<br><br><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fmaxp&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659422339&sdata=W9pmetXwIIbhnrKtYNywMS1AMyevWBZJUtd%2F7AK%2FeYI%3D&reserved=0" rel="noreferrer" target="_blank"><br><br>https://docs.microsoft.com/en-us/typography/opentype/spec/maxp</a> says » This table establishes the memory requirements for this font. Fonts with CFF data must use Version 0.5 of this table, specifying only the numGlyphs field. Fonts with TrueType outlines<br><br> must use Version 1.0 of this table, where all data is required.« It’s unclear if “CFF” is inclusive of CFF2 here or not, and it’s unclear what role the table has with bitmap-only fonts.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Same on </div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fhmtx&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659432331&sdata=qRAiffd%2F1bptT4j32rGGJtu6u8K1oj5JPt%2FcgQ4p%2Brc%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/hmtx</a><br><br> — the description goes into detail about glyf, CFF & CFF2 but makes no reference to bitmap-only fonts. </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Therefore, the spec does not provide sufficient info about which tables should or must be in an outline-less sbix-based, CBDT-based or EBDT-based font.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Febdt&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659432331&sdata=oIS2HpcMj8ha2TFMu6scwQw8PAM8NKYypngmOQ9H9%2BI%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/ebdt</a><br><br> and </div><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Feblc&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659442328&sdata=DTf%2B9BnRYY%2BwAWJZtzD6xJoQkT1zk8m2ttWuwdkfsCg%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/eblc</a><br><br> make no mention of their relationship to the outline formats, or to other bitmap formats. </div><br><br><div dir="auto"><br><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Frecom%23embedded-bitmaps&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659442328&sdata=q7VjBF2rFCpJ9kj9%2ByQJ440NsQcpm1D%2FI50%2F%2FQ0b9NM%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/recom#embedded-bitmaps</a><br><br> explicitly allowes EBDT-only fonts and says that all required tables except glyf and loca should be there. Does that still include maxp & hmtx? </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Since recommendations allow EBDT-only, one could think that CBDT-only is also allowed, because somewhere it says that CBDT uses similar concepts to EBDT. But maybe someone else might think differently. </div><br><br></div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">sbix and CBDT also make no mention of their relationship with each other, and I think sbix/CBDT are not coordinated either.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">There is a reluctance on some parties’ part to support SVG in fonts, but I can easily see how either CBDT or sbix or both could be used for SVG the same way as EBDT was used for TT outlines — as a hand-tuned representation for small sizes. An<br><br> engine might prefer the fast PNG rendering for smaller sizes and switch to slower SVG for larger sizes, or if it doesn't have an SVG renderer, it still might render upscaled PNGs from sbix/CBDT (as Apple used to do with sbix-only, and as Google still does<br><br> with CBDT-only).</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">In OFF2, we might do away with EBDT/CBDT entirely. EBDT is no better than sbix, in fact it's worse because it has a max PPM of 127 (!). sbix can be used for all kinds of bitmaps, and its PNGs can be monochrome or grayscale. </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">I don't see why OT fonts that have SVG also MUST have glyf/CFF(2), while sbix does not have to have glyf/CFF(2), and EBDT/CBDT also, in practice, doesn't have to have outlines. </div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">If an sbix-only font (without glyf/CFF(2)) is valid (at least some part of the spec suggests it is), then a font with sbix and SVG but without glyf or CFF(2) also should be valid, bit isn't.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">Finally, I don't think it's clear whether a CFF2 table and a CFF table can or cannot co-exist in the same font.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Frecom&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659452319&sdata=%2BxYr7nAngUjPQJ0PaEs2b5A6NDe4warYAMuSh7tlSME%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/recom</a><br><br> says »Mixing Outline Formats</div><br><br><div dir="auto" style="border-color:rgb(255,255,255)">Both Microsoft and Adobe recommend against mixing outline formats within a single font. Choose the format that meets your feature requirements.« </div><br><br><div dir="auto" style="border-color:rgb(255,255,255)"><br><br><br></div><br><br><div dir="auto" style="border-color:rgb(255,255,255)">But of course... <br><br><div dir="auto"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fotff&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659452319&sdata=wMuVyEbVt7qcxqFXGi4adiGHNgYmgg8fa0JUTb7Apkw%3D&reserved=0" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/typography/opentype/spec/otff</a><br><br> lists “SVG Outlines” as the 3rd kind of outlines next to “TrueType Outlines” and “CFF Outlines”, and the SVG table spec says you *must* mix SVG Outlines with either TT or CFF outlines, so obviously that recommendation is, uh, err... 😁</div><br><br></div><br><br></div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">I hope we can clarify these relationships.  </div><br><br></div><br><br></div><br><br></div><br><br><div><br><br><div><br><br><div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto">A.</div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><br><br><br></div><br><br><div dir="auto"><br><br><br></div><br><br><br><br><br><br><br><br></div><br><br><br><br><br><br><br><br></div><br><br><br><br><br><br><br><br></div><br><br><br><br><br><br><br><br></blockquote><br><br></div><br><br></div><br><br>_______________________________________________<br><br><br>mpeg-otspec mailing list<br><br><br><a href="mailto:mpeg-otspec@lists.aau.at" rel="noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br><br><br><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7Crenzhi.li%40microsoft.com%7C032984bc5e5d40f1179d08d856ab375e%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637354640659462316&sdata=Jj1189xsw80U4%2FtlcjtPvapKZtd%2FgjdXHfhVKj8lLac%3D&reserved=0" rel="noreferrer noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br><br><br></blockquote><br><br></div><br><br></div><br><br></div><br><br><br><br></blockquote></div></div>