Add UnicodeRange for font query #377
Conversation
|
The test input from #371; also some Hebrew characters: Font matchesNote here that |
|
Hmm... I believe that for CSS matching we need support for arbitrary numeric ranges (not just "standard ranges") specified as part of the FontInfoOverride. See https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range. So perhaps it would make sense to have some variant on Reading this PR it looks like the 128 standard ranges thing is part of an OpenType standard? So I guess we may still need that code (not my area of expertise), although presumably one can also check which codepoints a font actually supports? |
Yes, of course. That's largely orthogonal to this PR. I had assumed that Parley would already do this, but maybe not; this may be why The way this works in
This is per- Using this PR without per- The second (missing) part of this PR would help by providing some likely font matches when no suitable fonts are found otherwise. E.g. if someone uses an arrow then the family won't identify a suitable font (though some contain a few common arrow glyphs anyway) and the script ("common") won't either, but the
Hmm, For fonts found on the system, I think we normally only have the info from the OS/2 table. The other reason I chose to precisely mirror the OS/2 specification is because of how I guess there are other possible approaches; e.g. building a (very large) map from I'm not sure if you want to copy the approach I've adopted for I would like this to be adopted by |
|
Combined with #378 (which effectively just massively increases the number of font matches), this PR is effectively a fast pre-filter for callbacks. E.g. with this PR, matching for a font supporting Hebrew ( That is because the |
I am understanding correctly that the invariant this PR is relying on / taking advantage of is "If a font doesn't list a 'standard unicode range' then it doesn't contain any glyphs for any codepoints within that range"? If a font does support a given "standard range" then we then still need to check whether the font actually contain the specific glyph we are looking for but this allows for fast-rejecting when a font doesn't cover a given "standard range"? |
|
Honestly, the only specification I found for behaviour is this one:
I fully expect that there are some But does that matter? Lets consider
The latter point can be addressed by changing how glyph fallback works: instead of checking one long list of fonts, use at least two: a pre-filtered list of preferred fonts (possibly also using Related questions:
Conclusion: we likely still want |
|
Note that fonts often “lie” about |
This is a partial solution to #371.
My testing shows improvements; e.g. that arrows now use the most appropriate font instead of the first which happens to contain a match (this makes styles much more consistent).
enum UnicodeRange. New code because I couldn't find an appropriate impl oncrates.io(though there are some things touching on this in ttf_parser and in read-fonts).struct UnicodeRangesQueryby matching rangesThe missing part (last item) is to add a second-stage fallback (all fonts functional over the range) for when there are no matches. This is not quite so straightforward since
Collectiondoesn't have a function to list all available families; I'd like some guidance on the best way to do this within fontique. ShouldQuery::matches_withautomatically do this when it has no other matches, or should it be up to the caller to call something else likeQuery::all_fonts_for_range(range: UnicodeRange)in this case?Parley changes are needed to use this.
kas-textis updated here: kas-gui/kas-text#97.