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

[Hin-Tak Leung]

 I would probably say ligature, italic and bold, and others which changes the spacing/advance width of a glyph, is perhaps abusing the unicode variation selector mechanism a bit. Those go into gsub, stylistic sets etc.
Colour and other non-spacing-changing purpose is an interesting use - for example, I can quite see it being used for Arabic tashkil's: those have the fonts which supports it, display Arabic with colored tashkil's.
That said, I think John's comment about it being an index in a vendor's PUA, and somewhat font vendor specific, and perhaps even font version specific (ie. the font vendor decides to re-order the selectors in a font upgrade) is a bit problematic. That means the font vendor needs to ship a release note per font release detailing what is and what is not available, and where in the code space?
So it is quite difficult to think of a index into 256+ glyph variants of a character.
As a side note, I think the whole traditional Chinese and simplified Chinese division should have been dealt with via something like this. Ie. Traditional/Simplified Chinese differ by glyh shape, not by meaning of the characters, but that ship has sailed decades ago :-).

    On Saturday 22 June 2024 at 14:47:36 BST, William_J_G Overington <wjgo_10009 at btinternet.com> wrote:  
 
 
John Hudson wrote

 

> Unless you are anticipating 256 variations of a single character needing to be captured in plain text, ...

 

I am anticipating the possibility that once this feature becomes available that new ways of carrying out research may become developed.

 

For example, there was research on the Gutenberg Bible where glyphs for a letter are not precisely the same and it is thought that Gutenberg used a one-cast matrix system. I have wondered if that is the case, would using many ligatures be a cost saving practice? I have further wondered if there were unsuspected virtual ligatures such as pi and pl and so on made, two unconnected glyphs on the same piece of metal type.

 

Unicode has 256 official Variation Selectors available, some in plane 0, most in plane 14, so the same for the user-defined variation selectors seems reasonable to me.

 

Unicode traditionally uses blocks of 256 code points, so it seems to me that 256 user-defined variation selectors is a good idea.

 

The history of information technology has examples of where a decision over what was necessary was later changed.

 

Around 1980 it was decided that two digits was enough to specify a year. By the mid 1990s lots of software needed to be altered, at great cost and effort, as the year 2000 approached. If only four digits had been used from the start.

 

Here is a link to the Unicode roadmap page for plane 14.

 

https://www.unicode.org/roadmaps/ssp/

 

Having 256 user-defined variation selectors would be a row full. If fewer than 256 are encoded, would the rest of the row ever be used for something else?

 

Once these user-defined variation selectors are implemented then they may well be used in ways not in the proposal.

 

It would be possible to encode in plain text, each of italic glyphs, bold glyphs, bold italic glyphs, titling font glyphs (that is larger capital letters on the same point size body), Black Letter glyphs, red glyphs, and so on, all with a graceful fallback..
 

There is a famous print of the famous This is a Printing Office text where most of the text is printed in black ink and one line is printed in red ink.

 

With these User-Defined Variation Selectors that text could now be typeset in plain text such that with an appropriate font the red lettering would be displayed yet with a graceful fallback if the text were displayed other than with such a font.

 

William Overington

 

Saturday 22 June 2024

 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240622/bc201b32/attachment.htm>