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

Wed Jun 19 22:48:13 CEST 2024

 It just so happened that somebody (likely one of the people lurking in this list, or parties closely associated with one) requested some addition to freetype-py - the python binding to FreeType - towards such a goal.

Basically the requester asked that it should be possible to via freetype-py to retrieve the character + variant-selector -> glyph id mapping .

So in the submitted example, this is one such result - the first number is just the character (without variant selector)'s glyph id, then followed by appending with 15 different variant selectors, with Source Han Sans:

40593|62913|62914|62915|62916|62917|62918|62919|62920|62921|62922|62923|62924|62925|62926|40593

Note that the last one is identical to without.

equivalent answer can be retrieved via harfbuzz and fonttools. So it is relatively simple just to check if character + variant selector looks up to be the same id as without, to highlight that mapping for that selector is missing.

#195/#196 on freetype-py's github tracker for those who want to know.

My role in this was mainly just to approve the suggested code addition and examples , so I am not familiar with this area on the "context/history" side - I think it would be nice to have names/annotations for the variant selectors, e.g. "region" "historical forms", but that's unlikely the case? John's comment about more additional variants seems to corroborate that - the numbering / additon of variant selectors is a bit ad-hoc?
     On Friday 7 June 2024 at 16:29:08 BST, John Hudson via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  

The font wouldn’t need to do anything special in this scenario. The behaviour you describe is the sort of thing that is usually found at the application level, which is where text highlighting/colouring takes place, in concert with the shaping engine. It seems easy enough to do: check for presence of variation selector sequences, check for format 14 cmap mappings for those sequences in the current font, highlight any sequences without mappings.

[In the context of the runology queries, I don’t think variation selectors are the best solution. There are similar issues in the study of historical texts in many writing systems, and the set of variants is usually too large and too open-ended to be suitable for Unicode’s strict definition of variation selector forms. The current version of the Brill Epichoric font, for instance, includes 31 forms of Alpha—not including RTL boustrophedon variants and stoichidon spacing forms—and it only takes discovery and publication of one more inscription to introduce one or more additional variants.]

JH

 On 2024-06-07 4:11 am, William_J_G Overington via mpeg-otspec wrote:

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

  _______________________________________________mpeg-otspec mailing listmpeg-otspec at lists.aau.athttps://lists.aau.at/mailman/listinfo/mpeg-otspec -- John HudsonTiro Typeworks Ltd    www.tiro.comTiro Typeworks is physically located on islands in the Salish Sea, on the traditional territory of the Snuneymuxw and Penelakut First Nations.__________EMAIL HOURIn the interests of productivity, I am only dealing with email towards the end of the day, typically between 4PM and 5PM. If you need to contact me more urgently, please use other means. _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240619/4122f5e9/attachment-0001.htm>