<html><head></head><body><div class="ydp8eebb2f2yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div><br></div><div><br></div>
<div id="ydp8eebb2f2yahoo_quoted_0211056357" class="ydp8eebb2f2yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Friday 28 June 2024 at 06:12:44 BST, Ken Lunde <lunde@unicode.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">> Hin-Tak,<br clear="none"><br clear="none">> 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.<br clear="none"><br clear="none">> 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.<br clear="none"><br clear="none">> BTW, you may be interested in the "IVS Test" project that I started while at Adobe:<br clear="none"><br clear="none">> <a shape="rect" href="https://github.com/adobe-fonts/ivs-test/" rel="nofollow" target="_blank">https://github.com/adobe-fonts/ivs-test/</a><br clear="none"><br clear="none">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">Thanks for the URL for the ivs-test - looks to be an interesting "stress test" benchmarking sample for performance in related software/ code path!</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Hin-Tak</div><div dir="ltr"><div class="ydp8eebb2f2yqt3819255734" id="ydp8eebb2f2yqtfd41662"><br clear="none"></div></div></div>
</div>
</div></div></body></html>