L2/23-080R

Editorial Committee Report and Recommendations for UTC #175 Meeting

Source: Editorial Committee

Date: May 5, 2023 (revised)

A. Unicode Release Topics

A1. Unicode 15.1.0 Report

FYI: The Editorial Committee's participation in Unicode 15.1 is relatively limited, because no publication of the core specification is planned for 15.1. The Editorial Committee has been doing some limited editorial review of UAXes and UTSes which will be revised during the 15.1 release cycle. This work will ramp up during the beta review period, after the April UTC meeting.


A1. Unicode 16.0.0 Report

FYI: The Editorial Committee is continuing review of new content planned for the eventual 16.0 publication of the core specification. In particular, contributing editors have started to deliver drafts of sections for new scripts that we anticipate will be published in 16.0. To date, we have rolled in reviewed draft sections for the following new scripts. (Section numbers are as they will appear in the revised new 16.0 text.)

Still pending are drafts for the following new scripts:

Contributing editors are working on drafts for those three scripts, drawing upon the proposal documents for content.

There is also ongoing work to do routine upkeep of the core specification and to stay current with bug reports and other small tweaks to core specification content mandated by the UTC.

In general, the Editorial Committee can assert that we should not have any trouble completing new content for the core specification to cover the current anticipated repertoire for 16.0. The essential challenge for the Editorial Committee for 16.0 is not the new content related to newly assigned repertoire, but rather the overall change in the planned publication format for the 16.0 core specification.


A3. Core Specification Future Development

FYI: The "TUS Future" project continues to be active, meeting approximately twice a month.

The planned architecture continues to be a SvelteKit-based website: contents are authored in Svelte components (a kind of enhanced HTML, similar to JSX), then static web pages are generated at compile time for deployment and archiving. A single archival PDF is planned for 16.0, and will be generated from the web pages.

With the prototype site in place, Liang Hai's development work has slowed down, waiting for the other participants to discuss and collectively make some architectural decisions. The current focus is on deciding how to expose URLs to various content locations and maintain certain stability of the URLs.


B. Website Topics

B1. Website Content Maintenance

FYI: The Editorial Committee continues to provide minor maintenance of pages on the Unicode technical website.


B2. FAQ Updating

FYI: The FAQ update project has reached a stage where most of the major revisions to existing items have been accomplished, and all FAQ items are now automatically glossed. There are some pages that could use an update, but the group has not received drafts by people knowledgeable on the issues. Instead, there has been an ongoing stream of minor bug fixes that could be resolved without meetings. We are open to suggested review and update suggestion for any page and will schedule meetings as needed to process them. Reports of problems in existing FAQ pages or suggestions for new FAQ items should be directed to Ben Yang and Asmus Freytag.


C. Editorial Committee Process Issues

FYI: The Editorial Committee continues to meet regularly. Our meetings are now generally held on a biweekly schedule.

This report to the UTC includes feedback from the Editorial Committee meetings held on February 2, February 16, March 2, March 16, March 30, and April 13, 2023.

The Editorial Committee has been innovating in its process, and is now using GitHub repositories, both for its issue tracking (and discussion), and for ongoing editorial maintenance of the core specification.

Public-facing infomation about the Editorial Committee and its work is maintained on the Unicode Editorial Committee page on the website. The Editorial Committee also maintains an internal subsite for use by the committee. People who would like to find out more about the work of the Editorial Committee or contribute to that work should contact the Acting Chair, Ken Whistler.

NOTICE: The Editorial Committee is currently recruiting for a new chair. The expected responsibilities of the chair would include:


D. UTR Topics

FYI: The Editorial Committee has nothing to bring up separately about various UTRs at this time.


E. PRI Topics (and other feedback)

E1. Public Feedback noted in L2/23-078


Date/Time: Mon Feb 06 11:22:42 CST 2023
Name: Danny Anderson
Report Type: Membership Inquiry
Opt Subject: Cross-Reference Addition

Could there be a cross-reference mention of "⪇" (0x2A87) in the Unicode Code Charts 
under the "≨" (0x2268) character? I know that 0x2A87 cross-references 0x2268, but 
not vice versa.

A similar note applies for "⪈" (0x2A88) and "≩" (0x2269).

FYI:The Editorial Committee reviewed this feedback, which is requesting cross-references in the names list from 2268 to 2A87 and from 2269 to 2A88, to balance the cross-references in the other direction. The request seems reasonable, and has already been implemented by the names list editors for 15.1, so no action needs to be recorded.


Date/Time: Fri Feb 17 18:50:30 CST 2023
Name: Liang Hai
Report Type: Error Report
Opt Subject: Core Spec

Cell of column “Code Point and Name” / row “Mongolian variation 
selectors” of Table 4-10, Unusual Properties, on page 194 of the 
Core Spec, version 15.0:

> 180B MONGOLIAN FREE VARIATION SELECTOR ONE
> 180C MONGOLIAN FREE VARIATION SELECTOR TWO
> 180D MONGOLIAN FREE VARIATION SELECTOR THREE
> 180E MONGOLIAN VOWEL SEPARATOR

Requests:

1. U+180E MONGOLIAN VOWEL SEPARATOR (aka, MVS; gc = Cf/Format) should be removed, 
as it’s not a variation selector.

2. The recently U+180F encoded MONGOLIAN FREE VARIATION SELECTOR
FOUR (FVS4) should be added.

FYI: The editorial Committee reviewed this feedback. The error in Table 4-10 does need to be corrected. The editors have already made the fix in the draft file for the 16.0 core specification, so no action item needs to be recorded. Note that in addition to the correction for adding U+180F to the list of the other three Mongolian FVS characters, a separate entry in the table for U+180E, which deserves to be called out for its special formatting behavior in Mongolian.


Date/Time: Thu Mar 16 07:04:29 CDT 2023
Name: Simon Cozens
Report Type: Error Report
Opt Subject: Typo in UTS Figure 11.5

Note: This error has already been fixed in the draft.

In the second example of complex hieroglyph formatting, the character sequence 
given is 1314A, 13433...

U+13433 is EGYPTIAN HIEROGLYPH INSERT AT BOTTOM START, but the intended rendering 
(both in the image and in the symbolic column) is for the vertically-paired signs 
to be inserted at TOP END; 13433 should be replaced by 13434.

FYI: As noted in the feedback report, this error in the core specification has already been addressed in the 16.0 core specification draft, so no new action needs to be recorded for this fix.


E2. Public Feedback noted in PRI #473 (Alpha Review)

Date/Time: Thu Mar 30 14:04:04 CDT 2023
Name: Alexei Chimendez
Report Type: Public Review Issue
Opt Subject: 473

Some minor corrections and suggestions to the text of the Standard. I
understand that the minor release 15.1 will not update the core
specification, so please consider the following comments in anticipation of
the next major release.

1. In §3.6 Combination D56, in the following lines:

> This applies even to default_ignorable characters that are not also combining marks

> (which is both default_ignorable and a combining mark)

the phrases "default_ignorable [characters]" should be "characters with the
property Default_Ignorable_Code_Point", or simply "default ignorable
[characters]" without the underscore.

This definition could also mention the property Join_Control. That property
is already used in the definition of combining character sequences in
UAX #29 (Table 1c).

2. In §3.11 Normalization Forms D104, in the following line:

> Thus, while the correlation between ^\p{ccc=0] and \p{gc=Mn} is close,

the right square bracket should be a right curly bracket.

FYI: The Editorial Committee discussed this feedback.

Re Item 1: After discussion, the Editorial Committee suggested updating the first instance to "default ignorable code points" and the second instance to "Default_Ignorable_Code_Point and a combining mark". This change has already been made in the 16.0 draft, so no action needs to be recorded for the change.

Re Item 2: This typo has already been fixed in the 16.0 draft, so no action needs to be recorded for the change.

Suggested Action:

AI, Rick McGowan, UTC. Respond to Alexei Chimendez, pointing to the resolution in L2/23-080 and thanking him for his feedback on PRI #473. [Thu Mar 30 14:04:04 CDT 2023]

G. Miscellaneous Topics

G1. (None noted)