Fallback features

[christolliday]

Here are a few features that are higher level than what this library currently provides, but that I think would be useful for most users of this library and make sense to include:

1. Add a method (query_closest_available?) that given a font name or parameters will return the requested font name or fallback to a basic, available font if the requested font is not available.

2. Adapt the above method to return the most similar available font for the given parameters. Servo does this by defining a distance function between font descriptors, here.

3. Include a feature flag that if turned on will bundle a basic fallback font in your application binary, that the method in 1 and 2 will fallback to in the case that no system font is available. This flag could be enabled by default for any platforms that are otherwise unsupported to allow at least basic font loading on any platform that rust supports.

4. Allow applications to specify their own custom fonts that can be bundled, queried and loaded, not sure how this would work at the moment.

Of these I think 1 and 3 are the most important, whereas 2 and 4 are more "nice to have" and could be added later.

[matprec]

Thanks for your feedback!

3. Include a feature flag that if turned on will bundle a basic fallback font in your application binary, that the method in 1 and 2 will fallback to in the case that no system font is available. This flag could be enabled by default for any platforms that are otherwise unsupported to allow at least basic font loading on any platform that rust supports.

Hmm i don't really like the side-effects in this proposal. What's wrong with .unwrap_or(my_default_font)? This is more expressive and gives good customization opportunities. If you want it anyways, it can be easily wrapped:

Implementor:

const default_font: &'static [u8] = include_bytes!(...);

fn load_font(name: &str) -> Font {
    let bytes = system_fonts::query_closest(name).unwrap_or(default_font);
    ...
}

4. Allow applications to specify their own custom fonts that can be bundled, queried and loaded, not sure how this would work at the moment.

This would could be done in its own module, since we can't rely on the system easily. We would have to pull in deps for ttp / otf fonts and manually inspect them. Could be hidden behind a feature flag though

[christolliday]

Actually thinking about this a little more, I think these features might be a little higher level than makes sense for this library, they are things I want to be in limn but they way I want to implement them might not make sense for other projects that load fonts or aren't high level UI libraries. All these features can be added to projects that depend on this library of course.

The general idea is just to have a central registry with a common interface for both system and application bundled or specified fonts, then whatever font "selector" code can use consistent rules to select from all sources, but the selector code would probably be better off being at a high level as well.

I think the best way to go is implement what I'm thinking about is add it to limn first. Later it could be it's own crate, or I might propose it be merged in here as a separate module, if that makes sense.

Anyway thanks for having a look. I'll close this and if it makes sense later, open a new issue when it's implemented in limn.