Support for providing multiple webfont formats as fallbacks

[kontur]

Wondering if it makes sense to have a implementation in tune with the @font-face declaration that supports passing in several formats.

[graphicore]

I'm not sure. Can we find a good use case for this? Maybe the solution is something else eventually.

[kontur]

I suppose aside from legacy fallbacks pre widespread woff support, the case would be someone providing woff2 for browsers that support it, but woff to those that don't. Not entirely sure how to approach this in my wordpress plugin neither - so far I am offering woff and woff2 as default suggested formats, but also allow uploading eot, ttf and svg and generate the @font-face rule according to what's supplied, should someone want to include older font formats as well. There might be a case for simply insisting on woff only, and woff2 eventually. I'm not familiar with the FontFace API, but it would seem one can also provide several urls to a FontFaceSet just like with @font-face

[graphicore]

I don't think we need to cover this. woff/woff2 is essentially to save some bandwidth via compression. We're downloading an OpenType format anyways and use that download in the @font-face rule directly. I'd suggest to use otf or ttf for the best compatibility, then the legacy fallbacks needed would be just eot or svg. And these probably don't work very well to test opentype features etc ... I'm not sure if it's worth the effort. I think browsers that need eot or svg are all pre 2011. Anyways, having fallbacks configurable could be done. I just don't think it's very high on my list.

I'm not familiar with the FontFace API, but it would seem one can also provide several urls to a FontFaceSet just like with @font-face

If there is a FontFace API present I'd expect at least woff to be supported, but we fall back to @font-face as well.

[kontur]

I'll have a go at this, because I haven't found a proper way to supply "the most suitable" of several available files without browser sniffing - so the @font-face or FontFace API would be a good way to let the browser choose. I found out that FontFace API actually lets you supply a "@font-face" rule as the second argument, as a fallback.
So what I'm thinking I'll do is separate single format and multiple format loading, where all loading functions take either a string (e.g. like now) or alternatively an object with format keys and url values for multiple formats of the same font. We can make the order of preferred formats a config array, in order from most to least desirable, say OTF > TTF > WOFF2 > WOFF > EOT. Either way, with multiple files then we pass the best match from the passed in formats to FontFace load, but also a generate @font-face with all passed formats, which we also use in case FontFace is not available.

[graphicore]

Yeah, I guess you can give it a shot. For EOT, I'd expect that it's not supported by Opentype.js, but maybe it is (It's OpentType after all "Embedded OpenType").
But when you go via @font-face you may end up with not being able to use any of the Opentype.js related stuff. We may have to identify widgets that need info that comes via Opentype.js, like finding features in the font.
Maybe, another version of FontsData is required, that takes it's information from the options rather than from Opentype.js?

A desirable order is rather WOFF2 > WOFF > EOT > ... because of the lower file sizes, or?

[kontur]

I don't think the @font-face declaration excludes any of the Opentype.js features per se, why would it - it's just a different method of getting the same file to the browser?

The problem I am facing is that all font files are loaded via XHR, so the normal progression of letting the browser load the most appropriate file doesn't really apply, even if I can write the makeWebFont function that way. The way the WebfontProvider works means it already requires the files to be loaded, which defeats this fallback effort by load overhead. Really not sure how to go about this, again.

[graphicore]

The problem I am facing is that all font files are loaded via XHR, so the normal progression of letting the browser load the most appropriate file

So that's how it works at the moment, load the font via XHR, then look inside with opentype.js to get all the data provided by fontinfo.js. And because it's loaded already, use it with WebfontProvider.

[graphicore]

even if I can write the makeWebFont function that way. The way the WebfontProvider works means it already requires the files to be loaded, which defeats this fallback effort by load overhead. Really not sure how to go about this, again.

I said two weeks ago:

Maybe, another version of FontsData is required, that takes it's information from the options rather than from Opentype.js?

I still think that's needed. Maybe we could try to make our current FontsData export a json of all the Data it provides. Then make a new one that provides data from just that json. So, we could load the prepared fontinfo, alongside with a list of different file types for each font. I'm not sure how hard or easy it will be to do the json export.

[kontur]

Ah I see now, I must have misunderstood why you suggested switching away from Opentype.js for that matter.