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

[Hin-Tak Leung]

 Hi Ken,
Apologies, I double-checked - I think you are right about them being more or less in sync. For some reasons I seem to have the mistaken impression that that one is v2... the other v4 and with widely different release dates. Some of the other Adobe Source non-Hans seems to be indeed at v4...
As for the sub-optimal claim, I just meant minimal in terms of numbers of references to distinct glyph shapes (and minimal table size). Reading UTS #37 properly, I see that this is very much not the case, and as you said, as the number of UVSes increase, the number of registered collections increases. Or rather, the other way round: as the number of UVSes increase AS A CONSEQUENCE OF more registered collections, there will be partially overlapping collections, and redundancies / duplicated references to exact same shape across different collections, and they will take up more variant selector slots with the same glyph shapes.
In fact, if I read UTS #37 correctly (sorry this sounds like asking the author to explain the subtlety/intention/clarification - I see you wrote UTS #37) , as a hypothetical scenario, it is entirely possible for a later version of a font having no new glyphs compared to an earlier version, but just a much larger uvs cmap. And it seems to imply that a (specific versioned instance of) uvs cmap should have a corresponding (specific versioned instance of) IVD_Collections + IVD Sequences?
Put it in simpler terms, the "suboptimal" claim about the current construction of Adobe Hans - to get around it, a vendor - say, Google - could register a "web font usage uvs collection" with exactly one IVS per distinct glyph, and ship a font that does not support any other collections?
Hidden in there, is the idea that the current Adobe Hans must have a (versioned) list of (versioned) IVS collections it claims to support - and it should be possible to check the implementation of a uvs cmap against that text-based list?
I hope this is not too tedious a discussion...
Regards Hin-Tak


    On Monday 15 July 2024 at 04:51:59 BST, Ken Lunde <lunde at unicode.org> wrote:  
 
 Hin-Tak,

Apologies for the delay in replying. I spent the last week working on Unicode- and IRG-related matters.

I just compared the Format 14 'cmap' subtables of the latest Source Han Sans (Version 2.004) and Source Han Serif (Version 2.002) fonts, and they are "pretty much" in sync. (I developed tools for doing such a comparison.) I found only four differences, which were attributed to whether the sequences are "default" or "non-default," which may actually be a bug. That is no longer my problem, but I can still confidently state that that their UVSes are "pretty much" in sync.

I am, however, curious about your "suboptimal" claims. I suspect that the Format 14 'cmap' subtable itself may be suboptimal, as the "IVS Test" project sort of demonstrates, given the sheer size of its 'cmap' table. As the number of UVSes increases, the optimization decreases, or rather, the fact that it is suboptimal becomes more apparent.

Regards...

-- Ken

> On Jun 29, 2024, at 19:03, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:
> 
> 
> 
> On Friday 28 June 2024 at 06:12:44 BST, Ken Lunde <lunde at unicode.org> wrote: 
> 
> 
> > Hin-Tak,
> 
> > For better or worse, I am effectively the caretaker of the history of much of the CJK-related type activities that took place at Adobe over the last 30+ years, to include the development of the Source Han and Noto CJK Pan-CJK typefaces, which are clones of one another.
> 
> > About the observations that you made, particularly about the lookup of UVSes in Source Han being suboptimal, that was intentional. While I have been the IVD Registrar since May of 2011, the registration of virtually all Adobe-Japan1 IVSes was performed by my former Adobe colleague, Eric Muller. I suspect that your observation is about the Variation Selector that is associated with what is deemed the default UVS, meaning that the Format 14 'cmap' subtable defers to the Format 12 (or 4) 'cmap' subtable for the GID. When the first -- and by far, largest -- batch of Adobe-Japan1 IVS were registered in the IVD, it was intentional that the lowest -- by code point order -- Variation Selector was not associated with the UVS that is considered the default (aka encoded) one. This was purposefully done so that implementations would not make such an assumption.
> 
> > BTW, you may be interested in the "IVS Test" project that I started while at Adobe:
> 
> > https://github.com/adobe-fonts/ivs-test/
> 
> Thanks Ken, for the anecdotes about the development history. I am aware that technical decisions are often made not entirely based on technical considerations. It may not even be optimal at the time, and certainly not on hindsight. It is always interesting to learn how "oddities" come to be.
> 
> It makes a lot of sense to intentionally NOT to associate the lowest variation selector with the default. Technologically it is redundant (one can save one code point by just "spec it out" and remove it and gain the use of one empty slot). A lot of parties are going to argue that they want their favourite as default so "default" in this case is a political minefield too.
> 
> I was curious about the non-optimalness of the format 14 cmap on Adobe Sources Hans Sans, and wonder if they are sync with the Serif font. I.e. two glyph shapes can be non-degenerate and different in the serif font (e.g. a brush stroke tapering from top right to bottom left, vs the reverse tapering from bottom left to top right - they become identical in the Sans font). But I found that the serif font has an entirely different versioning and release schedule. While its UVS table feels more optimal, no conclusion could be drawn from its relationship with the Sans font. There is probably another interesting story there.
> 
> Thanks for the URL for the ivs-test - looks to be an interesting "stress test" benchmarking sample for performance in related software/ code path!
> 
> Regards,
> Hin-Tak
> 

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