fix: OS/2 tables must be included when subsetting OpenType fonts

[yisibl]

In Chrome and Firefox, use OpenType Sanitizer to check the validity of fonts. Can we introduce OpenType Sanitizer to test the validity of allsorts subsetted fonts?

 ttx -l SourceSerifPro-Regular-sub.ttf
Listing table info for "SourceSerifPro-Regular-sub.ttf":
    tag     checksum    length    offset
    ----  ----------  --------  --------
    OS/2  0x60539B1C        96       188
    cmap  0x0703061B       274       284
    glyf  0x5CD24954       710       560
    head  0x1BB196DC        54      1272
    hhea  0x0B6406B6        36      1328
    hmtx  0x0DBE0104        28      1364
    loca  0x01F702D0        16      1392
    maxp  0x001700ED        32      1408
    name  0x25D3FFE5      1978      1440
    post  0xFFD10032        32      3420
    prep  0x68068C85         7      3452

Fixes: https://github.com/yeslogic/allsorts-tools/issues/16

[wezm]

Thanks for working on this, it is most appreciated. You're perhaps wondering why this wasn't done earlier if it's such a small change: Allsorts was extracted from Prince, where it's used to handle fonts embedded into PDFs. In this context it's not (or at least has not been so far) necessary to include all tables required to produce a valid stand-alone font file. I.e. the reason they aren't valid is not due to negligence, but by design for the original use case. However, we do want the subsetting functionality to be useful to a broader audience (time permitting) but we also don't want to unnecessarily increase the size of every PDF that our customers create.

With that context in mind, it requires a bit more consideration from us to determine the way forward. I have already slated this for discussion at an upcoming meeting. One option is to include the table as per this PR. If we decide not to do that in order to support our use case then it will probably require the ability for the caller to indicate which tables to include in the subset font. I imagine there would be some pre-defined "profiles" so this functionality easy to use. It's worth noting that for stand-alone use it's highly likely that gsub and gpos should be included too (they are not currently), if present in the input font.

So leave it with me, I'll aim to get back you this week.

[yisibl]

Thank you for your reply. I'll close this PR first.

Yes, it would be great to have a separate configuration to distinguish between PDF and normal font subsetting. Indeed, we also need to handle the gsub and gpos tables correctly.

As far as I know, allsorts is the first library to implement subsetting in Rust, which will be of great importance. In particular, allsorts can provide a good comparison and reference to the googlefonts/oxidize project. You can take a look at this project.

[wezm]

So leave it with me, I'll aim to get back you this week.

To follow up on this. We discussed this at the meeting today and agreed that a mechanism to configure the tables to include would be ideal. We have no time frame for when we will get this implemented though (I.e. it's not currently scheduled to be worked on as we are focussed on other things at the moment). I have created issues to track the various things that we need in order to produce valid standalone subset fonts and updated the tracking issue with them all.