A number of MacOS fonts fail to render since 0.12.0

[maxmelander]

After upgrading to 0.12.0 from 0.11.2 a significant number of fonts no longer render.
I believe this to be a Swash issue that happened somewhere between 0.1.12 and 0.1.17. For context we use swash outside of cosmic text for scaling glyphs, so I can see that we get None back when calling scale_outline on the swash scaler. I have also confirmed that calling draw on the cosmic buffer never calls the callback function for the affected fonts, but we do get correct LayoutRuns.

We load these fonts using the Local Font Access API. Interestingly, where there are Google Font duplicates, such as with Baskerville, the Google Font versions do still work.

Local MacOS fonts no longer working include (and many more):
Helvetica
Baskerville
Chalkboard

I have not tested on any other OS or outside of our wasm context.

[nicoburns]

This seems likely to have been caused by dfrg/swash#52. As a workaround, I'd recommend pinning an older version of Swash.

(CC: @dfrg)

[dfrg]

Thanks for reporting. A bit more context would be helpful in identifying the problem. Which version of macOS? Do you know if these happen to be .ttc files?

[maxmelander]

I'm on MacOS 13.5.1 (22G90). All of the files listed above are .ttc files. But I can also find .ttf files that fail. One example is the font Big Caslon.

[dfrg]

Thanks, I'll dig up a macOS 13 system and take a look at those fonts.

[dfrg]

I'm not able to reproduce this locally so I can only assume that the issue is related to the wasm build. Unfortunately, I don't really work with wasm and don't have a rig set up to do testing so I won't be able to investigate this further until I have the time to set one up.

[maxmelander]

Alright, thank you. I'll dig around a bit tomorrow and report back if I can figure out where things go wrong. Appreciate your time:)

[maxmelander]

Hey again @dfrg .
I did some digging, and found that Skrifa is returning a ReadError::InvalidSfnt(0x74727565) for the fonts in question.

Looking up Apple's TrueType reference, I found this:

The values 'true' (0x74727565) and 0x00010000 are recognized by OS X and iOS as referring to TrueType fonts. 
The value 'typ1' (0x74797031) is recognized as referring to the old style of PostScript font housed in a sfnt wrapper. 
The value 'OTTO' (0x4F54544F) indicates an OpenType font with PostScript outlines 
(that is, a 'CFF ' table instead of a 'glyf' table). Other values are not currently supported.

Fonts with TrueType outlines produced for OS X or iOS only are encouraged 
to use 'true' (0x74727565) for the scaler type value. 
Fonts for Windows or Adobe products must use 0x00010000.

A bit out of my depth, but it kinda sorta sounds to me like 0x74727565 should be included in this check in the read-fonts crate:

    fn with_table_directory(
        data: FontData<'a>,
        table_directory: TableDirectory<'a>,
    ) -> Result<Self, ReadError> {
        if [TT_SFNT_VERSION, CFF_SFTN_VERSION].contains(&table_directory.sfnt_version()) {
            Ok(FontRef {
                data,
                table_directory,
            })
        } else {
            Err(ReadError::InvalidSfnt(table_directory.sfnt_version()))
        }
    }

I still haven't checked this outside of a wasm build, but it feels curious that your weren't able to reproduce this yourself. I don't understand how running in wasm could change the sfnt version.

[dfrg]

I’m not sure either but as luck would have it, we added the true tag a while back and just released a new version of skrifa yesterday containing this change. I’ll update swash later today but you might be able to patch with skrifa version 0.20 to see if it works.

[dfrg]

ref googlefonts/fontations#961

[dfrg]

Forgot to follow up but swash 0.1.18 was published and should hopefully fix this.

[maxmelander]

I've tested with the new version and can confirm that it fixes the issue. Thank you!:)