When glyphs from multiple fonts are mixed, as is reasonably common in mixed-script text, a background drawn behind an inline box is only drawn to fit the first available font. This gives consistent sizing across inline boxes, but might not end up fitting all the text. (This effect will likely be exaggerated by the use of leading-trim.) Do we want a switch to allow the height of an inline box to consider fallback glyphs? (Would we want this to be the default when leading-trim is used?)
It seems undesirable to consider fallback fonts based on which characters are rendered, since that will lead to uneven sizing across different elements that are supposed to be the same, or potentially across different lines of the same element (depending on what the scope of "rendered" is).
But at the same time, it seems like using the metrics of the first choice font isn't always what's wanted.
Using the metrics of all the specified fonts (but not system font fallback and probably not generics) seems likely to be too slow
It doesn't seem like there's an obvious way for an author to specify what they want.
In some cases, my understanding is that developers in some language environments (e.g., Japanese) might specify a Latin font first before a Japanese font, even if the majority of their text is Japanese, because they don't want the Latin glyphs from the Japanese font. I'm not sure if this is still common, though. But if it is, finding some solution here may be important.
When glyphs from multiple fonts are mixed, as is reasonably common in mixed-script text, a background drawn behind an inline box is only drawn to fit the first available font. This gives consistent sizing across inline boxes, but might not end up fitting all the text. (This effect will likely be exaggerated by the use of
leading-trim
.) Do we want a switch to allow the height of an inline box to consider fallback glyphs? (Would we want this to be the default whenleading-trim
is used?)