Search code examples
fontsopentype

How can an out of date implementation gracefully process a new version of an OpenType font?


You'll find below the following text in section Version Numbers of the MS OpenType font file specification:

Implementations reading tables must include code to check version numbers so that, if and when the format and therefore the version number changes, older implementations will handle newer versions gracefully.

Suppose one has written a code to read an OpenType font file with version 1 and later on, the code is used to process the same font file, but with version 2. I just can't imagine how that could "gracefully" succeed, unless the above statement means that one has to update the code to the final version of the font file, before processing it.


Solution

  • You are mistaking "graceful" for "still parses the font file". The idea of the spec is that there are version numbers so that every parser explicitly checks the version number, continues parsing versions it knows how to parse, and properly reports and deterministically behaves on versions it does not know what to do with.

    Graceful:

    • start reading table
    • read version number into table struct
    • check version number
    • branch to parsing function for known version number
    • report inability to continue parsing for unknown version number
    • cancel parse run in a deterministic, documented way
    • application that uses the parser can now gracefully deal with the "cannot load the request font" situation they are in.

    Not graceful:

    • start reading table
    • read bytes into a struct that reflects the most up to date OpenType table format when the parser got written.
    • end up with corrupt data on a version mismatch, possibly hard crash there and then due to accessing memory outside the allocated range for the table.
    • possibly serve corrupted data and/or crash later because offsets were wrong
    • possibly crash the application that uses the parser because corrupt data was returned, or the parser crash was hard enough to kill the process
    • possibly ... etc. etc.

    There is zero expectation that a parser will be able to parse newer OpenType table formats, but it should absolutely deal with them in a graceful manner, checking whether versions match those that it knows how to work with, and reporting the inability to parse data that it has no parsing rules for, with a clean exit that allows consuming applications to do what they need to do.