fontdb
fontdb copied to clipboard
RazrFalcon
Prefer name ID 16 over 1 if available for family
I was wondering why some fonts in my scan had unexpected family names (e.g. DejaVu Sans Light instead of DejaVu Sans)... according to the Name ID docs, ID=1 is the "font family name" with the additional requirement that it should be shared by at most four fonts. ID=16 is essentially the same name but without this restriction, though it may be absent(?) hence we use 1 if 16 is not available.
Completely off-topic, I now want serde support for Weight, Stretch and Style. Shall I just implement locally (serialize_with etc)?
Edit: this was pretty easy with thanks to serde.
This was intentionally removed https://github.com/RazrFalcon/fontdb/commit/0f412edd99f0b6b75381c3928988f59fd4e6e3ca, but I can't remember why... I assume it broke resvg or something.
I guess because of this (link):
A font family name only specifies a name given to a set of font faces, it does not specify an individual face. For example, given the availability of the fonts below, Futura would match but Futura Medium would not
So DejaVu Sans is a family name, but DejaVu Sans Light is a face name.
I really have to find time to write a test suite.
Since there is already logic for matching by weight, I would assume that would deal with "light"/"medium" variants. The weight matching logic is almost redundant with this restriction. But I guess there are reasons... ?
The reason I brought this up is because most font management tools on my system include 9 faces under the "DejaVu Sans" family name, including this "Light" variant. fc-list lists both family names:
$ fc-list "dejavu sans light" family
DejaVu Sans,DejaVu Sans Light
So the question then is should we more closely follow what fontconfig does or the CSS docs?
I also don't really see why there is a distinction between serif and "serif". For example, Linux's fontconfig (at least on my machine) has an alias between Carlito and Calibri, which implies that it is not only the special sans-serif etc. generic families which may be/have aliases. Which makes me wonder how closely browsers actually follow this spec (since I think they do use fontconfig on Linux?).
fontdb follows CSS, not fontconfig logic, because it was designed for SVG rendering.
Fonts handling is different on all OS'es too. Will have to check what Windows and macOS does.
The problem with fonts handling in general is that there are no single, correct behaviour. Everyone are doing whatever they want.
Which makes me wonder how closely browsers actually follow this spec
Good thing that all of them are opensource, therefore we have to check what they are doing. But this also will take time.