<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-size: 13px;color: rgb(0, 0, 0);font-family: arial, sans-serif;"><style type="text/css"><!-- DIV {margin:0px;} --></style><div style="font-size: 13px;color: rgb(0, 0, 0);font-family: arial, sans-serif;">Behdad,<div>I think you're missing something here. That may relate to the unfortunate conflation of two very different technological approaches under the label of "hinting".</div><div><br></div><div>I don't know whether it's still true, but back during the so-called font wars, people who developed TrueType fonts were distinctly unhappy about TrueType instructions being called hints, because they weren't meant to be hints; they were meant to drive the rasterizer very specifically. The rasterizer guys at Adobe used to talk about the distinction between programmatic "hints" (as in TrueType) and parametric "hints" (as in Type 1, then CFF).</div><div><br></div><div>It's intriguing to suggest that handling font rasterization could be done via generic algorithms. That's actually in line with Adobe's original goal. The idea was to keep improving the rasterizer until it got to the point where hints were no longer useful. While rasterizer environments have improved a lot, and some indeed no longer use hints, the use of hints continues to make a measurable improvement in many cases.</div><div><br></div><div>I could see an argument that the TrueType rasterizer is part of the TrueType format, and thus effectively documented. That's true to the extent the TrueType instructions are actually executed as written, although in many (most?) cases that's no longer what happens, as Terry pointed out. But the whole point of T1/CFF hints wasn't to control rasterization, but rather to simply support (not drive) the rasterizer – the piece that should actually know what are the characteristics of the device it's part of. Adobe developed a large number of rasterizers, each optimized for its intended use. (Terry helped develop a number of those, and knows what he's talking about.)</div><div><br></div><div>Of course there is a thing that approaches being a "generic" rasterizer – one optimized for imaging text on a square-pixel LCD screen. That's what we open-sourced in Freetype, so that Google's (and everyone else's) CFF fonts would display as well as possible in their primary target environment.</div><div><br></div><div><div>From my perspective the fact that CFF and TTF are very different in their relationship to rasterization is not a mark against CFF; it's just a fact – each does a good job in its different environment. But I think it's notable that most of the undocumented changes in TTF rasterization have been moves toward the CFF approach.</div></div><div><br></div><div>The number of environments in which T1/CFF rasterization is functionally undocumented is roughly equivalent to the number of environments in which TrueType rasterization is functionally undocumented. If the state of rasterization documentation is a valid reason for proposing to remove CFF from the spec, it's also a valid reason to remove TrueType. That's just equitability, not what-aboutism. But while I can imagine reasonable arguments for moving ahead without CFF/CFF2, I don't honestly see documentation as one of them.</div><div><br></div><div>Thanks for your consideration.</div><div>David Lemon</div><div><br></div><div><blockquote style="padding-left: 5px; margin-left: 0px; border-left: #0000ff 2px solid; font-weight: normal; font-style: normal; text-decoration: none; font-size: 10pt; font-family: arial,sans-serif; color: black;">-----Original Message-----
<br>From: Behdad Esfahbod <behdad@behdad.org>
<br>Sent: Sep 17, 2020 5:16 PM
<br>To: Dave Crossland <dcrossland@google.com>
<br>Cc: mpeg-otspec <mpeg-otspec@lists.aau.at>
<br>Subject: Re: [MPEG-OTSPEC] Hints, TT and CFF (was: Re: Proposal to make OFF complete)
<br><br><div dir="ltr">Just to complement my argument: to anyone who claims that CFF/CFF2 hinting being unspecified is *by design*, let me make two points:<div><br></div><div>- Hinting, *by definition*, is to optimize rasterization of fonts on constrained devices. It is to *improve on* what would otherwise be rendered by generic algorithms. So, to suggest that hinting can be done by a generic algorithm is an oxymoron.</div><div><br></div><div>- Indeed, as evidence of the above: when Google was commissioning Noto Sans CJK from Adobe, the Adobe team insisted that they will only do that if Google also pays to liberate the Adobe CFF rasterizer to be integrated into FreeType. Because they deemed their CFF fonts *unusable* without the Adobe rasterizer.</div><div><br></div><div>Does that leave any doubt that CFF only benefits Adobe? What font designer hints fonts to unknown hinting-interpretter anyways?</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a target="_blank" href="http://behdad.org/">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 8:50 PM Behdad Esfahbod <<a target="_blank" href="mailto:behdad@behdad.org">behdad@behdad.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Sep 16, 2020 at 5:32 PM Dave Crossland <<a target="_blank" href="mailto:dcrossland@google.com">dcrossland@google.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Sep 16, 2020, 4:08 PM Behdad Esfahbod <<a target="_blank" href="mailto:behdad@behdad.org">behdad@behdad.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Aug 27, 2020 at 7:50 AM Dave Crossland <<a target="_blank" href="mailto:dcrossland@google.com" rel="noreferrer">dcrossland@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Haha, awesome!<br><br>I must admit my ignorance with regards to CFF2, but, isn't one of the major features of CFF2 that hints can vary? </div></blockquote><div><br></div><div>Major in what way? Yes, CFF2 hints can vary. Also yes, TT-based varfonts' hints can also vary.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Major in that Ken's fonts don't take advantage of it, and yet a "business case" for CFF and CFF2 that I've heard is that rendering is superior because of the hinting model..</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Ignoring the major problem though: that CFF/CFF2 hinting interpretation is FULLY UNSPECIFIED. So varying or not is moot.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I'm eager to hear your thoughts on the thread where this was discussed, as Terence I believe proposed that TTF hinting is also unspecified. </div></div></blockquote><div><br></div><div>I'm not going to reply to Terence's email because it qualifies for "whataboutism". That is, TTF hinting might be underspecified. But that doesn't detract from my point, that CFF/CFF2 hinting is FULLY unspecified. That sounds more like Eric's reply though. Terence's goes into CVT details that I find wrong / irrelevant.</div><div><br></div><div> </div></div></div>
</blockquote></div>
</mpeg-otspec@lists.aau.at></dcrossland@google.com></behdad@behdad.org></blockquote></div></div></div></body></html>