Splitting TWHK into TW & HK

[kenlunde]

I am opening this new issue to indicate how we plan to handle the Traditional Chinese situation as it pertains to TW (Taiwan) versus HK (Hong Kong) usage, and will be closing Issues #6, #17, #18, and #32 because the intention here is to indicate the action that will be taken. Please reference these four closed issues for specific user comments and suggestions.

For those who are interested, the background is that we (Adobe and Google) made a decision to follow the Taiwan MOE glyph standard for Big Five. For better or worse, and mainly for the sake of consistency, we also decided to apply the Taiwan MOE glyph standard to the characters that correspond to Hong Kong SCS. Hong Kong SCS is an add-on to Big Five, so from a particular point of view this makes sense. We very much appreciate the feedback from the community about this, and will attempt to remedy the issue, though it may take some time and effort.

We are targeting late August to release the first major update to Source Han Sans (and the Google-branded Noto Sans CJK) that will address most of the issues that have been reported and confirmed as bugs. Below is the current plan for addressing the HK issue:

First, all instances of TWHK will be changed to simply TW, but the glyphs will remain the same (other than any corrections). In other words, the character code coverage will still be Big Five and Hong Kong SCS, and in a way that still follows the Taiwan MOE glyph standard. Note that most of the Hong Kong SCS characters also correspond to CNS 11643 characters, in Plane 3 and beyond. The Traditional Chinese (TW) subset OTFs may be changed in that the HK-specific glyphs are removed. This has not yet been decided.

Second, experimental HK subset OTFs and HK font instances (OTC) will be added, which will attempt to address the community concerns by repurposing existing glyphs to the extent that is possible.

Lastly, about the suggestion to use Kangxi Dictionary–style glyphs, doing so is beyond the scope of this project. One particular difficulty of implementing such glyphs is that there is no Sans Serif (黑体/黑體) typeface design reference or standard.

[kenlunde]

The earliest would be closer to the end of this year. A lot of planning is involved.

[kenlunde]

In order to guard against stale URLs, I am making the Hong Kong Glyph Guidelines PDF file available here.

[orangeparanoid]

@kenlunde As in http://blogs.adobe.com/CCJKType/2015/08/irg44.html , is there any plan to follow: IRG N2074: http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg44/IRGN2074.pdf ?

I reviewed some HKSCS characters and found Simplified Chinese characters (rarely / never used in Hong Kong newspaper, e.g. 见 HKSCS：8BE5. 見 is the usual form in Hong Kong). Will such Simplified Chinese characters be included in Source Han Sans HK? Both 见 and 見 in the same HK font?

[kenlunde]

@orangeparanoid: As stated in that blog article, One reason for my interest is that I plan to support HKCS 2015 in the Source Han Sans Version 2.000 glyph set, which effectively means that Version 2.000 development is effectively on hold until HKCS 2015 has been finalized.

One of the problems with HKSCS is that it implicitly included Big Five as part of its scope. The main problem with that was that there was no way to specify the HK form of a character that is included in Big Five. That will change with HKCS. Also, the fact that 见 is included in HKSCS (and likely in HKCS) doesn't mean that 見 will be excluded, because it is include in Big Five.

[RyanChng]

Just wondering, to what extent would Pingfang HK be useful as a design reference? (Given that we have no other Heiti style reference for HK as far as I know of.)

[kenlunde]

@RyanChng: I barely trust standards (because I have found plenty of errors in both regional and international standards), which necessarily serve as primary references, and I have even less trust in fonts. With that being said, PingFang HK may serve as a point of comparison, but will not be used as a reference per se.

[RyanChng]

@kenlunde: I see. What do you intend to use as a reference? The Songti and Kaiti standards, perhaps?

[kenlunde]

I am planning to use the forthcoming HKCS 2015 standard as the primary reference.

[RyanChng]

I see. Do keep us posted if possible! Thank you =)

[kenlunde]

That is the plan. 👍

[beachmat]

But will there still be an interim release before version 2 for the HKSCS as it stands?

[kenlunde]

@beachmat: No, because doing so represents a huge amount of work that would effectively need to be redone after all of the HKCS 2015 details are available.

[beachmat]

Thanks, and sorry, you made that clear earlier in the thread.

[orangeparanoid]

@kenlunde,

I appreciate your work on designing the HK font. (hopefully to be released in 2016 or 2017)

I recommend that someone / some people from Hong Kong should be hired to test if the HK font really works as expected, by actually viewing traditional Chinese characters on the screen.

As Adobe works with a Mainland China font company, Mainland Chinese citizens don't use the HK font / traditional Chinese characters. Traditional Chinese characters are banned, except in Hong Kong and Macau.

Mainland Chinese citizens literally are not able to tell if traditional Chinese characters are odd, strange or natural. These people simply use the simplified Chinese characters instead.

When Adobe asks Mainland Chinese citizens to test the HK font, chances are that some strange results can happen. Odd problems are just undetected.

Ideally, revising the same font less frequently can bring some convenience to the users. (even if the first HK font release is postponed)

[extc]

Agree. Once the font is incorporated into Android N, it is difficult to change as the system font folder is marked read-only in ROM. One need to root the system and overwrite it.

[kenlunde]

Please continue to be patient with regard to proper HK support in Source Han Sans / Noto Sans CJK. Several factors are contributing to the delay, one of which is adhering to the forthcoming HKSCS-2015 standard.

[orangeparanoid]

I just thought of more horizontal extensions for consideration.

[kenlunde]

@orangeparanoid: You may not completely understand the meaning of horizontal extension, because the only characters in your list that would qualify, because they do not yet have an H-source reference, are U+7CA4 粤 and U+865A 虚.

For the ones that share the same code point but have different glyphs for HK and CN, it would require disunification, meaning a separate code point for one of the characters in the glyph pair, to simultaneously support both glyphs for HK.

[hfhchan]

@orangeparanoid rest be assured, the "HK preferred" glyphs and code-points you have quoted are included in HKSCS 2016.

[hfhchan]

@kenlunde Rather than support the full of HKSCS, I have recently compiled a corpus of Hanzi in use in Hong Kong, based on a one year scrape of news articles (local news, sports, entertainment & commentary) from on.cc, the most popular news site in Hong Kong. I wonder if you are interested in it?

The complete corpus covers 8,648 distinct characters (including latin, kana, zhuyin and emoji). 447 characters are identified as typos (盬鹽, 恴意), simplified characters (铜銅), uncommon variants (俢修), or (true) source-separated equivalents (况況).

On random sampling, I deem the quality more representative and practical than the one Google compiled for their Google Fonts.

[orangeparanoid]

@kenlunde My correction: The HK preferred 黃 (U+9EC3)：

For U+9EC4, if the user changes the font from CN to HK, the user still sees U+9EC4, instead of U+9EC3. I guess, this is the expected behaviour of the font and the expected odd situation. Since these characters do not belong to the horizontal extension, there is no way to get back the HK preferred 黃 (U+9EC3).

Should (or could or will) the font be responsible for handling this situation? Should (or could or will) Unicode handle it? I am confused.

[hfhchan]

@orangeparanoid The font is generally not expected to handle this situation.

For U+9EC4, if the user changes the font from CN to HK, the user still sees U+9EC4, instead of U+9EC3. I guess, this is the expected behaviour of the font and the expected odd situation.

Yes, you are correct. The user / system should run simp <=> trad conversion routine to change U+9EC4 into the U+9EC3 before rendering using the fonts. (Even though U+9EC4 and U+9EC3 are not strictly simplified vs traditional character according to mainland Chinese standards, they are often treated as such in Taiwan and Hong Kong and other parts of the world.)

Since these characters do not belong to the horizontal extension, there is no way to get back the HK preferred 黃 (U+9EC3).

You misunderstand what horizontal extension means. Horizontal Extension means that the regional standards determine that an existing glyph or character in Unicode is deemed useful / used in that locale. Thus, they add that existing glyph or character in Unicode into their own regional standard. Horizontal Extension only cues font implementors that a certain character / glyph is useful in a particular locale. Horizontal Extension does not change the rendering of the character in any way.

HKSCS already includes U+9EC3. If HKSCS horizontally extends to U+9EC4, U+9EC4 will still be displayed with the missing stroke. U+9EC4 will not be converted or display as U+9EC3 or vice versa.

[hfhchan]

@orangeparanoid in reality, some fonts may choose to display U+9EC3 and U+9EC4 as 黃. These fonts are built to target printing in Taiwan/Hong Kong, where the existence of U+9EC4 instead of U+9EC3 is not desired and regarded as an error. If 黄 is required, the typesetter simply changes the font.

However, Source Han Sans is a general font for screen viewing and as system default font. User cannot easily change system font. Discerning such difference may be useful or required in certain circumstances. Therefore, Source Han Sans should and will render U+9EC3 and U+9EC4 differently, same as SimSun (default font for Windows, zh-CN) and PMingLiU (default font for Windows, zh-TW/zh-HK).

[kenlunde]

@hfhchan: Actually, a horizontal extension can change the rendering of a character, at least for the region for which the horizontal extension is applied. Of course, the representative glyph that is associated with the horizontal extension must be unifiable with the character itself, and supplying representative glyphs is one of the requirements for horizontal extensions.

[orangeparanoid]

The life of initially happy users of the Source Han Sans HK font:

Use case 1: A nine-year-old kid said, "Miss Wong, I saw 黄 （with the top of 共）instead of 黃 (with the top 廿一) on the mobile phone. You marked my 黄 as the wrong word in the dictation. It is unfair. I shall tell my Dad." 　　Miss Wong said, "Don't learn Chinese from the computer guys." 　　The kid's Dad wrote a letter to the school principal to complain about the poor teaching standard of the Chinese teacher the following day. 　　Two months later, the teacher got fired.

Use case 2: 　　An elderly woman applied for a job. She wrote 黄 （with the top of 共）according to printed information on the job ad she saw on the mobile phone. The boss of the company saw this word and commented, "Our company won't hire careless people." This boss clearly expected 黃 (with the top 廿一) .
　　This elderly woman could not get her job and remained unemployed.

I am sorry that the users relied on the font so much that using the character can bring some consequences. The users in both cases hated the font and the mobile phone so much.

[hfhchan]

@orangeparanoid well these hypothetical problems would also occur for Taiwanese user or Japanese user too. Both locales prefer 黃.

As a Hong Kong user I can tell you this is not a problem. All popular traditional Chinese keyboard on Android and iOS output 黃 (u+9ec3) instead of 黄 (u+9ec4).

How u+9ec4 displays is not a concern of average Hong Kong, Taiwanese or Japanese user.

[hfhchan]

@orangeparanoid

你所提出的假设情況基本上不会发生。首先，港台日都是使用“黃”而非“黄”，其他地方都相安无事，何以认为香港用家会有这些问题呢。

第二，身为香港人，我可以肯定告訴您，香港使用的输入法均會输出 U+9ec3 黃，而非 u+9ec4 黄。

U+9ec4 是怎么样字，港台日的人才不会理。

再者，在香港教育局出版的教材里，黄是简化字，不能算错字。老師被投诉，活该。老師被炒，这故事太夸张了呗。

[orangeparanoid]

My thoughts are:

(1) Responsibility sharing Should the font/ Unicode/ horizontal extension handle the situation when one glyph is preferred? If not, the users (including adults and hundreds and thousands of primary/ secondary school kids) should be solely responsible for distinguishing the characters. Okay, don't learn Chinese from computer guys. That's fine. (Never blame any font developer.)

(2a) Consider possible/ potential consequences in theory and in reality Should Information Technology help to reduce or solve the problem? What is the purpose of the font Source Han Sans HK? For adults only? Not for school kids? School kids use mobile phones too (sadly). You cannot prevent Use Case 1 from happening. (regardless of whether you think it is possible or not)

The mobile phone's font seemingly becomes the authoritative source of reference. What will happen? Less educated people use mobile phones too. You cannot prevent Use Case 2 from happening. (regardless of whether you think it is possible or not)

(2b) How users input the characters In practice, sadly, it is possible. Here's how:

Not everybody uses Cangjie. Some people use Pinyin for typing Chinese.

"Teaching Chinese in Putonghua (Pinyin)" is the somewhat mandatory practice in both primary and secondary schools, as reported in the news. (Please check with individual schools.)

When using "Chinese (Simplified) - Microsoft Pinyin New Experience Input Style" on Windows, typing the Pinyin 'huang' gives the Mainland China preferred character U+9EC4.

Now, with the voice input, it is also possible to get U+9EC4.

It is theoretically possible for individual schools to accept the Mainland China preferred character U+9EC4. In practice, please check with individual primary/ secondary schools.

(3) Confusion in official documents I can find The Mainland China preferred character U+9EC4 does exist in files in Hong Kong Legco: (An example to show that confusion can happen.) Example: 立法會交通事務委員會 (Legco Panel on Transport) 檢討沒有遵從交通燈指示的罪行 http://www.legco.gov.hk/yr06-07/chinese/panels/tp/papers/tp0323cb1-1190-1-c.pdf [Screenshot]

(4) New Shape of the Character (not just simplified characters) I know that U+9EC4 is the 新字形, invented by some Mainland Chinese citizens (Mmmmm, with no obvious speed improvement when a person reads the character) .

(I am sorry that I don't have the names of the inventors available).

U+9EC4 is not a "simplified character" in the official China sense but a "China'ized" traditional Chinese character (新字形 or New Shape of the Character). U+9EC4 is, however, Mainland China preferred.

To add more confusion, not all characters in 新字形 or New Shape of the Character are different from the HK convention. Some are even the same as characters in the HK convention. (That's why I once said hiring Mainland China citizens to make the HK font can create odd problems, I am afraid. 新字形 is another source of confusion.)

(5) How to check To see the differences in practice, please refer to Xian Dai Han Yu Ci Dian (现代汉语词典 ISBN 7-100-03477-9 which is a dictionary partly or fully edited by the ruling Communist Party) for more information.

Then, get a dictionary in Hong Kong, e.g. 朗文中學生中文新詞典 ISBN 962 00 0022 6 (The shapes of characters are printed based on 香港語文教育學院's works). Compare and contrast. (I don't know if it is illegal to bring 朗文中學生中文新詞典 to Mainland China.)

In Source Han Sans HK, add the horizontal extension of U+9EC4 and U+9EC3? (Is it justifiable enough for this to happen?) The examples I quoted also include 澳、奧.

(6) So much work I think, with so much work, the release date of the HK font should possibly be in 2018 or later, to preserve the quality of the HK font, in my opinion.

Thanks for understanding.

[hfhchan]

(1) absolutely not. the person inputting the character should ensure he/she is inputting the character. It would create more confusion of source han sans displays U+9EC4 as U+9EC3 in the Hong Kong context. If I open the same document on Microsoft Windows, U+9EC4 would change to use the mainland-preferred glyph because Microsoft Windows does not come with Source Han Sans! The integrity of the shape of a particular "code-point" across operating systems and regions is more important than the "correctness" from a "character" standpoint. There is no point in Source Han Sans changing the glyph if other fonts show something different.

The user cannot check if he/she is inputting the right character if the two codepoint display the same too.

(2) Source Han Sans is a general purpose font. It should not attempt to "correct" any variants. Such "corrective" fonts should be, and have always been, reserved for digital printing or amateur "抗眼殘" use only.

If you correct 黃 to 黄, then should it correct 裡 to 裏? It quickly becomes a slippery slope once you start "correct" characters.

(3) That's the problem of our government. Most people don't care anyway.

(4) 黄 with a missing stroke is not a new invention. In calligraphy, 黄 is more common than 黃. The actual terminology for the character shape is not important -- anyhow, the teacher should explain it is not INCORRECT. From the education system perspective, it is a simplified character. Furthermore, HKEAA accepts simplified characters in its exams. If the teacher bans simplified characters, (out of some political ideology), it is his/her problem.

(5) There is no need. These differences have been fully reflected in HKSCS. The CLIAC has already decided that no two code-points should display the same in the HKSCS, including all horizontal extensions. Therefore, even if 澳、奧 was horizontally extended on the part of the CLIAC, the mainland-preferred glyph should be kept.

Another example is 悅 (U+6085) and 悦 (U+60A6). The CLIAC has already decided that the difference between 悅 and 悦 should be preserved in the upcoming HKSCS-2015. Previously, the Guidelines on Character Glyphs for Chinese Computer Systems had requested otherwise, but only for characters including 兌/兑. It was deemed an oversight and has since been corrected.

It is the responsibility for the person inputting to check if he/she is inputting the right character.

When using "Chinese (Simplified) - Microsoft Pinyin New Experience Input Style" on Windows, typing the Pinyin 'huang' gives the Mainland China preferred character U+9EC4.

He/she should use "Chinese (Traditional, Hong Kong) - Microsoft Bopomofo" and choose Hanyu Pinyin instead of Zhuyin Fuhao in the settings. Or, he/she can use pinyinput.com which is made by Hong Kong people.

Now, with the voice input, it is also possible to get U+9EC4.

That is the problem of the speech recognition software. You should rightfully file a complaint to the product. That is a gross negligence to the customs and preferences of Hong Kong.

"Teaching Chinese in Putonghua (Pinyin)" is the somewhat mandatory practice in both primary and secondary schools, as reported in the news. (Please check with individual schools.)

According to the EDB, schools are "strongly recommended" to use Traditional Chinese characters. As said, on the part of the EDB, 黄 is a simplified character. The EDB officially refuses to examine (審核) any education material that is written in simplified characters -- that means it will not be included in Recommended Textbook List (適用書目表), which also means schools may be held responsible if they use textbooks with improper material. Anyhow, 黃 and 黄 are both accepted in the public exams -- so this is not even a problem.

I am now proposing an OpenType flag through other channels, which asks for the unification of different character forms activated by necessity to replace glyphs by their preferred variants. This is a similar solution used by Japan to preserve their different glyph forms specified in different versions of JIS.

[orangeparanoid]

@hfhchan, actually not everybody understands my points.

I am writing from a user experience perspective (Not necessarily a political perspective. Beware.). Every time people think of differences between HK and Mainland China, people immediately think of political issues. (Oh, not in my points. I don't say every Communist Party product is bad.)

I would like to talk about the user experience and the HK conventions. (No particular political implication. Users just don't use some characters in some ways.)

I am not insisting on doing/ changing/ correcting some things. Not that something must happen to suit the taste of users. Yes, users can be ignored entirely. No problem.

Just make the font developers happy. It is entirely okay. Nothing wrong of the developers.

(I am not starting a flame war. I don't start one.)

I am suggesting the social cost involved. (If the HK font possibly saved some social cost...)

There are 337 558 primary school students in 2015/ 2016. (Source: http://www.edb.gov.hk/en/about-edb/publications-stat/figures/pri.html )

Let's assume (without any questionnaires for evidence) 10 per cent of these students asked the teachers about the legitimacy of (hand)writing according to the mobile phone's font. There would be about 33755 students asking this type of questions. Let's say each of them spent 1 minute asking this type of questions. 33755 minutes of time would be spent on asking. Let's say the teacher spent 2 minutes explaining the issue to each of them individually. The total time spent would be 33755 + (33755 * 2) minutes. Let's be positive. 30 students were in one class. 33755/ 30 = about 1126 classes. These classes were just 10 per cent of the entire primary school student enrollment. Let's say each class asked once only.

The total time spent on asking and answering would be 1126 + (1126 * 2) = 3378 minutes.

Then, assume the teacher had to respond to allegations of poor teaching standard and had to spend 15 minutes responding to parents. Out of 1126 classes, let's say 500 parents complained about the issue of mobile phone's font not being accepted as the correct answer. They complained and spent three minutes each time. The amount of complaint time spent would be 500 * 3 = 1500 minutes. The amount of time responding to the complaints would be 500 * 15 = 7500 minutes. The entire complaint process would require 1500 + 7500 = 9000 minutes.

If the initial process of teaching, asking and answering was done pretty well, the complaint time would be saved. The total time spent would be hopefully only 3378 minutes. (Just >56 hours)

If the initial process was not done well (this attracted complaints), the total time spent would be 3378 + 9000 = 12378 minutes. (>206 hours)

If you think this time spent was unavoidable...

In practice, for HK primary school teachers, will they accept the Mainland China preferred U+9EC4? You could conduct a survey.

I mentioned earlier. Mobile phone users can be entirely ignored. Don't care about wasting people's time. Nothing wrong of the developers. Just for your information, the font can cost some social cost.

I am not an expert in computing. I can do the maths. In the calculation, I did not count the time spent in non-primary-school industries. The time spent (wasted if you like) would be much larger than 206 hours.

If you think my calculation is faulty, I would love to learn more and improve myself. I like learning and improving.

Thanks for the time spent if you read.

[tamcy]

As I am really no expert on this issue, I am not sure if I understand @orangeparanoid correctly.

IIUC, "Horizontal extension" is used to tag a codepoint in Unicode that is deemed useful in a particular region, but is lacking the corresponding source reference (kIRG_HSource for HK) due to some reasons.

For example, "兌" (U+514C) is the preferred form in Taiwan, while "兑" (U+5151) is the preferred form in Hong Kong. As "兌" is encoded in Big5 (codepoint: A749) but "兑" isn't, "兌" (U+514C) is supplied with a corresponding kIRG_HSource, while "兑" has none, despite it being the actual preferred form in HK. This can lead to misunderstanding that "兑" is not used in HK. With the release of the upcoming Hong Kong Character Set 201x, "兑" will come with a kIRG_HSource to identify that this character is in fact used by HK, so font product targeting HK should support it.

In this sense, a. "Horizontal extension" is merely a mechanism to add source information to an existing codepoint. It doesn't define any relationship with another codepoint whatsoever. It also doesn't mean to map the actual presentation (glyph) of codepoint B to codepoint A. b. As 黃 (U+9ec3) is already the preferred form in HK with a kIRG_HSource, I don't understand why @orangeparanoid would want 黄 (U+9ec4) to be added via "horizontal extension". As said, "horizontal extension" is used to mark a codepoint as useful in a particular region, and what he suggested ("黃" should be shown even user enters "黄" because "黃" is the preferred form) clearly contradicts it. c. "Horizontal extension" is not established by the font product. This means that his "horizontal extension" suggestion should actually be raised to CLIAC, not here. d. As mentioned in this document, modifying the glyph form of the character mapped in Big5 (e.g. requireing 兌 U+514C to be rendered the same as 兑 U+5151) would result in violation of the encoding principal of ISO/IEC10646, causing inconsistency in documents produced at different times. I believe the same would certainly happen if Source Han Sans HK changes the glyph of 黄 U+9EC4 to the same as 黃 U+9EC3 as you suggested. For instance, user will no longer view @orangeparanoid's (and my) issue concerning 黃 and 黄 properly with this hypothetical Source Han Sans HK.

(And no, students are not supposed to learn Chinese writing via mobile phone, which UI probably isn't presented in Regular Script 楷書.)

[orangeparanoid]

I am not sure if it is appropriate to provide the opinion here.

The MingLiU font on Windows has indeed caused some social costs to users. Okay, primary school teachers print notes, exercises, and test/ exam papers. Some teachers try their best to avoid MingLiU. If unavoidable, teachers print and change the character by pen, before photocopying.

MingLiU font: https://www.microsoft.com/typography/fonts/family.aspx?FID=245

Example, 等：The top part underneath 竹 being 士, not 土

I am sure that Source Han Sans HK will make it 土, according to the HK conventions. Don't think MingLiU is the best font users expect when handling documents.

Let's assume, it takes 1 minute to change the character by pen. There are 10 exercises each subject each month. There are 4 subjects. The time spent is 1 * 10 4 = 40 minutes per month. There are 6 levels from Primary 1 to Primary 6. For one school, the time spent is 40 6 = 240 minutes per month.

There are 572 primary schools in Hong Kong. When all teachers do the same, the time spent per month is 240 * 572 = 137280 minutes per month. Do this for eight months. The time spent is 137280 * 8 = 1098240 minutes. (This is 18304 hours. Amazing.)

Back to the horizontal extensions issue, if this feature does not help in the Use Cases I suggested, I have no more comments.

I can be wrong. I can be misunderstanding the usefulness of horizontal extensions in the Use Cases.

Thanks for the any helpful advice and for the time spent.

[hfhchan]

I am not insisting on doing/ changing/ correcting some things. Not that something must happen to suit the taste of users. Yes, users can be ignored entirely. No problem.

Just make the font developers happy. It is entirely okay. Nothing wrong of the developers.

@orangeparanoid 您好似將我反對將兩個碼位區分字形，簡單化為造字廠商懶惰。對不起，我可能之前語氣不好。

我覺得您所提出的假設不會發生，也未曾發生。就算發生，也是教育體制的問題，不是字體的過失。可能就咁誤導左您，令你覺得係造字廠商懶惰不肯行多一步解決問題。

但我想澄清幾點。

據我了解，你提議無論是 U+9EC3 和 U+9EC4 都顯示為黃？

我反對的原因如下： （１）當年製作ISO/IEC 10646的時候（1999年），中日韓台一致決定現時20292個字符。換句話說，亦即係當年覺得有區分的需要。至少喺Unicode嘅層面，佢地係繁簡關係 (國際碼將Big-5 與GBK所使用字符差異直接視為繁簡關係)。U+9EC3 和 U+9EC4 視為不同的字，能夠分開輸入，這個是編碼層次的問題，不是字體層面的問題。中日韓台將四區文字編在一區，這個是歷史事實。有人主張應該將所有不同的寫法統一使用同一個碼位，有人主張中日韓台四區的字無論多像都應該獲分配不同的碼位。最後的結果就是一些字分開編碼，一些字統一編碼。已成定局，唯今之計就是輸入時要多啲留意。

（２）台日兩區都是以黃為標準。他們也沒有人要求將 U+9EC3 和 U+9EC4 都顯示為黃。您所形容的問題，台日兩區理論上都會發生。

（３）假設只有 Source Han Sans HK 將 U+9EC3 和 U+9EC4 都顯示為黃，您整嘅文件傳送到另一部無 Source Han Sans HK 字體嘅電腦時，如果您錯誤輸入U+9EC4 ，對方見到嘅就會係黄，而唔係黃。如果將兩個字設計成同一個樣，會令到你無法確保你打啱字。字符顯示唔一致，會造成混亂，大幅增加校對所需時間與專業知識。

（４）Word裏的搜尋功能針對「字符」而非「字」，如果搜尋框內輸入 U+9EC4 ，是無法找到U+9EC3 的。如果 U+9EC3 和 U+9EC4 望落去一樣樣，恐怕會引起混亂。

（５）@tamcy 都幫我講埋，Horizontal Extension 嘅事，唔係話 Adobe 想點就點，香港負責向 ISO/IEC 10646 提出 Horizontal Extension 嘅代表團就係香港特別行政區政府政府資訊科技總監辦公室中文界面諮詢委員會。如果您對Horizontal Extension 有咩提議，向港府提出比較適當。

（６）兩個字符設計成同一個樣會違反 ISO/IEC 10646 嘅編碼原則。即使中文界面諮詢委員會決定Horizontally Extend 將 U+9EC4 編入港區使用，都會保存 U+9EC4 從三筆草花頭嘅字形。

（７）如果中文界面諮詢委員會將 U+9EC4 標為港區使用，或會使人以為 U+9EC4 在本港一般行文可以接受。

（８）一般用途嘅字體嘅作用，就係要區分唔同嘅「字符」。印刷用嘅字體嘅作用，就係要區分唔同嘅「字」。如果您想不論編碼都顯示「正確」的字形，應當採用針對印刷用嘅字體。

（９）如果真的要想學生解釋，就解釋話黄係異體字，亦係簡化字。呢個係教育工作者嘅責任。要知道，電腦的中文系統不是為港人而設，而是為了中日韓台港澳越的需要而設，中間必有取捨。

[hfhchan]

@orangeparanoid 我反而想提議，應當關注一下中文界面諮詢委員會的參考字形、教育局小學生字詞表裏的字形與香港通行的印刷宋體（包括蒙納宋、華康儷宋）字形有不同大大小小的差異。基本上中文界面諮詢委員會的參考字形、教育局小學生字詞表裏的字形都是閉門造車。蒙納宋、華康儷宋字形是香港設計師80年代針對香港通行寫法而製作的，香港人習慣使用丢而不用丟，用兹不用茲（滋右邊），插字右邊用千不用干，叟字一筆棟穿，老字帶鉤，都能在字體裏充分反映，此等寫法卻在兩官方參考中標為「異體」。

中文書寫有其變化規則，不能兒戲的說，老字下方的匕在甲骨文是拐杖的形體，所以不帶鉤。根本是穿鑿附會，拐杖會彎？ 流右下是川的變體，所以不鉤。鉤與不鉤會影響字義咩？上至隋朝都是帶鉤的。

有相同寫法的只有台灣教育部標準字形。世事無咁多巧合，查實當年推出常用字字形表，係應台灣教育部標準字形而製作的。中文界面諮詢委員會的參考字形亦係用華康的細明體微調而成。

求字、也字、鹿下比、蠶上旡、選上巳、旨上匕等字宋體楷體不鉤，也是無中生有、莫名其妙的寫法。

香港細路寫字越來越樣衰，這個基本上是公認的事實。唔想一些平衡美感盡失的楷書與宋體殘害香港人下一代的審美觀，我想需要更多人向政府提出建議，還原楷書宋體應有的筆法。

[orangeparanoid]

I would say based on what I understand here, the Chinese characters issues will be endless because of the laissez-faire policy previously adopted for many years (not thinking more about education, etc.). Existing usage is not changeable unless things break. Social costs will remain social costs: Users themselves will always be solely responsible for using the Chinese characters/ Unicode/ font/ Chinese input methods.

Sorry for bringing the issues in the wrong place. Social costs will remain social costs and the costs will just exist. It's better not to break things.

(If a genius of Chinese characters+ Unicode+ font+ Chinese input methods+human language education+not breaking things ever proposed a brilliant solution...)

For me, better do something else for saving the characters I want to use.

[tamcy]

@orangeparanoid I can't speak for the admin, but I think it is completely OK to propose 黄 U+9EC4 to look the same as 黃 U+9EC3 (whether it will get accepted is another question). But "horizontal extension" is probably not what you want, and this leads to confusion.

We are not living in a perfect world. Variants do exist. Just pay a visit to Wong Tai Sin and you will find different variants of 黃:

So even your "social cost math" stands, the cost isn't solely contributed by the unreleased Source Han Sans HK. Student will probably ask about why the character they saw on newspaper / publications / television programmes / road signs / buildings isn't exactly the same as what they learnt anyway. And I am quite sure that this won't be "fixed" by merely mapping the glyph of 黃 to 黄 in SHS-HK.

[kenlunde]

Thanks to all for the recent discussions. One of the reasons for the delay in deploying HK versions of this typeface design is to make sure that it is done right. I considered remapping existing glyphs to get part of the way there, but I concluded that deploying a full solution, though at a later date, was an overall better solution and less confusing.

[kenlunde]

Hong Kong SCS-2016 was published this month, and while it includes representative glyph code charts for HKSCS-2016 proper, representative glyph code charts for the Big Five subset are forthcoming. These materials will serve as the basis for the HK fonts and font instances that will be deployed as part of the Version 2.000 update.

[hfhchan]

Note: The government has promised to clarify that the new glyphs are "reference glyphs" and not intended to be "prescriptive glyphs" via written correspondence. Factually speaking, there is nothing "representative" about the glyphs in the charts, but anyways.

[kenlunde]

@hfhchan: Of course, but they certainly serve as a guide for font developers. As I have stated before, if one follows representative glyphs too closely, the end result will be a clone of the typeface that was used for the representative glyphs.

[c933103]

https://www.ogcio.gov.hk/en/business/tech_promotion/ccli/cliac/reference_glyphs.htm Information linked from this webpage, Reference Glyphs for Chinese Computer Systems in Hong Kong, have also been updated.

[kenlunde]

@c933103: Yes, I am aware of this, and used it last month to go through the Source Han Sans glyphs to formulate a plan for proper HK support.