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

[Dave Crossland]

❤️

On Fri, Sep 11, 2020, 6:48 PM Terence Dowling <terry at tdowling.com> wrote:

> 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.
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/277f3cd2/attachment-0001.html>