Re: Thoughts on upsizing Unicode
stgiga via Unicode <[email protected]> Tue, 07 Apr 2026 09:42:17 +0200
| Newsgroups | gmane.text.unicode.general |
|---|---|
| Organization | St. GIGA Movement |
| Message-ID | <[email protected]> |
--=_129065804e042023df3260c24ae83c3d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed The X-Face headers from the previous version of this message have been removed, and the message follows: I think that Rebecca's idea is good, if sectioning off part of Plane 14 as surrogates isn't viable, though Rebecca's option would be equally minimally-invasive. Personally, extending Unicode is all well and good (having said that, if the Unicode 18 Alpha repertoire holds true, UnifontEX will hit exactly 65535 glyphs in the Unicode 18 release, which will be released after Unicode 19 drops so that upstream Unifont doesn't immediately obsolete the 18.0 version I use. Ultimately, I'd be involved in Unicode matters more formally long after I finish this, either doing stuff to BWTC32Key [data storage in UTF16 made of hacky teenage JavaScript], or using currently-nonexistent tools that use HarfBuzz beyond-64k extensions to go beyond Unicode 18 for Plane 0 and Unicode 11 for Plane 1 [highest versions that fit] outside of BDF and iOS Safari SVG webfonts from 2010, which are infinite glyph counts. Put simply, even after I have less to do with Unicode, ironically past that point I may get more involved even though it would not affect me in the least until I can evergreen-generate UnifontEX2 builds every Unifont release) in spite of it being something that I have no involvement with. We'll see how stuff goes. Best Wishes, stgiga --=_129065804e042023df3260c24ae83c3d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen= eva,sans-serif'> <p>The X-Face headers from the previous version of this message have been r= emoved, and the message follows: </p> <p>I think that Rebecca's idea is good, if sectioning off part of Plane 14 = as surrogates isn't viable, though Rebecca's option would be equally minima= lly-invasive. Personally, extending Unicode is all well and good (having sa= id that, if the Unicode 18 Alpha repertoire holds true, UnifontEX will hit = exactly 65535 glyphs in the Unicode 18 release, which will be released afte= r Unicode 19 drops so that upstream Unifont doesn't immediately obsolete th= e 18.0 version I use. Ultimately, I'd be involved in Unicode matters more f= ormally long after I finish this, either doing stuff to BWTC32Key [data sto= rage in UTF16 made of hacky teenage JavaScript], or using currently-nonexis= tent tools that use HarfBuzz beyond-64k extensions to go beyond Unicode 18 = for Plane 0 and Unicode 11 for Plane 1 [highest versions that fit] outside = of BDF and iOS Safari SVG webfonts from 2010, which are infinite glyph coun= ts. Put simply, even after I have less to do with Unicode, ironically past = that point I may get more involved even though it would not affect me in th= e least until I can evergreen-generate UnifontEX2 builds every Unifont rele= ase) in spite of it being something that I have no involvement with. We'll = see how stuff goes.</p> <p>Best Wishes,<br />stgiga</p> </body></html> --=_129065804e042023df3260c24ae83c3d--