[MPEG-OTSPEC] Does a rendering system know if a variation selector requested glyph is not available in a font?

[William_J_G Overington]

There is a document
 
(R)Unicode: Encoding and Sustainability Issues in Runology
 
https://www.unicode.org/L2/L2024/24129-runology.pdf
 
I have no expertise at all in Runology but I did notice one thing in the 
document that has prompted me to make an observation.
 
On page 14 the document has the following.
 
> Fonts supporting that form would display the appropriate glyph, 
> recognising the string of base-character + variation selector, but 
> fonts without such support would ignore the variation selector and 
> fall back to a generic form for the base character.
 
I suggest that it would be possible to have a version of the program 
that displays the glyphs to be such that if the fall back glyph is 
displayed due to the requested glyph not being available in the font, 
then that fall back glyph could be displayed in, say, red, or some other 
way, so that it would be clear that that was the situation rather than 
it being just an unreported fallback situation. Is that possible with 
fonts and rendering systems as they are now?
 
So it would not be a situation of the variation selector request being 
ignored, but a situation of the variation selector request not being 
acted upon yet a notification that the request had not been acted upon 
notified to the researcher.
 
I appreciate that this would not be a feature requiring encoding in 
Unicode, but would involve the font and the rendering system. So how 
could this be implemented please, indeed are there any programs that 
already implement such a feature? If the font returns the default glyph 
when asked for the variation sequence requested glyph, does the 
rendering system know that this is the case? If so, how? If not, can a 
feature be added to the font specification so that the rendering system 
will know please?
 
I am thinking that such a feature could b useful in various situations, 
not only runology.
 
William Overington
Friday 7 June 2024
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240607/c0ad2c1e/attachment-0001.htm>