<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 9/16/2020 13:08, Behdad Esfahbod
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF63+7Vk_B=1AZMEDiCeYdD-9=-7mLx3w3QeC=R7KkHEiwadgg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br>
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Ignoring the major problem though: that CFF/CFF2 hinting
interpretation is FULLY UNSPECIFIED. <br>
</div>
</div>
</div>
</blockquote>
<p>There are good and valid reasons why the font isn't the proper
repository for deciding</p>
<p>very specific pixel/sub-pixel rendering issues. Among them:</p>
<p>1) The end user may have an opinion concerning the balance
between metric <br>
</p>
<p> fidelity and readability</p>
<p>2) ClearType/CoolType rendering for low resolution devices (200
dpi or less) can, <br>
</p>
<p> if done well, improve readability while not greatly
compromising metric fidelity. <br>
</p>
<p>3) Some end users are more color sensitive than others so they
may require <br>
</p>
<p> different levels of control with respect to color fidelity.</p>
<p>4) Some devices have rather non-traditional physical device
geometry issues and <br>
</p>
<p> an OEM may want to take those issues into account with their
embedded <br>
</p>
<p> rasterizer implementation.</p>
<p><br>
</p>
<p>Early desktop publishing started with ~72 dpi monochrome displays
and hand-tuned <br>
</p>
<p>bitmap fonts were common. Device technology evolved and device
resolution <br>
</p>
<p>became more varied. When resolution was still low and devices
were essentially <br>
</p>
<p>monochrome, fully instructed fonts (that allow the font designer
full pixel level control) <br>
</p>
<p>enhanced user experience (more choices of pixels/em and better
user experience with <br>
</p>
<p>devices of increasingly varied resolution. <br>
</p>
<p><br>
</p>
<p>Adobe chose a different model, burden the rasterizer with the job
of understanding <br>
</p>
<p>device geometry and properties and have the font designer provide
concise information <br>
</p>
<p>about glyh shape issues (stem width, alignment zones etc.) i.e.
hints. Over the growth</p>
<p>of desktop publishing and display screens becoming "final form"
rather than "print preview"</p>
<p>the rasterizer capability grew, yet the original fonts continued
to be appropriate.</p>
<p><br>
</p>
<p>I suggest that it is inappropriate to expect a font
designer/developer to have access to</p>
<p>the range of devices on which their font product may be used.
Instructions burden the</p>
<p>font designer/developer with all of these issues, hints do not.</p>
<p><br>
</p>
<p>I'll say it again, the font wars are over. Still, it is useful to
understand the compromises <br>
</p>
<p>built into the choices that have been made.</p>
<p><br>
</p>
<p>Terry Dowling<br>
</p>
<blockquote type="cite"
cite="mid:CAF63+7Vk_B=1AZMEDiCeYdD-9=-7mLx3w3QeC=R7KkHEiwadgg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<br>
</div>
</div>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mpeg-otspec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>