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

[Ken Lunde]

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
>