Separate font family and font style in font name

[lucaswoj]

From @nickidlugash on June 3, 2015 20:16

Right now a font is specified with a string that concatenates font family and style, e.g. "Open Sans Regular". If we split it up, we can implement smart fallbacks based on style.

/cc @mikemorris

Copied from original issue: mapbox/mapbox-gl-style-spec#284

[lucaswoj]

From @mikemorris on June 3, 2015 20:32

Just wanted to add that I'm not sure if we'll be able to easily break down the style as precisely as CSS does, we may be limited to the string that FreeType gives us for style_name.

While the detailed CSS spec looks like:

font-style: none/normal/italic/oblique,
font-variant: none/normal/small-caps,
font-weight: none/normal/bold,
font-family: Open Sans/serif/sans-serif

...we may instead be limited to a family name Open Sans and a style string Bold Italic unless the font file contains any clues outside of the name about the variant or weight. I'm actually curious what logic browsers are using to map the CSS spec back to system font files.

[lucaswoj]

From @mikemorris on June 3, 2015 21:22

Hah, wow, so weights and variants should be present in the font file according to the OpenType spec, even though it doesn't look like FreeType can read them directly. Chromium's blink engine is constructing a bitmask to match against those.

[lucaswoj]

From @mikemorris on June 3, 2015 21:53

The Source/platform/fonts directory in the blink repository is pretty fascinating for digging deeper here...

[lucaswoj]

From @mikemorris on June 3, 2015 22:17

We may be able to read metrics from the OS/2 table by building on @lbud's work in node-fontnik/tables and passing the OS2 FT_Sfnt_Tag.

[lucaswoj]

From @peterqliu on June 3, 2015 22:25

Added wrinkle (or maybe the same wrinkle): if we decouple family and style, what happens when a stylesheet specs a style that doesn't exist for the family? Would there have to be a fallback style, as well?

Would probably run into this a lot if you're trying out different families for size, or (in the future) custom uploading only one weight for your type family.

[lucaswoj]

From @nickidlugash on June 3, 2015 23:31

if we decouple family and style, what happens when a stylesheet specs a style that doesn't exist for the family?

Wouldn't the editor only enable you to choose from styles that do exist? It would be possible to hand-write invalid combinations, but currently you can hand-write invalid strings for font names as well.

[lucaswoj]

From @samanpwbb on June 3, 2015 23:39

How would this work with user fonts? We can't expect all fonts uploaded to have the metadata necessary to expect to split family from style, can we?

[lucaswoj]

From @nickidlugash on June 4, 2015 0:30

How would this work with user fonts? We can't expect all fonts uploaded to have the metadata necessary to expect to split family from style, can we?

I'm not sure – @mikemorris?

[lucaswoj]

From @lbud on June 4, 2015 1:8

@samanpwbb I would actually expect nearly all to have at least that metadata, except for maybe amateur handcrafted fonts, which we would probably determine family={Name of Font} and style=[none]/`` (empty) — but I feel like this would be a really uncommon issue.

Actually, if anyone has some really obscure/amateur fonts, npm install fontnik and run

fontnik.load(fs.readFileSync(<path_to_font>), function(err, res) {
    console.log(res)
})

(as specified here) you'll be able to tell if they have a family_name and style_name :)

[lucaswoj]

From @samanpwbb on June 4, 2015 1:10

Oh wow, in that case I am definitely in favor of separating style and family. There are a lot of advantages. I'm sure we could figure something out for the few cases that don't provide the metadata.

[lucaswoj]

From @mikemorris on June 8, 2015 13:35

metadata necessary to expect to split family from style

Yep, we can definitely get this much from FreeType. More specific details like weight (numerical value as opposed to just a string) may be specific to OpenType fonts.

[lucaswoj]

From @mikemorris on June 9, 2015 19:21

style_name
The face's style name. This is an ASCII string, usually in English, that describes the typeface's style (like ‘Italic’, ‘Bold’, ‘Condensed’, etc). Not all font formats provide a style name, so this field is optional, and can be set to NULL.
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec

Ugh. This makes things a little more complicated on the backend, but for the purpose of the style spec I think it just means font-style should be optional. Splitting family and style in the spec should still be possible and worthwhile though.

[lucaswoj]

This issue was moved to #4091

[jfirebaugh]

Closing here; see #6584.