Consolidation of Glyph Correction Suggestions (See Issue #178)
kenlunde opened this issue · 120 comments
This Issue will be used to track glyph correction suggestions, and will consolidate existing Issues so that a single Issue can be used. Please report any future glyph correction suggestions to this Issue.
In TWHK, the rooftop dots in a "two dots + horizontal stroke" (e.g. 首弟美 etc) may need be redesigned. Currently, the first dot touch but not join the horizontal stroke, while the second dot join the horizontal stroke.
According to the MOE Song glyphs, they should not touch nor join the horizontal stroke. In the commerical Chinese Song typefaces, the left dot does not touch the horizontal line while the right dot joins the horizontal line. This is because the shape of the left dot looks very "black", the shape of the right dot needs to be elongated to create a balance of blackness. However, since strokes are the same thickness in Heiti and balanced in blackness already, the right stroke need not be elongated and join the horizontal line.
I think that both strokes "join" suits Heiti fonts much better. An example is to compare the rooftop dots of 慈 versus 弟. My opinion is that joining looks better than one touch and one join, or two touch.
However, if sharing more glyphs are preferred, then having both strokes touch instead of joining horizontal line may be preferred. For the CN glyphs, Microsoft YaHei itself is not consistent about using "left touch, right join" or "left touch, right touch". So if the CN and TW glyphs used the "left touch, right touch", the same glyph can be shared across CN/TW/JP/KR.
@hfhchan: hmm, what about the two strokes in compounds like 立? If they both touch bottom and both don't touch top... might look weird. Also Taiwan standard says those strokes must touch bottom AND top...
@RyanChng agree with you that the strokes must touch top and bottom for TW's 立. I think this means that the glyphs for TW's 立, by itself and in elongated position (on the left or right) cannot continue to be shared with CN. Meanwhile, the top dot should at least touch if not join the first horizontal line too. So I think they should be disunified from the CN glyphs.
SHS TW is also inconsistent about the left dot touch/join when 立 is compressed at the top. Compare 音, 章 and 意. The style for 章 (two dots join at bottom) seems more appropriate to me, and is also the style used for Microsoft YaHei Bold when 立 is in this position. In this case, I think it is possible that SHS can get away by having the top of the two strokes touch the top stroke, and join the right stroke, for both CN and TW in this situation.
To better illustrate my point, here is a quick ugly mockup:
Red: Changed Glyphs / New Glyphs
Grey: Shared Glyphs with CN
Inconsistent shape for 全(U+5168) in SC version
While 全 as a component of some glyphs, such as 铨, 诠, 佺, 醛, 荃, 痊 .etc, middle stroke "一" is longer than top stroke "一" of their component "王".
However, for the Simplified Chinese glyph for 全, the length of top stroke "一" and middle stroke "一" is almost equal of its under component "王". This is quite different from both the glyph for 全 as a component of other glyhps and original JP version.
Therefore, my suggestion is making the middle stroke "一" longer than the top stroke "一" of component "王" of the Simplified Chinese glyph for 全 as JP version. SC and JP version should share the same component "王" to keep consistency of the glyph for 全.
Hmm @fatloong I notice there's another difference between SC and JP, which is the intersection/meeting of the two strokes in 人. Wonder why that is so...
@kenlunde there are actually a lot of errors in TC I’ve noticed. The 禾 component in 透 and 誘 is wrong, the last stroke should curve downwards. Also for 稽, the 匕 component’s first stroke should be straight instead of curved... the Taiwan MOE standard is notoriously difficult, so should we open a separate issue for TW glyph correction? Haha
@RyanChng Well I guess the reason for the difference of 人 between SC and JP may be the glyph should follow China and Japan standard relatively...
@fatloong yeah China standard seems to insist the two strokes meet differently, Japan standard shows them meeting at the same point. TW standard is a 入.
Please try to refrain from using this "issue" as a discussion thread. If a discussion is necessary, I suggest it be done elsewhere, and the results posted to this issue.
OK sorry @kenlunde, to summarise, known issues we have right now with TW are the strokes in 誘, 透 and 稽...
No worries. I simply want to minimize the volume of discussion, and instead to focus more on the end result of such discussions. This makes the "issue" much easier to navigate.
The component 口 in 極 (U+6975, TW & CN), 避 (U+907F, CN) and 迵 (U+8FF5, TW & CN) are inconsistent with the other glyphs.
Also, I would like to suggest to improve the quality of TW version's 極 (look at the placement of 口). Actually this is not an isolated issue: when there is a need to adjust the look of the character for standard compliance, I found that KR version tends to just replace the unsuitable parts, preserving the original components as much as possible. However, the vendor tends to redraw the whole CN/TW glyph (Exceptions are like 鬱 and 留). Unfortunately, the quality of the redrawn glyph sometimes isn't quite to the standard of the original one (I suppose JP can be used as the reference base?).
(EDIT 1: added 迵 U+8FF5 to the list)
(EDIT 2: added 鴿 U+9D3F, 造 U+9020)
Although 國字標準字體研訂原則 doesn't specify how the corners of 口 should be, 口 only has protrusions on both bottom corners when 口 is exposed at the bottom of the character in the 國字標準字體方體母稿.
I think for 方体, we should follow the standard of "when 口 is at left or bottom left, no protrusion on bottom-right corner; when 口 is at the bottom or right or anywhere else, protrusions at the bottom."
The bottom of glyph 鳖 should be aligned to glyph 吃:
Because ideographs are optically centered within the em-box, and do not rest on a static line, I will leave the judgment up to SinoType's designers. In other words, I will bring this issue to their attention. However, your screenshot shows a perhaps more serious problem with the glyph for 鳖 (uni9CD6-CN) in that the top portion of the protruding vertical stroke in its upper-left component has two thicknesses. I will also report this issue to SinoType for fixing.
The issue of inconsistent thicknesses for the same stroke also occurs in other glyphs with 㡀 component (like 敝, 弊, 幣) in all locales. It seems to me that the designer intentionally reduced the thickness of the inner vertical line of 㡀 to give more space to accommodate the two inner "ten"s (点/點/､) for the heaviest weight. The fact that such behavior is also found in Kozuka Mincho and Kozuka Gothic seems to support my assumption. However, due to the interpolation nature of Source Han Sans, that thickness difference is also observed in intermediate weights (thin, normal, regular, medium and bold) where such an adjustment is unnecessary.
Not a correctness issue per se, but the character 為 is very oddly shaped. There seems to be visually too big a gap on the centre-left of the glyph. Most common fonts (e.g. Microsoft Yahei, Microsoft Jhenghei, SimHei) "deal" with this by starting the second downward left stroke about 1/3 from the left of the glyph, rather than 2/5 from the right.
Regarding the TW version of Source Han Sans, the glyph "恋" is supposed to be presented like the following:
But, it displays as following (in SHS 1.004R):
Is that character included in Plane 1 or 2 of CNS11643? If not, I believe a similar but not exact glyph is selected for that character. If yes, I think it's a bug.
I am not familiar with "planes", but what I saw among all other 全字庫標準 CNS11643 fonts supports my idea:
You could download 「全字庫正宋體」 and 「全字庫正楷體」 at this website:
http://data.gov.tw/node/5961
They includes most commonly-used Simplified Chinese kanji glyphs (almost all of them, but I don't know the exact number).
As far as I know, Plane 1+2 ≈ Big5 which doesn't include any simplified characters. It seems to me that SHS TC satisfies the minimum requirement of CNS11643 while the fonts you listed support more glyphs.
But MOE really showed their standards in 「全字庫正宋體」 and 「全字庫正楷體」 regarding simplified kanji glyphs used in PRC and Japan.
Let we stop our discussions here and let Ken Lunde decides whether it's necessary to extended the SHS TW as what 「全字庫正宋體」 and 「全字庫正楷體」 do. If you think further discussion is necessary, please open a new issue as our discussion thread. Do not reply this message here.
I found that two "王" radicals in "瑟琶" are asymmetric...
芮 in JP - CN - TW
The weighting of 艹 and 內 doesn't look good in TW version.
Per this tweet, the CN glyph for U+5B4D (孍), uni5B4D-CN, has an incorrect left-side component (radical), which I just confirmed.
I would like to see the 口part to appear with the same height across characters with this component.
I mean the same height between the top margin and the top horizontal line of 口. See the screenshot.
+1 to the above suggestion. Glad that I am not the only one who noticed this issue (that exceptionally high radical "口" in 啲 immediately caught my attention when I was reading a newspaper article on my Android phone. I hesitated to report it as it may sound subjective).
Also note that the placement of 口 is much more consistent in JP (second line in the screenshot). So this could be exclusive to CN/TW/HK glyphs.
Thank you for the comments on the placement of the 口 radical/component.
to @kenlunde & @orangeparanoid >
Such inconsistency is pretty common among all font products made by SinoType, which is one of the reason I look down on them. They never do placement unification on radical parts.
While I agree that some characters would benefit from such adjustment, in terms of the relative height and Y-axis position of the 口 radical/component, such inconsistency is not likely to be relevant in real-world text as characters that use the same component are not likely to appear together in strings of three or more (there are, of course, such two-character compounds). Still, this is worth bringing to SinoType's attention.
@kenlunde "such inconsistency is not likely to be relevant in real-world text as characters that use the same component are not likely to appear together in strings of three or more (there are, of course, such two-character compounds)"
These characters with the 口 component exist in the same utterance, in common real-world text. They are in Cantonese Chinese (not in Mandarin Chinese).
See the examples in a dictionary entitled "廣州方言詞典" published by 江蘇教育出版社 in 2003. (Maybe someone with the Cantonese Chinese background should help.)
@orangeparanoid I agree that the 口 radical is really common in Cantonese. Here's an example sentence: 你訂嗰啲嘢啱啱嚟咗，擺嗮喺嗰度喎。(The stuff you ordered just came, and [we] put them all there.)
With all due respect @kenlunde, I have to agree. In fact some write the 度 (location pronoun) as 喥, rendering the sentence as 你訂嗰啲嘢啱啱嚟咗，擺嗮喺嗰喥喎。
It’s more or less due to the fact that many Cantonese particles with unclear etymology are assigned phono-semantic characters with the right side indicating pronunciation and the left side standardising on the 口 radical.
Thank you, all, for this valuable information and details.
I don't know if the following issue with the shape of the upper part of 巴 in the characters 聲 and 絕 should be reported. In the screenshots below, you could compare the left and right squares or rectangles inside 巴 in the other two characters mentioned. 聲 and 絕 look odd because the squares or rectangles are not identical at font size 14 or small font sizes. At larger font sizes, they look as natural as the other characters. It is not easy to reproduce this issue. For your information,
To reproduce the issue of the character 絕:
@orangeparanoid I believe it's more of Windows hinting problem. Take OS X for example:
They are rendered properly.
@rschiang is correct in that this is a rendering issue, not a glyph issue. Depending on the environment (OS or application), a different renderer may be used, and even if the same renderer is used, its settings may be different. This normally affects edge cases, meaning that if you look long enough, you'll find issues. That is the nature of fitting pixels to a grid, and it is not specific to Source Han Sans.
On Windows, indeed, the characters of 絕 and 聲 look less odd, after (1) I changed the registry settings, (2) I disabled the ClearType option, and (3) I restarted the computer.
regedit:
HKEY_CURRENT_USER\Control Panel\Desktop
"FontSmoothingType" -> 0
"FontSmoothing" -> 0
On Debian Linux,
dpkg-reconfigure fontconfig-config
Font tuning method for screen (system default): -> None
Enable subpixel rendering for screen: -> Never
Enable bitmapped fonts by default? -> No
I restarted the computer to get the desired display of the characters. Debian Linux displays these characters perfectly at any font size.
Reference:
https://wiki.debian.org/Fonts
Maybe, it is good to list the information somewhere here:
Font installation instructions
https://github.com/adobe-fonts/source-han-sans/blob/master/README.md
I couldn't figure it out without your advice. Thanks.
See Issue #120 for LE connection issues that affect some glyphs that use "⻐" or "⻠" as a component, such as 钮钵钯 and 饪. I looked at the master sources, and while the ExtraLight masters look okay, the Heavy ones have connections that are off by one or two units. This means that most of the five intermediate weights will exhibit this issue.
踎's 否 seems extremely compressed compared to other characters, expecially 鑽 who's phonetic component is more complicated. Also compare with 跨.
The glyph U+5C14 尔 is presented inconsistently.
In Source Han Sans Simplified Chinese the glyph adopts the Japanese form as part of composite characters, contrary to prescribed practices in China. This is arguably a pressing issue as U+4F60 你 is a ubiquitous character in daily use, and the defect is highly visible (and jarring) with larger font sizes.
Thank you.
For 黃 ， 橫
In the table 通用规范汉字表
黄 黃
横 橫
They are encoded separately.
Thank you, @jimmymasaru. I was about to reply with the same information.
@kenlunde and @jimmymasaru ,
Thanks for such enlightenment. This reminds me of the issue of "preferred glyph" in PRC. Not the font issue, but a "preferred glyph" issue.
The following CN glyphs need to be adjusted:
U+3D78 㵸 (uni3D78-CN): Remove the extra box-like element in the center of the right side of the glyph
U+454E 䕎 (uni454E-CN): The lower-left component is incorrect
U+49B4 䦴 (uni49B4-CN): The bottom two horizontal strokes should have different lengths
U+5329 匩 (uni5329-CN): The inner components are connected incorrectly
U+61F2 懲 (uni61F2-CN): A horizontal stroke is missing from the top-middle component
U+752D 甭 (uni752D-CN): The left vertical stroke of the bottom component is incorrect
U+8669 虩 (uni8669-CN): The upper-left component is incorrect
U+884B 衋 (uni884B-CN): The top component is missing a horizontal stroke
U+9119 鄙 (uni9119-CN): The center vertical stroke should be vertical not slightly diagonal
U+95D9 闙 (uni95D9-CN): The arrangement of the inner components is incorrect
I actually suspect U+8669 standard glyph for PRC is mistakenly designed…… (compare with 隙) I will raise this up in a document for IRG#45.
Thank you, and please keep me posted about U+8669. (IRG#45 has already taken place, so I think that you meant IRG#46.)
Ah yes. I am including it into IRGN2131 but it is currently listed under IRG#45. The T-source characters I am also originally disputing is 枲 and 葈: the bottom part should be shaped like 麻 instead of 木.
@hfhchan U+8669's original source is GB 7589-87 65-49, and I just took a photo of that standard's glyph chart, which shows a different glyph, in terms of the upper-left component. In other words, Source Han Sans is probably correct, and the "G" column glyph of Unicode and ISO/IEC 10646 is probably incorrect, as you are suggesting.
Another example of the 口 component which may be useful for typsetting and QA:
https://www.facebook.com/drkwokkaki/photos/a.410966992274509.80919.395804300457445/970463786324824/?type=3
Those characters with 口 (哋嘅啲) and the character "攞" could do with considerably better stroke thickening and baseline alignment too. (Incidentally, these characters are predominately only used in Cantonese.)
The 見 component of 視 could do with a bit of enlargement on the x-axis too. It looks quite strange now considering that normal fonts usually render it as 3/7 or 4/6.
The radical of glyph "袱" (U+88B1) in CN/TW (37133) is incorrect.
Recorded. Thank you!
From @extc
The design of U+450B is inconsistent with the other traditional characters.
Being listed in Plane 6 of CNS, it is not subject to the glyph normalization by the MOE.
Using the design for H-source would be a better replacement.
This is similar to the case for 着 and 嘅.
@hfhchan: As part of my current work toward Version 2.000 and HK support, U+450B is already marked as "to be modified" as its working glyph name is uni450B-HK, meaning that it is meant for HK use, but its glyph does not currently conform to the HK standard. There is also a glyph whose working glyph name is uni450B-CN, but that's for CN use.
l checked the Ext B glyphs of Source Han Sans TW and find 26 glyphs have errors. I summarized in the table as follows:
https://drive.google.com/file/d/0B2wRQ9hyzuhVSFBSYTB6TXFRWHM/view
1st column : Source Han Sans TW Regular
2nd column: MingLiU-HKSCS_ExtB
3rd column: TW-Sung-ExtB-98
Note that the glyphs for all 26 of these characters are included for HK use, and have known issues in that a great number of them do not conform to HK conventions. These are already tagged for adjustment in the Version 2.000 update. Still, I very much appreciate that you pointed out these issues, and when Version 2.000 is deployed, either late this year or in early 2017, please recheck the glyphs for these characters.
The characters 〈, 〉, 〈, 〉, 《, 》, 「, 」, 『, 』, 【, 】, 〔, 〕, 〖, 〗, 〘, 〙, 〚, and 〛 in Korean need be proportional instead of fullwidth. As Korean separates words with spaces, leaving a space before or after them is considered a bad idea and should be avoided.
(This is also related to Issue #28.)
Does the symbol ’ have to be fullwidth in Chinese? As it is not only used as a right single quotation mark but also as an apostrophe, it is not a good idea to make it fullwidth. Even Unicode recommends using ’ (instead of ' from ASCII) for an apostrophe.
A fullwidth ’ is bad even for romanized Chinese. Keep in mind that apostrophes are used in Hanyu Pinyin, like “Xi’an” (西安). If the apostrophe in “Xi’an” is fullwidth, there is too much gap between “Xi’” and “an,” as though there is a space right after the apostrophe.
Making the symbol ’ fullwidth in Chinese has more disadvantages than advantages. I suggest making ‘ ’ “ ” in Chinese as proportional, like Japanese and Korean.
Come to think of it, when the symbol ’ is used as an apostrophe, it is almost always followed by a Latin letter (it’s, c’est, O’Brien, d’Artagnan, etc.) or by a digit (’16 for the year 2016).
Here is another suggestion:
Leave the default glyph of ’ in Chinese as fullwidth. However, if the character ’ is followed by a Latin letter or by a digit, use a proportional glyph.
This can be done using GSUB without any problems.
Here are the Latin letters and digits covered by Source Han Sans:
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, ª, º, À, Á, Â, Ã, Ä, Å, Æ, Ç, È, É, Ê, Ë, Ì, Í, Î, Ï, Ð, Ñ, Ò, Ó, Ô, Õ, Ö, Ø, Ù, Ú, Û, Ü, Ý, Þ, ß, à, á, â, ã, ä, å, æ, ç, è, é, ê, ë, ì, í, î, ï, ð, ñ, ò, ó, ô, õ, ö, ø, ù, ú, û, ü, ý, þ, ÿ, Ā, ā, Ă, ă, Đ, đ, Ē, ē, Ě, ě, Ĩ, ĩ, Ī, ī, Ń, ń, Ň, ň, Ō, ō, Ŏ, ŏ, Œ, œ, Ũ, ũ, Ū, ū, Ŭ, ŭ, ƒ, Ơ, ơ, Ư, ư, Ǎ, ǎ, Ǐ, ǐ, Ǒ, ǒ, Ǔ, ǔ, Ǖ, ǖ, Ǘ, ǘ, Ǚ, ǚ, Ǜ, ǜ, Ǹ, ǹ, ɑ, ɡ, Ḿ, ḿ, Ạ, ạ, Ả, ả, Ấ, ấ, Ầ, ầ, Ẩ, ẩ, Ẫ, ẫ, Ậ, ậ, Ắ, ắ, Ằ, ằ, Ẳ, ẳ, Ẵ, ẵ, Ặ, ặ, Ẹ, ẹ, Ẻ, ẻ, Ẽ, ẽ, Ế, ế, Ề, ề, Ể, ể, Ễ, ễ, Ệ, ệ, Ỉ, ỉ, Ị, ị, Ọ, ọ, Ỏ, ỏ, Ố, ố, Ồ, ồ, Ổ, ổ, Ỗ, ỗ, Ộ, ộ, Ớ, ớ, Ờ, ờ, Ở, ở, Ỡ, ỡ, Ợ, ợ, Ụ, ụ, Ủ, ủ, Ứ, ứ, Ừ, ừ, Ử, ử, Ữ, ữ, Ự, ự, Ỳ, ỳ, Ỵ, ỵ, Ỷ, ỷ, Ỹ, ỹ
U+5829 堩 (uni5829-CN): ⿲土忄亘 → ⿲土忄亙 (⿲土忄亘 is U+21377 𡍷)
@acuteaccent: With regard to the glyphs for 〈, 〉, 〈, 〉, 《, 》, 「, 」, 『, 』, 【, 】, 〔, 〕, 〖, 〗, 〘, 〙, 〚, and 〛, this topic was already discussed in a different context, and the conclusion was that it is the layout engine's responsibility to invoke the 'halt' (for horizontal layout) or 'vhal' (for vertical layout) to get half-width versions of these characters whose glyphs are full-width by default. Because the glyphs for Korean hangul are monospaced and close in width to full-width, half-width metrics will work, and are desirable.
BTW, the revised "UI suggestion" for these two GPOS features will read as follows: This feature should be off by default. However, implementations conforming to Requirements for Japanese Text Layout (JLREQ [21]) or similar CJK text layout standard that expect half-width forms of characters whose default glyphs are full-width should turn on this feature by default, or selectively apply this feature to particular characters that require special treatment for CJK text layout purposes, such as brackets, punctuation, and quotes.
@acuteaccent: With regard to the suggestion to make the glyphs for U+2018 and its three friends proportional width, please see Noto CJK Issue 5 in which we seem to be driving toward making the glyphs for these four characters proportional across the board. I'd rather not implement a contextual feature, because it will fail at the worst times, and will be difficult to override when it does fail.
@acuteaccent: With regard to the CN glyph for U+5829 堩, this is yet another GB 18030 representative glyph error. I have noted this error for the Version 2.000 update. Thank you.
I disagree with the suggestion made in Issue #136.
Source Han Sans should prioritize the characters that are used today, not the ones that were used in archaic documents. In other words, characters need to be selected based on the contemporary/modern usage, not on the historical/archaic usage.
There are thousands of characters that appear in archaic documents but are never (or very rarely) used today. Adding glyphs for such archaic (or very rarely used) characters to Source Han Sans will not be that efficient. Keep in mind that the glyph set of Source Han Sans is almost full; unused glyphs need to be used wisely.
And in regard to that particular issue (Issue 136), there is no guarantee that the Wikisource document has no typos or errors. There might be typos or errors.
Even books that are published today sometimes have typos or errors, even though they are carefully proofread and reviewed before they get published.
It is very unlikely that the Wikisource document was carefully proofread and reviewed.
@kenlunde
Regarding U+5829 and U+21377, the glyphs are currently distinct in unicode standard 9.0.
Do we need to raise this issue via IRG?
@hfhchan: The U+5829 issue outside the context of Source Han Sans is a GB 18030 issue, and doesn't involve the IRG. I sent to China an error report for this character. Both characters have G and T sources.
U+4E35 丵 the horizontal lines are asymmetric
罪(U+7F6A, CN) symmetry broken
The nominal form of U+D7B1 ힱ (CID+58739) seems to be too compressed. It does not have to be like that, as it is a standalone form. Compare with Malgun Gothic:
I suggest making the glyph taller, like that of Malgun Gothic.
Among the nominal forms of hangul jamo, the first stroke (short vertical stroke) of yesieung (ㆁ) is inconsistent in terms of its length.
(characters used in image: ᇬ ᇭ ᇮ ᇯ ᇱ ᇲ ퟛ ퟵ ퟶ)
These can be roughly divided into two groups:
- ᇬ, ᇭ, ퟵ, ퟶ – too short
- ᇮ, ᇯ, ᇱ, ᇲ, ퟛ – okay
The first strokes of yesieung in the first group clearly need some adjustments. I suggest making them longer, to show more clearly that this is yesieung (ㆁ), not ieung (ㅇ). More specifically, I suggest the length to be the same or similar to that of ᇯ.
(Keep in mind that I am only talking about the nominal forms. The glyphs with ".[lvt]jmo0[1-6]" attached at the end of their names do NOT need adjustments like this.)
Thank you, and noted for the nominal glyphs for U+11EC, U+11ED, U+D7F5, U+D7F6, and U+D7B1.
The CN glyph of 民 is not center aligned. Seems that the alignment is inherited from the JP glyph.
Good catch. Noted. Thank you.
Currently, both 彳(U+5F73, a CJK unified ideograph) and ⼻(U+2F3B, a Kangxi Radical) map to CID 17771. The glyph is inclined to the left side, which is fine for the radical U+2F3B. However, 彳(U+5F73) is actually a word used in ancient Chinese (like 彳亍), so the glyph should be in full size and center aligned. I am not sure about JP and KR, but this should at least apply to CN and TW.
I agree. Noted. And, thank you.
U+257E0 𥟠 : ⿰禾皆 → ⿰禾𣅜 (⿰禾皆 is U+7A2D 稭)
Noted. Thank you.
Incorrect Shape for 徵:
(Left PMingLiU, Middle SHS, Right Expected).
The center bottom component is 𡈼, not 壬. 𡈼 plays a phonetic role.
Noted. A new TW glyph for U+5FB5 徵 (uni5FB5-TW) will be added.
should be 門兵 and not 門共, as discussed on twitter here https://twitter.com/eisoch/status/825621764633923586
Thank you, and noted.
The top left component of TW's 肄 (U+8084) doesn't seem right. Seems the shape should be the same as that in 疑.
| Current | Proposed |
|---|---|
 |
 |
Not a bug report per se, I would like to suggest to improve the composition of some characters in TW (or CN when they're shared). From the screenshot, you can see that the TW glyphs look like as if the components are just stacked together. The characters don't look like as a whole - for some, one can nearly draw a vertical line between the components to separate them apart. This is less an issue for infrequently used characters, but I hope that at least 均 (U+5747) can be improved. Thanks!
This is about the glyph of U+4CA4 䲤 in the TC version.
As ⿰鱼酒 and ⿰魚酒 are officially separated, one shall not use U+4CA4 for ⿰魚酒. Mapping the ⿰鱼酒 glyph to U+4CA4 (and at the same time, keeping the ⿰魚酒 glyph to U+9FD0 鿐 only) for the TC version helps users not to use U+4CA4 for ⿰魚酒.
It seems that the TC version of Source Han Serif maps ⿰鱼酒 to U+4CA4 and ⿰魚酒 to U+9FD0 only. This should be applied to Source Han Sans as well.
The difference in behavior for U+4CA4 in Source Han Sans and Source Han Serif is due to the lack of meaningful HK support in the current version of the latter. U+9FD0 is included in both typeface families because it is in the URO. Also, I am of the opinion that it is okay to map U+4CA4 to the glyph for ⿰魚酒 for Traditional Chinese fonts, because a non-zero number of implementations may expect it. I am, however, considering a change for the Version 2.000 update.
Well, such implementations are just simply not catching up; they are just behind. In order to make (or force) such implementations catch up and to get rid of (or minimize) possible confusion, the ⿰鱼酒 glyph should definitely be mapped to U+4CA4 in the TC version as well.
A quick google returns nil meaningful results - either mojibaked documents or dictionary websites pulling data from Unihan. The character U+4CA4 is effectively unused on the web.
The nominal forms of leading consonants (choseong) and trailing consonants (jongseong) of conjoining hangul jamo need to be distinguished, like those in Malgun Gothic, HCR Dotum/Batang LVT, and Source Han Serif.