Prefer the system provided emoji fonts on systems which provide one,
such as Windows, MacOS and Android, even if the Emoji One or Emoji Two
fonts are installed.
This also allows free software OSes such as GNOME to prefer the Emoji
One font, which is not used in other OSes and therefore has a unique
brand identity, by installing them and only them by default.
Users can use more capable fonts while Emoji One and Emoji Two catch up
by installing a font otherwise already used by another system, such as
Google's freely redistributable Noto Emoji font.
https://bugzilla.redhat.com/show_bug.cgi?id=1496761
VotoSerifGX has over 500 named instances, which means it also has over a thousand
name table entries. So we were looking for names for over 500 pattern, looking for
some thirty different name-ids, and using linear search across the 1000 entries!
Makes scanning VotoSerifGX three times faster. The rest is probably the lang
matching, which can also be shared across named-instances. Upcoming.
This reverts commit 57764e3a36449da25bb829c34cb08c54e9e5de90.
For regular font pattern we don't look into fvar, so it doesn't make sense to
get non-variation from it either.
Old logic was really bad. If you requested weight=102 and got a medium
font (weight=100), it would still enable emboldening...
Adjust it to only embolden if request was >= bold and font was <= regular.
Has two distinctions from FcCompareRange():
1. As best value, it returns query pattern size, even if it's out of font range,
2. Implements semi-closed interval, as that's what OS/2 v5 table defines
If font claims to support range [100,900], and request is for [250], then
return [250] in "rendered" pattern. Previously was returning [100,900].
This is desirable for varfonts weight and width, but probably not for size.
Will roll back size to return request size always, for non-empty ranges.
If "instance-number" part of face id is set to 0x8000, return a pattern
for variable font as a whole. This might have a range for weight, width,
and size.
If no variation is found, NULL is returned.
Not hooked up to FcQueryFaceAll() yet. For now, can be triggered using
fc-query -i 0x80000000
There's nothing assymetrical about how we match them. Previously we "considered"
them half-open because the OS/2 spec had usLowerOpticalPointSize as inclusive
and usUpperOpticalPointSize as exclusive. But we do not respect that.
Note that the parsing code accepts both anyway, because of the way our sscanf()
usage is written...
This is for clients to passthru font variation settings. Modeled
similar to FC_FONT_FEATURES. Each element value is for one axis
settings, eg. "abcd=2.3" where 'abcd' is the OpenType Font Variations
axis tag.
Needs docs update.
Behdad Esfahbod
Bastien Nocera
Akira TAGOH