<html><head></head><body><div class="ydp1e0a450yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div>Hi Vlad. Thanks for the update.</div><div><br></div><div>Firstly, a small correction - "braking changes" surely that is "breaking changes"?</div><div><br></div><div>I am reading claims of size-benefits of proposed changes quite carefully, and quite skeptical of them in general.</div><div><br></div><div>The claims about composite usage in hangul and CJK is really limited to optimal/stylistic usage scenarios with Hei/San styles, really, and perhaps put quite severe constraints on both the style (not plural) in heavily composite-oriented design based approach, and also the actual day-to-day design work-flow. Worst case: you see styles coming out looking like those from B-movies with Fu Manchu as the villain from the 60's. That reminds me of the work of a famous artist called Xu Bing - one of the things he is famous for, is writing English phrases/slogans in chinese-calligraphic-style composite glyphs. What it sounds like is the reverse - losing all the calligraphic tradition of the far east and recommending/forcing hangul/CJK into a San style.</div><div><br></div><div>The other size claim is about the possibility of sharing data between old glyf and new GLY2(?). otf tables have alignment and checksum requirements, so that would mean contiguous-ness of the old subset, and possibly padding (and also a 1 to 3(?) byte padding break between old subset and new) complications. Some of the details are certainly behind closed-source implementations, but I believe there are non-overlapping-ness checks in various font checking schemes / tools, both stand-alone and built into OSes too: ie valid tables are taken as non-overlapping, and overlapping tables indicate broken fonts. That will need to change/specified/excepted if glyf and GLYX/GLY2(?) is to share content.</div><div><br></div><div>I can continue my rant on size claims regarding SVG vs COLRv1, and quadratic vs cubic too. Poorly written SVG is poor, and qudratics not using implicit on-curves points are larger. Claims about being better than poor SVG and better than poor quadratics, size-wise, are meaningless.</div><div><br></div><div>So I'd prefer to see those size-related claims removed, if not heavily qualified/caveated.</div><div><br></div>
<div id="ydp1e0a450yahoo_quoted_7931318565" class="ydp1e0a450yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Sunday, 15 October 2023 at 11:06:57 BST, Vladimir Levantovsky <vladimir.levantovsky@gmail.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="ydp1e0a450yiv5976629584"><div dir="ltr">Dear all,<br><div><br></div><div>Please see attached the text of the AHG report I plan to present tomorrow during the opening SC29/WG meeting Plenary. This report is based on the AHG meeting summaries that were previously distributed on this list.</div><div>If you have any comments, please send them by the end of the day today.</div><div><br></div><div>Thank you,</div><div>Vladimir</div><div><br></div></div>
</div>_______________________________________________<br>mpeg-otspec mailing list<br><a href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow" target="_blank">mpeg-otspec@lists.aau.at</a><br><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="nofollow" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br></div>
</div>
</div></div></body></html>