Unicode: Difference between revisions

Content deleted Content added
No edit summary
→‎Concerns: per jan Lepeka: "Unicode hates gaps; they know what you're trying to pull when you do that"
Tag: 2017 source edit
 
(One intermediate revision by one other user not shown)
Line 12:
 
==Proposals==
There are have been a few past proposals for thea {{tp|sitelen pona}} Unicode block. In 2021, shortly after the publishingpublication of the {{lipu ku|en}}, Gabriel Tellez submitted a proposal, consisting only of the glyph chart for {{tp|[[linja pona]]}}.<ref>{{cite web|url=https://www.unicode.org/L2/L2021/21137-toki-pona.pdf|title=Toki Pona for Unicode|website=The Unicode Consortium|author=Gabriel Tellez|date=2021|access-date=2024-01-29}}</ref> It was rejected by the {{w|Script Ad Hoc Group}} in its recommendation.<ref>{{cite web|url=https://www.unicode.org/L2/L2021/21130-script-adhoc-rept.pdf|title=Recommendations to UTC #168 July 2021 on Script Proposals|website=The Unicode Consortium|author=Deborah Anderson, Ken Whistler, Roozbeh Pournader, Liang Ha|date=2021-07-26|access-date=2024-01-29}}</ref> As of January 2024, there is undergoing work for a proposal for {{tp|sitelen pona}}, cowritten by [[Under-ConScript Unicode Registry]] maintainer [[Rebecca Bettencourt]] and many important figures in the Toki Pona [[community]].<ref>{{cite YouTube|id=W3I_x_rpwc8|title=nasin Juniko | toki lili pi mun #15|lang=tok|author={{tok|jan Kekan San}}|channel=Toki Pona VR|handle=TokiPonaVR|date=2024-01-24|access-date=2024-01-29}}</ref> A preliminary proposal was submitted on 16 April 2024.
 
{{tp|sitelen sitelen}} does not seem to be under consideration, as it has far fewer users<ref>{{cite web|url=https://tokiponacensus.github.io/results2022|title=Results of the 2022 Toki Pona census|website=[[Toki Pona census]]|published=GitHub|author={{tok|jan Tamalu}}|date=2022-10-03|access-date=2024-01-29}}</ref> and lacks font implementation of its nonlinear writing direction. Additionally, there is currently little existing architecture for scripts similar to {{tp|sitelen sitelen}}, such as {{w|Mayan hieroglyphs}}.
Line 35:
(And as for which {{tok|nimi sin}} to add to the Extended block, I think for the time being we could add any word that any fontmaker wants to support in their font. Once SP font making becomes more common, perhaps when 2 or 3 font makers promise to add it to a font, or something like that.)
</blockquote></ref> This would come at the expense of complicating the encoding situation rather than submitting one proposal and being done with it.
*'''Commerciality'''. While the [[Toki Pona logo|Toki Pona "logo"]] {{sp|toki-pona}} would not receive its own codepoint, it occurs as part of {{tp|sitelen pona}} {{sp|[[pu]]}}. Moreover, {{sp|pu}} and {{sp|[[ku]]}} refer to and graphically represent commercial products that are not fully in the public domain. If this is an issue, an idea is to reserve the codepoints for these glyphs, not officially defining them, but allowing ''de facto'' use. Otherwise, fonts would have to create workarounds to encode them, which may create another standardization problem.
 
==References==