Font API : collections, concurrency

[benoitkugler]

We should polish our API for font loading : the heavy lifting is already implemented in opentype/api/font but some features are missing in the public font package.

Firstly, we should export a function to support collections. What do you think of

ParseTTC(Resource) ([]Face, error)

?

On the other hand, concurrent usage of fonts was something @whereswaldon was interested in. It is now possible, but requires to properly split the font usage in two parts : the *opentype/api/font.Font which is safe for concurrent use, and the *font.Face, which is not. Should we clarify that in the font package, for instance by also exporting the *opentype/api/font.Font type ?

What do you think overall about font handling ?

[whereswaldon]

I'd love support for collections again. That was a feature Gio lost when switching to our shaper.

That signature looks fine to me.

I would like to expose the dual font/face types so that I could build a shared font loading cache across all of Gio's shaper instances, with each shaper building faces for its own use.

One challenge we have in Gio right now is attaching correct metadata to loaded fonts. We currently kinda force users to do it manually for custom fonts that they load. Is there any consistent way to extract that information from the font data itself? The name of the typeface, the style (bold, italic/emphasis), etc...? Or is that somehow inferred by other software (say, web browsers)?

[benoitkugler]

One challenge we have in Gio right now is attaching correct metadata to loaded fonts. We currently kinda force users to do it manually for custom fonts that they load. Is there any consistent way to extract that information from the font data itself? The name of the typeface, the style (bold, italic/emphasis), etc...? Or is that somehow inferred by other software (say, web browsers)?

Yes, there is a way : on linux systems, this is typically done by fontconfig. I've actually written somewhat similar (but simplified) in the font-scan branch. There are 4 properties available :

• family name
• weight (bold, ...)
• style (italic, ...)
• stretch (condensed, ...)

This is something I will eventually need as well when using go-text for html rendering, so I can propose a PR to integrate the relevant part in go-text : that would be a in new package opentype/api/metadata/

[whereswaldon]

I was actually looking at the font-scan branch recently because I'm thinking about how to properly do system font loading for Gio in the future. I think the approach definitely has merit.

I'd happily review a new PR for the metadata API. :D In the longer term, we should rebase the font-scan branch and open a PR for that functionality as well.

[benoitkugler]

With #51 and #55 merged, I'm closing this as resolved. Feel free to re-open it if more changes about font API should be discussed.