[MPEG-OTSPEC] Agree on goals/principles for font content specification as a priority

[Terence Dowling]

If you are considering a new "breaking" font format I'd ask that there

should be some common agreement for what bits actually go into the

font file.


Consider:

1) A simple checksum is insufficient to verify font integrity, so if
integrity

   checks are to be included they should be sufficiently robust.

2) No font consuming program can depend on the content of a font to be

  valid. The consuming program must be capable of defending itself from

 malicious content.

3) Every bit in the font file should "earn" its place and provide some
benefit beyond

 "that field was in the old spec".

4) Fonts, especially fonts with rich content, can be large. There is a
real tension between

having a data value appear in only one place and the operational
consideration to avoid

having to load the whole font file to be able to do anything (locality
of reference).

5) Data tables like cvt & prep are a potential security issue. The goal
was originally to have

an opportunity to do some setup like work only once, but since glyph
programs can store

into cvt, all manner of bad things can be done to alter results such
that a secure font

processor must cache an unmodified version of the cvt after prep or redo
the work for

each glyph rendered. If you doubt that cvt manipulation to significantly
alter rendered

text (and the human readable understanding of same), perhaps some on
this list will be

willing to share the relevant test fonts. I'm retired now so I no longer
have access to what

I produced as a work product.

6) There is a significant difference between resolution dependent
rendering (ttf) and scaled

rendering (cff). An example from the Microsoft world (Parchment)
provides an example

of how drastically a glyph shape can change based on specific rendering
conditions. While

the shape changes exhibited by Parchment are "interesting" and "benign",
please understand

that the shape shown "on-screen", "desktop printer", and "high
resolution printer" could all

be sufficiently different that they could completely alter the human
readable sense of the result.


In no way is this list something you all will agree on, but while the
specification is

still open to significant change  it would be useful to have some agreed
guiding principals

against which suggested content proposals can be tested.