<div dir="auto">❤️</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020, 6:48 PM Terence Dowling <<a href="mailto:terry@tdowling.com">terry@tdowling.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you are considering a new "breaking" font format I'd ask that there<br>
<br>
should be some common agreement for what bits actually go into the<br>
<br>
font file.<br>
<br>
<br>
Consider:<br>
<br>
1) A simple checksum is insufficient to verify font integrity, so if<br>
integrity<br>
<br>
   checks are to be included they should be sufficiently robust.<br>
<br>
2) No font consuming program can depend on the content of a font to be<br>
<br>
  valid. The consuming program must be capable of defending itself from<br>
<br>
 malicious content.<br>
<br>
3) Every bit in the font file should "earn" its place and provide some<br>
benefit beyond<br>
<br>
 "that field was in the old spec".<br>
<br>
4) Fonts, especially fonts with rich content, can be large. There is a<br>
real tension between<br>
<br>
having a data value appear in only one place and the operational<br>
consideration to avoid<br>
<br>
having to load the whole font file to be able to do anything (locality<br>
of reference).<br>
<br>
5) Data tables like cvt & prep are a potential security issue. The goal<br>
was originally to have<br>
<br>
an opportunity to do some setup like work only once, but since glyph<br>
programs can store<br>
<br>
into cvt, all manner of bad things can be done to alter results such<br>
that a secure font<br>
<br>
processor must cache an unmodified version of the cvt after prep or redo<br>
the work for<br>
<br>
each glyph rendered. If you doubt that cvt manipulation to significantly<br>
alter rendered<br>
<br>
text (and the human readable understanding of same), perhaps some on<br>
this list will be<br>
<br>
willing to share the relevant test fonts. I'm retired now so I no longer<br>
have access to what<br>
<br>
I produced as a work product.<br>
<br>
6) There is a significant difference between resolution dependent<br>
rendering (ttf) and scaled<br>
<br>
rendering (cff). An example from the Microsoft world (Parchment)<br>
provides an example<br>
<br>
of how drastically a glyph shape can change based on specific rendering<br>
conditions. While<br>
<br>
the shape changes exhibited by Parchment are "interesting" and "benign",<br>
please understand<br>
<br>
that the shape shown "on-screen", "desktop printer", and "high<br>
resolution printer" could all<br>
<br>
be sufficiently different that they could completely alter the human<br>
readable sense of the result.<br>
<br>
<br>
In no way is this list something you all will agree on, but while the<br>
specification is<br>
<br>
still open to significant change  it would be useful to have some agreed<br>
guiding principals<br>
<br>
against which suggested content proposals can be tested.<br>
<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>