Showing posts with label UTC #180. Show all posts
Showing posts with label UTC #180. Show all posts

Tuesday, August 27, 2024

Highlights from Unicode Technical Meeting #180

by Peter Constable, UTC Chair

Unicode Technical Committee (UTC) meeting #180 was held July 23 – 25 in Redmond, Washington, hosted by Microsoft. Here are some highlights.

Finalizing Unicode 16.0

One priority was to finalize technical decisions for Unicode 16.0 in preparation for a September 10 release. Beta feedback and a small number of new proposals were considered and various decisions affecting 16.0 were taken. Regarding the set of encoded characters and emoji sequences for Unicode 16.0, no changes were made from the Beta.

Unicode 16.0 will include major additions and improvements for Egyptian Hieroglyphs, most of which were already included in the Beta. One aspect of the improvements is a refinement in the encoding model for rotational variants using variation sequences. Since the Beta, it was recognized that ten of the Egyptian Hieroglyph encoded as characters in Unicode 5.2 would be better represented using rotational variation sequences. This led to some new UTC decisions affecting the 16.0 release:
  • Ten standardized variation sequences for Egyptian Hieroglyph rotational variants were added, while one standardized variation sequence that had been added in Unicode 15.0 was rescinded.
  • In the Unikemet.txt data file with Egyptian Hieroglyph properties, the kEH_Core property has been changed from a binary property to having an enumeration of values, one of which is “L(egacy)” indicating characters encoded in Unicode 5.2 that are not part of the core set and are not expected to be supported in fonts.
Another significant change affecting the 16.0 release is a glyph change for U+0620 ARABIC LETTER KASHMIRI YEH, and a change to its joining group in ArabicShaping.txt (180-C23, 180-C24). This affects not only the glyph shown in the code chart, but also the positional forms shown in the Arabic section of the core spec. The need for this arose from incorrect information in the core spec resulting in fonts that don’t provide a final form that matches users’ expectations. See L2/24-152 for background details.

While no further changes were made to the set of emoji in Unicode 16.0, a change will be made in how emoji characters are displayed in the code charts. The technology used to produce the chart pages is not able to display full-color emoji, and up to now the code charts have not made it clear when pictographic symbols have the Emoji property. In Unicode 16.0, characters with the Emoji property will be indicated in the code charts with a small triangular badge in the top left corner of the cell. A white triangle will indicate an emoji character that should have default emoji (full color) presentation:

A black and white sign with a clock
A black triangle will indicate an emoji character that should have default text (monochrome) presentation:

A rectangular sign with a grid and numbers
The script descriptions in the core spec are used to provide background information on each script as well as information to guide implementations. For many scripts, it has been a challenge to provide comprehensive guidance for implementations, particularly when there are complex rendering requirements. However, some implementers have written Unicode Technical Notes providing guidance for implementation of a particular script. Although these are not normative specifications approved by UTC, they can still be valuable information conducive to interoperable implementations. For Unicode 16.0, UTC decided to have two existing UTNs referenced within the core spec sections for the respective scripts:
As mentioned for the Beta, the core spec for Unicode 16.0 will be published as per-chapter HTML pages.

Characters for future versions

At UTC #180, code points were provisionally assigned for 1,063 new characters, including 38 Arabic characters, 45 characters for phonetic transcription, and 965 ideographs and radicals for Jurchen script. With these characters in the pipeline, work can get started on property data, charts, and other content that will be needed for them to be encoded in a future version of the standard.

Some initial decisions were also taken on the character additions for Unicode 17.0: as IRG had finalized its recommendations for CJK Unified Ideographs Extension J, that block of 4,300 new ideographs has been approved for encoding in Unicode 17.0.

Also, a proposal was approved to disunify one existing CJK unified ideograph character, U+5CC0 in Unicode 17.0. When U+5CC0 was encoded in Unicode 1.1, it was deemed that two similar ideographs should be unified. The proposal demonstrated that this unification should not have been made, and that was confirmed earlier this year by IRG. The changes for 17.0 will include encoding of a new character, U+2B73A, and revision of the source references for 5CC0, 2B73A and 2F879. A complication in this case is that ideographic variation sequences for the two distinct glyphs have been registered for use in Japan. No changes in “J” source references will be made, and it is not expected that implementations for Japanese will be affected. For additional information, see section 7 of L2/24-165.

Variation sequences and historic scripts

People working with historic scripts often deal with glyph variations. Variation sequences seem like an appropriate encoding mechanism to use in such cases, though asking UTC to standardize variation sequences for many historic variations could seem like a challenge. With that in mind, a proposal was presented to encode a block of additional "user-defined" variation selector characters. These would be additional PUA characters with a constraint that they would only be used as variation selectors.

That proposed solution is problematic: existing stability policies and commitments prevent assigning more PUA code points and also prevent constraining existing PUA for certain uses. At the same time, there was opinion within UTC that the need expressed was reasonable, and there was openness to considering alternative solutions. One potential alternative that gained some interest was to establish a registration process, similar to what is defined in UTS #37 for ideographic variation sequences but intended for use with historic scripts.

For complete details on outcomes from UTC #180, see the draft minutes.


Adopt a Character and Support Unicode’s Mission

Looking to give that special someone a special something?
Or maybe something to treat yourself?
🕉️💗🏎️🐨🔥🚀爱₿♜🍀

Adopt a character or emoji to give it the attention it deserves, while also supporting Unicode’s mission to ensure everyone can communicate in their own languages across all devices.

Each adoption includes a digital badge and certificate that you can proudly display!

Have fun and support a good cause

You can also donate funds or gift stock


As Unicode, Inc. is a US-based open source, open standards, non-profit, 501(c)3 organization, your contribution may be eligible for a tax deduction. Please consult with a tax advisor for details.
 
  翻译: