[OpenType] Proposed new language tag: ZHM (Chinese, Macao SAR)

Peter Constable petercon at microsoft.com
Fri Dec 21 08:33:03 CET 2018


If a tag is to be registered for this, I recommend that it use four letters, not three — e.g., “ZHTM”.

Requests may come for a tag to differentiate typography for a particular _language_ from that of other languages. Where there isn’t a conflict, the most sensible choice of tag in that case would be to use the ISO 639-3 ID appended with a space. “zhm” isn’t currently assigned in ISO 639, but it could get assigned at some point. If that were to happen, it would not be for “Traditional Chinese as used in Macao” since that isn’t a language; it’s a typographic variant of an orthography for one or possibly more languages as used in a particular region. So, “ZHM ” would create risk of future conflict; a four-letter tag such as “ZHTM” would avoid any such risk.

I recognize that this would differ from the precedents of “ZHH”, “ZHS” and “ZHT”, but those were less-than-optimal choices for tags for the same reasons given here. There’s no benefit from adding to risk just for the sake of following earlier decisions.


Peter

From: mpeg-OTspec at yahoogroups.com <mpeg-OTspec at yahoogroups.com> On Behalf Of Ken Lunde lunde at adobe.com [mpeg-OTspec]
Sent: Monday, December 3, 2018 10:31 AM
To: opentype-list at indx.co.uk; mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Re: [OpenType] Proposed new language tag: ZHM (Chinese, Macao SAR)



Eric,

Macao SAR is currently preparing such documentation, in the form of their forthcoming MSCS (Macao Supplementary Character Set) character set standard. IRG N2281, which is their Activity Report for IRG #50, provides a bit of background:

http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg50/IRGN2281_MacaoActivityReport.pdf<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fappsrv.cse.cuhk.edu.hk%2F~irg%2Firg%2Firg50%2FIRGN2281_MacaoActivityReport.pdf&data=02%7C01%7Cpetercon%40microsoft.com%7C8f66c0d878c64a61229e08d659506370%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636794599143340029&sdata=lkNG24jv0TOxiEvayfENcBnRqFNUHsRhe47QJQvI4%2Fg%3D&reserved=0>

In the case of ZHT and ZHH (introduced in Version 1.5), while both are considered to be Traditional Chinese, the official conventions are different, which leads to different glyphs for a non-trivial number of ideographs. ZHH uses a very large number of forms that are the same as ZHT, some that are the same as ZHS, and even a few that are the same as JAN. And, some forms are unique to ZHH. The same would be true for ZHM.

Speaking from a regional standards point-of-view, MSCS (ZHM) is expected to share a lot of forms with HKSCS (ZHH), but some will be different, and possibly shared with CNS 11643 (ZHT). A known example is the 女 component when used on the left side of an ideograph. Instead of following HKSCS, MSCS will follow CNS 11643. See the attached code chart excerpt for U+597B 奻. When Macao SAR submits their horizontal extension that is based on MSCS, the M-Source representative glyph will be the same as the T-Source one. Other components are likely to be affected in the same way.

Regards...

-- Ken


On Dec 2, 2018, at 10:25 AM, Eric Muller via OpenType <opentype-listmaster at indx.co.uk<mailto:listmaster at indx.co.uk>> wrote:

Message from OpenType list:


On 12/2/2018 6:57 AM, Ken Lunde via OpenType wrote:

there are enough differences to warrant a new language tag.

Just curious: Is there some documentation of those differences? I
suppose the bulk of the differences are glyph shapes, but is there
anything else?

Thanks,
Eric.

[cid:4CA7C5F9-7D7F-490F-83AC-26C3FF4B8725 at corp.adobe.com]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20181221/db5668f0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 323 bytes
Desc: image001.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20181221/db5668f0/attachment.bin>


More information about the mpeg-otspec mailing list