<div dir="ltr"><div dir="ltr">On Thu, Oct 8, 2020 at 11:30 AM John Hudson <<a href="mailto:john@tiro.ca">john@tiro.ca</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>
<div>On 08102020 9:48 am, Behdad Esfahbod
wrote:<br>
</div>
<blockquote type="cite">
<div>Hence my call to make OFF *complete*, by either deprecating
& removing parts that are not complete currently, or add as
new work items to spec them.</div>
<div><br>
</div>
<div>Same about script-shaping specifications. For that, I'm
proposing new work items to develop script shaping
specifications (Indic, Arabic, USE, etc) that are currently NOT
part of OFF.</div>
</blockquote>
<p>Accepting that rasterisation and layout implementation specs
should exist, whether they should exist as <i>part</i> of OFF is
less obvious to me.</p></div></blockquote><div><br></div><div>How so? OFF files include bytes (CFF/CFF2 hinting data as well as GSUB/GPOS lookups) without specification of how to be used to display text using that font. This is akin to an image format specification without a decoding algorithm specified.</div><div><br></div><div>What is the use of such a file format standard then?</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>The layout implementation spec is most critical, I think, because
having different results in shaping and display—using the same
input text and the same font—on different platforms is
unacceptable to everyone. Having different rasterisation on
different platforms is something we’re used to, and ‘acceptable to
Adobe’ seems to me an peculiar criterion for determining which
rasterisation needs to be specified. Does such a specification
make other rasteriser implementations invalid? What if, for a
specific platform or device, a non-conformant rasterisation is
better? So perhaps what we need is an informational specification—<i>not
a standard</i>—that enables reproducible implementation of what
the code in FreeType does, while not favouring this over other
implementations. And if not a standard, then ISO isn't the place
for it.<br>
</p>
<p>JH</p>
<p><br>
</p>
<pre cols="72">--
John Hudson
Tiro Typeworks Ltd <a href="http://www.tiro.com" target="_blank">www.tiro.com</a>
Salish Sea, BC <a href="mailto:tiro@tiro.com" target="_blank">tiro@tiro.com</a>
NOTE: In the interests of productivity, I am currently
dealing with email on only two days per week, usually
Monday and Thursday unless this schedule is disrupted
by travel. If you need to contact me urgently, please
use some other method of communication. Thank you.</pre>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div></div>