Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidation of Glyph Redesign Suggestions #36

Open
kenlunde opened this issue Apr 11, 2017 · 92 comments
Open

Consolidation of Glyph Redesign Suggestions #36

kenlunde opened this issue Apr 11, 2017 · 92 comments

Comments

@kenlunde
Copy link
Contributor

kenlunde commented Apr 11, 2017

This issue is meant for tracking and submitting suggestions for redesigning glyphs, meaning that the glyphs are technically correct in structure, but could benefit from adjustment in order to become more usable for more languages or regions, or simply for aesthetic reasons (see the note below).

Please do not use this issue to nitpick the typeface design. Keep in mind that there are 64K glyphs in this typeface, which provides a live's worth of nitpicking.

Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

  • Adjusted the final stroke of the JP glyph for U+6C2B 氫, uni6C2B-JP, to be better balanced.
  • Adjusted the right-most vertical stroke of the JP glyph for U+595C 奜, uni595C-JP.
  • Adjusted the JP glyphs for U+3D93 㶓 and U+81F7 臷, uni3D93-JP and uni81F7-JP.
  • Adjusted the JP glyphs for U+507D 偽 and U+70BA 為, uni507D-JP and uni70BA-JP, respectively, to be better balanced, and adjust the CN glyph for U+6E88 溈, uni6E88-CN, in the same way.
  • Adjusted the TW glyphs for U+511A 儚, U+5922 夢, U+61F5 懵, U+750D 甍, U+858E 薎, U+85A8 薨, U+8609 蘉, and U+9138 鄸, uni511A-TW, uni5922-TW, uni61F5-TW, uni750D-TW, uni858E-TW, uni85A8-TW, uni8609-TW, and uni9138-TW, respectively so that their common Radical Design suggestions for character U+5BEB 寫 and U+95DC 關 #140 component is more proportionate.
  • Adjusted the TW glyph for U+7AC5 竅, uni7AC5-TW, so that the top and lower-left components are less wide.
  • Adjusted the CN glyphs for U+596E 奮 and U+5957 套, uni596E-CN and uni5957-CN, respectively, so that at least the two middle horizontal strokes are the same length, though the top one may need to remain short.
  • Adjusted the TW glyph for U+FF0C ,, uniFF0C-TW, by making its shape the same as the JP glyph, uniFF0C.
  • Adjusted the CN glyph for U+FF1B ;, uniFF1B-CN, by making its comma component the same as that of the JP glyph, uniFF1B.

Post Version 1.001:

  • Consider redesigning the glyphs for bopomofo per Issue Super OTC Part 2 link does not point to SourceHanSerif.ttc.z02 #17
  • Consider redesigning the TW glyphs that contain 辶 as a component per Issue lower part of 辶 looks weird in TC #15.
  • Consider adjusting CN glyphs for design consistency per Issue Design consistency of the CN glyphs #29.
  • Redesign the glyph for U+3025 〥, uni3025, to better match the glyphs for related characters, such as bopomofo.
  • The counters of many CN and TW glyphs for ideographs are too wide.
  • Adjust the 寺 component of the CN glyph for U+5D75 嵵, uni5D75-CN, so that its two parts do not connect.
  • Adjust the TW glyph for U+FF0C ,, uniFF0C-TW, by shifting it slightly downward.
  • Adjust the JP glyph for U+7B01 笁, uni7B01-JP, to have better balance and proportions between the top and bottom components.
  • Adjust the TW glyph for U+85AA 薪, uni85AA-TW, so that the lower-right component is taller.
  • Adjust the glyphs for U+3191 ㆑ through U+319F ㆟, uni3191 through uni319F, to be generic in terms of weight (see Noto CJK Issue #159)
@hfhchan
Copy link

hfhchan commented Apr 11, 2017

image
Considering lengthening the last stroke of U+6C2B such that the character is better balanced. Original character on the left, demonstration on the right.

@hfhchan
Copy link

hfhchan commented Apr 12, 2017

image
There is an hinting issue for 14249 which manifiests as uneven downward strokes at 27px, 42px, 47px, 55px, 60px, 76px etc.

The reason is likely because of an overlapping-but-subtly different alignment zone (in red):
image

The following is the glyph data extracted by otfccdump:

"stemH": [
	{"position":179,"width":30},
	{"position":443,"width":30},
	{"position":568,"width":29},
	{"position":690,"width":29},
	{"position":792,"width":32.5},
	{"position":794,"width":31}
],
"hintMasks": [
	{"contoursBefore":0,"pointsBefore":0,"maskH":[true,true,true,true,true,false],"maskV":[true,false,true]},
	{"contoursBefore":1,"pointsBefore":14,"maskH":[true,true,true,true,false,true],"maskV":[true,false,true]},
	{"contoursBefore":1,"pointsBefore":26,"maskH":[true,true,true,true,true,false],"maskV":[true,false,true]},
	{"contoursBefore":2,"pointsBefore":8,"maskH":[true,true,true,true,true,false],"maskV":[true,true,true]}
],

Corrected version:

"stemH": [
	{"position":179,"width":30},
	{"position":443,"width":30},
	{"position":568,"width":29},
	{"position":690,"width":29},
	{"position":792,"width":32.5}
],
"hintMasks": [
	{"contoursBefore":0,"pointsBefore":0,"maskH":[true,true,true,true,true],"maskV":[true,false,true]},
	{"contoursBefore":2,"pointsBefore":8,"maskH":[true,true,true,true,true],"maskV":[true,true,true]}
],

I also found very closely overlapping hstems on many glyphs, however they seemed not to cause any problems if the starting position was within 1 point. I also noticed that the starting shape for 豎撇 and 豎 were slightly different across glyphs. Lastly, the CN glyphs had the 豎 consistently 1 point higher than 豎撇, I do not know if this is some kind of compensation for an optical illusion or that SinoType was somehow aware of a hinting issue.

@kenlunde
Copy link
Contributor Author

kenlunde commented Apr 12, 2017

With regard to the JP glyph for U+595C 奜, uni595C-JP, it is targeted for removal in Version 2.000 to make way for HK glyphs, so this issue is likely to become moot. Still, I will mark this glyph to be inspected.

In any case, how hinting influences the pixels that are ultimately displayed depends on several factors, such as the rasterizer that is being used, and the pixel size of the glyph. This is no different than mainstream CJK fonts. Our fonts, including Source Han, are built using our auto-hinter, and is considered the best in the industry. Still, there will be cases where such behavior occurs.

Also, "alignment zones" has a special meaning, and for CJK glyphs, they are placed well above and well below the actual glyphs. They are useful only for Western-style glyphs whose letterforms are aligned to specific points along the Y axis, such as the baseline, x-height, and cap-height.

@hfhchan
Copy link

hfhchan commented Apr 12, 2017

image
Last Dot for U+3D83 (㶃) can be a tad longer and ending more to the right so the character is better balanced.

@hfhchan
Copy link

hfhchan commented Apr 12, 2017

image

U+3D93 JP glyph (CID 5118) is rather unbalanced compared to U+3D93 CN glyph (CID 5119) (a rare time where the JP glyph being the odd-ball instead of CN glyph).

image

U+81DF (CID 34062) for comparison.

Being ommitted from the regional-subsetted fonts, it seems that CID 5118 is a candidate for deletion in 2.000. However its source is from JA (Unified Japanese IT Vendors Contemporary Ideographs, 1993), which may warrant its inclusion, should there be enough space.

@hfhchan
Copy link

hfhchan commented Apr 12, 2017

image

The last stroke for 34112 should be 提 instead of 橫.

image

Korea would benefit from this change, but the character is out of scope for SHS.

@kenlunde
Copy link
Contributor Author

The JP glyphs for U+3D93 㶓 and U+81F7 臷, uni3D93-JP and uni81F7-JP, are candidates for removal in Version 2.000 because they're outside the scope of Adobe-Japan1-6. Still, I marked them for adjustment.

@KrasnayaPloshchad
Copy link

Consider adjusting CN glyphs for design consistency per Issue #29.

This comparison can be done via glyphdiff:
https://www.v2ex.com/t/268649

@Explorer09
Copy link

Explorer09 commented Apr 13, 2017

Second ㇒ stroke in glyph 為 (U+70BA) (and related 偽 (U+507D), 溈 (U+6E88)) looks unbalanced and goes too right-hand side.

While Japanese people might get used to this style, Chinese and Taiwanese people do not. At least I would consider the "diving board" part of the third stroke (㇕) too long.

I would like to see the second (㇒) stroke be placed in a more balanced position, see SimSun's glyph, for example:

為 example in various fonts shipped in Windows

Strangely, the glyph of 媯 (U+5AAF) looks rather okay (for both Simplified Chinese and Traditional Chinese glyphs).

為偽溈媯 preview

@kenlunde
Copy link
Contributor Author

kenlunde commented Apr 13, 2017

@Explorer09: Thank you. 為 U+70BA and 偽 U+507D have only JP glyphs that are shared with the other languages. 溈 U+6E88 has only a CN that is also shared with the other languages. I will ask the designer to tune these three glyphs so that are useful for more languages.

@Buernia
Copy link

Buernia commented Apr 15, 2017

Suzhou numerals for five〥(U+3025) needs to be redesigned, it don't have the same designs as others, seems to be smaller and thinner, likes the design of bopomofo.

image

@hfhchan
Copy link

hfhchan commented Apr 16, 2017

image
The proportions the top of 28818 (U+77A2 TW) are rather unconventional; consider overwriting 28818 with the subpaths of 61705 (U+77A2 U+E0101 JP)

Edit:
image

8 other TW glyphs were identified which suffer from the same disproportionate "CJK RADICAL GRASS 3" component to varying degrees: U+511A, U+5922, U+61F5, U+750D, U+858E, U+85A8, U+8609 and U+9138.

@kenlunde
Copy link
Contributor Author

@hfhchan The TW glyph for U+77A2 瞢 is best handled by removing it (see Issue #38), and by mapping U+77A2 瞢 in the TW CMap resource to uni77A2uE0101-JP (see Issue #37). The other eight TW glyphs are marked for adjustment.

@kenlunde
Copy link
Contributor Author

@Buernia: Right. I agree that the glyph for U+3025 〥 is in desperate need for some typeface-designer love.

@hfhchan
Copy link

hfhchan commented Apr 17, 2017

image

The top part of 30339 (U+7AC5 竅 TW glyph) is way too broad and the top of the left and right part 敫 is unaligned. The bottom left 方 is too broad (JP and CN glyphs are just right).

A general issue about 穴 being too broad exists in most of the TW glyphs, but U+7AC5 is a common character and the broadness is exceptionally out of place.

@Goodust
Copy link

Goodust commented Apr 21, 2017

default

I found some inappropriate or incorrect characters when I use "思源宋体“.

@kenlunde
Copy link
Contributor Author

@Goodust: Thank you for the report.

For U+2CD9F 𬶟, that does look like a bug, especially because the Source Han Sans glyph matches that of HanaMinB and the Unicode code charts. I will confirm tomorrow by referencing 通用规范汉字表 (Tōngyòng Guīfàn Hànzìbiǎo), which is in my office (I am at home).

For U+2C7C1 𬟁, HanaMinB looks wrong.

For U+7808 砈, because it is a GE character and therefore not frequently used for Simplified Chinese, this will be deferred until Version 2.000, because an HK glyph will be added that can be also be used for CN (and TW).

@Goodust
Copy link

Goodust commented Apr 21, 2017

@kenlunde
For U+2CD9F 𬶟,there's a screenshot of 通用规范汉字表 which you can refer to.
default
For U+2C7C1 𬟁, I just mean the bottom of "鸟“ is too narrow so that the character looks uncoordinated.
For U+7808 砈, I agree with your suggestion.
Have a good Day~

@tamcy
Copy link

tamcy commented Apr 21, 2017

627f-sample

The last stroke of 承 (U+627F) in TW (19114) can be extended. In fact it should be ok to map to CID19113 so that four regions share the same glyph.

  1. The left and right components in 承 and 丞 are the same historically.

627f-evi-1

  1. As shown in MoE's stroke order learning website, the rightmost component of 承 consists of 2 strokes. It looks like a one-stroke component just because the last stroke is compressed.

627f-evi-2

  1. Thus, the design of the component should be consistent with that of other similar glyphs. No need to use a separate deign for 承. The current design look unnatural.
    627f-evi-3

@tamcy
Copy link

tamcy commented Apr 21, 2017

Horizontal strokes at the middle of 奮 and 套

stroke

The 隹 component in 奮 and 镸(upper part) in 套 have 4 horizontal strokes. When written, the length of these strokes would be: D > A > B = C.

u596e u5957

In situations like 奪 and 套, A is shortened to accommodate to fit better with the last stroke of 大. However, current CN glyph tends to adjust the length so that A < B < C < D, resulting in a slope. This looks a bit weird.

I suggest to follow the design of JP/KR such that B and C are of the same length. A can also be widened to make it closer to B and C.

奮, which looks good for CN, is also included for comparison.

@hfhchan
Copy link

hfhchan commented Apr 21, 2017

image
Figure: CN / TW / JP / JP-transplanted-on-TW

34952 (U+8388-TW) could have an instant facelift by transplanting the bottom part of the JP glyph (34950) right on top of it -- before 34950 is removed in version 2 ;).

@jihnenglin
Copy link

(1)
The hook in the JP and KR glyph for 四 is present but is generally missing in glyphs for characters containing 四. To name a few,

泗駟瀆犢竇續讀贖黷

(The character 𧶠, which differs from 賣 in JP and KR, is composed of 士, 四, and 貝.)

2

(2)
The major component of the KR glyphs for 竇, 續 and 讀 should be 𧶠 instead of 賣.

1

@kenlunde
Copy link
Contributor Author

@jihnenglin ① This is simply variation within the typeface design. ② KS standards are notoriously inconsistent—not only between versions, but also within each version—in terms of the components that are used, and the 𧶠 versus 賣 case is a prime example. When I determined the mappings for Korean, which included determining which new KR glyphs were necessary, I intentionally made these components consistent within the scope of our declared KR support.

@tamcy
Copy link

tamcy commented Apr 23, 2018

As per this comment in adobe-fonts/source-han-sans#182, I suggest to consider unifying the ⺮ radical for all regions, using the form that the dots are connected to the horizontal line above. I'm mentioning it here just because I'm afraid that it would be overlooked. Thanks.

@kenlunde
Copy link
Contributor Author

While it is likely too late for Source Han Sans Version 2.000, because it is too far along, this is something that I am considering for Source Han Serif Version 2.000, and for a future version of Source Han Sans. I consider this regional difference insignificant enough to ignore.

@cathree3
Copy link

常州华文设计态度恶劣,居然使用暴力加粗制作注音符号,请 Adobe 考虑是否继续与其合作。
2018-06-14 11 08 46
注音ㄋㄌㄑㄔㄘㄝ
假名るかくイちせ

@kenlunde
Copy link
Contributor Author

We are planning to work with Arphic (Taiwan) to completely redesign the glyphs for bopomofo as part of the Version 2.000 update, which will also take WG2 N4980 into account.

@tamcy
Copy link

tamcy commented Jul 16, 2018

Please consider redesigning the full-width question mark so that it rhymes with the half-width glyph. The half-width design can not only make the font more unique, but can also help in contexts where both half-width and full-width forms are used together.

questionmark

@frankrolf
Copy link
Member

The question mark is an interesting case, and I’m never quite sure what to do for the full-width version. I designed the full-width question mark based on the feedback from our Japanese designer, Ryoko Nishizuka. She pointed out the Fournier-style feels odd to the Japanese eye, and that a more straightforward version is generally preferred.

@tamcy
Copy link

tamcy commented Jul 16, 2018

Thanks @frankrolf for the insider story. So it looks like there's a cultural difference here. In Hong Kong (where people mostly see Monotype HK fonts in publications, followed by TW fonts from Dynalab), similar design of the glyph can be found easily:

untitled-2

MSungHK-Light is widely used in HK printed newspapers, magazines, books, mangas etc., and its question mark design is unlike the ordinary form. Perhaps this is why I don't find the Fournier-style question mark foreign. They aren't identical, but this exactly means that the design of this glyph in Source Serif gives the font a unique character. If the current design isn't to be changed, I hope that the Fournier-style design could be considered to be included as an alternative glyph.

@tamcy
Copy link

tamcy commented Sep 21, 2018

I'm including three characters in this report (one has already reported by @hfhchan), but it may point to a more generic issue. I first thought that certain TW glyphs (maybe also CN glyphs) have chosen to part from the original design to compensate the difference in usual reading requirements between Chinese and Japanese (as most of these glyphs have a higher horizontal centroid, and the whole glyph tends to look smaller visually), though I'm not sure if it's a good idea for a Pan-CJK font, and I don't have enough evidence to support this observation.

In any way, the rearchitecting of 空 (U+7A7A) 穿 (U+7A7F) and 突 (U+7A81) for the TW region seems gone too far. I'd suggest it to stick closer to the original design. For 空 I'm bugged by three issues: (i) the much higher/taller 工 component makes it look unnatural, (ii) the drastic change in the horizontal centroid affects reading, (iii) I'm not sure about the reason behind shortening the horizontal strokes, which changes the "atmophere" of the glyph - now the ligher lower component 工 doesn't seem capable of supporting the heavier upper component 穴. The 空 components in other glyphs also received similar treatment, though at a lesser extent.

untitled-1

@kenlunde
Copy link
Contributor Author

@tamcy I made a note about this. Looking at the corresponding CN glyphs for these three ideographs, they would require similar adjustments, and my note includes that.

@hfhchan
Copy link

hfhchan commented Sep 22, 2018

@kenlunde the taller 工 for 空 in the CN glyphs is typical for classic CN fonts because CN shape of 穴 at the top is shaped differently from the TW/HK or JP/KR glyphs. The tall 工 gor CN could be kept as is but the TW/HK one should match JP/KR more closely.

@KrasnayaPloshchad
Copy link

常州华文设计态度恶劣,居然使用暴力加粗制作注音符号,请 Adobe 考虑是否继续与其合作。

看到这里,我发现韩文也是使用暴力加粗制作的,粗体字起笔收笔的笔锋都不太自然。
screenshot_2018-09-26 source_han_serif svg png png 1280x960
原图在这里

@kenlunde
Copy link
Contributor Author

We have received exactly zero complaints about the glyphs for hangul from Korean users, so making such a claim seems baseless. In fact, we have heard nothing but praise.

But yes, we are aware of the Chinese issues, which will be addressed as part of the Version 2.000. Due to the broad scope of the issue, Version 2.000 is likely to take time to complete.

@tamcy
Copy link

tamcy commented Dec 9, 2018

This is a suggestion to the forthcoming Source Han Serif HK. I would like to make an unusual attempt to suggest to at least adopting the CN version of the “compressed-女” component for HK.

Here shows the designs of the 女 component for TW, HK and CN as per their respective standards:

As shown, each region has two variations for this same component. The first row is the “normal” or “uncompressed” version. The second row, which is a variant form of the first row, is used when the component is positioned on the left side of other components. The interpretation is that when placed such way, certain strokes of 女 will be “compressed”, causing its form to change:

Region Difference to the normal, uncompressed version
CN The horizontal stroke is pushed so that it doesn’t protrude the left-ward stroke
TW The horizontal stroke is pushed so that it become slanted
HK The horizontal stroke is pushed to become slanted and doesn’t protrude the left-ward stroke

For certain characters discrepancies do exist between regions. For instance, a compressed version is used for 嬲 and 魏 in CN and TW, while the uncompressed version is used for HK.

Similarly, for 威, CN uses a compressed version, while HK and TW uses the uncompressed form:

I suggest to follow HK’s convention to choose which form is to be used. This suggestion is about how a particular form (compressed or uncompressed) would look like.

Current design in Source Han Sans HK

The design of the compressed-女 component is different between HK and TW. That said, Source Han Sans HK in version 2.000 doesn’t follow the design outlined in HK’s reference glyph document. Instead it uses TW’s “compressed-女”, so that most of the glyphs can be shared with the TW version.

The decision is probably due to the constraint of the available CIDs in an OpenType font. As their form only differ in a small way, it may not be economical to create a whole new set of HK glyphs for characters having this compressed-女 component (which would cost around 306 new glyphs). I believe similar sharing attempt will be adopted in Source Han Serif HK, which motivate me to write this suggestion.

The Suggestion

Since Source Han Serif HK may not use the “compressed-女” specialized for the region, I’d like to suggest it to use CN’s “compressed-女” component instead of TW’s. In my opinion, the TW and HK versions of this “compressed-女” component are not suitable for serif and sans-serif typography. HK version looks better, but not much. After all, this design inherits too many features from script writing, making it looks a little bit weird (to put it mildly).

Some might think me crazy, but I’d like to argue that CN version of the “compressed-女” isn’t that far away from the HK version. If the TW version is deemed appropriate for HK, then CN version should also pass:

Additionally, according to the first page of the 香港電腦漢字參考字形 document, “常用字字形表(二零零零年修訂本)” (List of Graphemes of Commonly-used Chinese Characters, 2000 ed.) is the primary reference of the character shapes. Here are some of the characters written in 常用字字形表:

You can see that the style isn’t exactly the same (they’re hand-written after all). It is understandable for 香港電腦漢字參考字形 to choose one form and apply it to all other glyphs for consistency, but what’s shown in 常用字字形表 indicates that the stroke difference isn’t of extreme importance when talking about whether a form is suitable for the region.

The Numbers

I have roughly gone through the characters with the 女 component available in the current Source Han Serif font. Here are the number of glyphs sharable if the form of a particular region is to be used:

Unc. 女 Comp. 女 Sharable glyphs (Big5) Sharable glyphs (HKSCS) Total
TW TW 130 (U) + 270 (C) = 400 0 400
TW CN 130 (U) + 227 (C) = 357 0 (U) + 76 (C) = 76 433
CN CN 65 (U) + 227 (C) = 292 8 (U) + 76 (C) = 84 376

This suggestion is mainly about adopting CN version of “compressed-女” (BTW I’m calling it CN version due to the scope of this typeface; such a style is used by most of the fonts in HK), while keeping the TW form for “uncompressed-女”. So the second row is what I am mainly proposing here.

For Big5, there are 43 less glyphs sharable if the CN’s compressed 女 component is used. But if the HKSCS characters are taken into account, there’re actually 33 more glyphs sharable than TW.

Closing

As a Hongkonger it’s a difficult suggestion for me to make. I’m still writing this because I believe that the suggested form will be approachable to a wider audience.

Just a side note: The combination of CN + CN for HK glyphs are also listed in the above table (the 3rd row). In fact I’d prefer the CN version to be used even for the normal version, although I know it is even less possible for this project. This is closer to form generally seen, which can also be found in GCCC-2000:

Thanks!

@hfhchan
Copy link

hfhchan commented Dec 9, 2018

I would second the proposal by @tamcy , and agree that CN-CN version looks better. The CN form (or the JP/KR form) is definitely more popular (or even the only form) in commercially successful fonts in Hong Kong.

It is very hard to consistently write 女 with an overshoot or not, and either form would be recognizable with users; so the selection of which form to use in HKSCS-2016 was, as usual, based on logistical concerns of minimizing the number of glyph changes necessary compared to the working font by Dynacomware. The form was not consistent in HKSCS-2008 and before.

@tamcy
Copy link

tamcy commented Dec 16, 2018

A few more suggestions on the upcoming HK glyph set:

  1. On the component 尺. In Source Han Sans I had reflected that the current form in other regions could be used, no need for a separate HK form. Although the current HK form is to be kept in Sans, I hope this can be considered for Serif. The form with last stroke shifted to the right has been explicitly mentioned in the Reference Glyph document (page 8) as an acceptable/standard compliant form: p8

  2. On component touching. I suggest to at least treat the touching behavior of the following components as a design, not regoinal difference:

    • How the dots 丶 touch (or not touch) the other strokes in components like 夕, 求, 羽, 立, 恆, 夜, 亠 (e.g. 主), 亙. Seems this is already the case in Serif.

    • Whether the “90°rotated 卄” component touches lower component 口, so that JP glyphs of 倜, 啁 can be used for HK.
      20181216-serif- -fix
      (fixed on 22 Dec: should be 啁, not 凋)

    • For characters comprising 丕, Non-TW regions (including HK) adopt a form where the vertical stroke of 不 isn't touching the bottom horizontal stroke, while TW glyph set uses the touching form. But the result in TW isn't consistent due to glyph sharing. As the disjointed form can actually be used for TW glyphs, I’d suggest to consider sharing the design cross all regions (Only U+5CAF 岯, U+80DA 胚 and U+82E4 苤 need adjustment, others can use JP/CN glyphs) (Fortunately it doesn’t adopt TW’s reference form where the dot touches the vertical stroke in 不. )

  3. Hong Kong reference glyph uses a diagonal stokes for 卝 (歡, 寬) and 卄 (𡪨) as in 艹. Suggest to NOT follow this this design and use vertical strokes instead (such that the glyph design can be shared with TW).

  4. Ignore the slightly slated horizontal stroke when 彗/慧 is positioned on the right (e.g. 槥) so that TW glyphs could be used.

By the way, I have published a project which contains JSON-formatted data derived from the Reference Glyphs for Chinese Computer Systems in Hong Kong. Specifically, it contains information whether a codepoint is marked as different from the TW-MoE standard. Not use if this can help in preparing the HK variant of the font, I'm posting it anyway.

@stone-zeng
Copy link

The terminal of the final stroke in U+5FD9 忙 is not smooth:

image

The similar situation appears in many other glpyhs. Is it by design?

@Man-Ting-Fang
Copy link

@stone-zeng I believe it is by design. This is the Japanese or Korean version of U+5FD9, right? The final stroke is "vertical and anticlockwise curve" (豎曲/竖曲), not "vertical and horizontal" (豎橫/竖横), and the unsmooth terminal is one of the characteristics of this stroke (at least in the serif style) and is used by many fonts designed for J/K/TC. The "vertical and anticlockwise curve" stroke is merged into the "vertical and horizontal" stroke in the standard of Simplified Chinese, but the glyph you show is simply not the SC version.

@stone-zeng
Copy link

stone-zeng commented Apr 4, 2019

@Man-Ting-Fang As you pointed, this is the Japanese version. I know the final stroke should be 豎曲/竖曲, but still the design of Source Han Serif is strange. Compare with the same glyph in Kozuka Mincho Pr6N R (a Japanese font by Adobe):

image

I think one of the two points in the orange box (see my previous comment) is redundant.

@kenlunde
Copy link
Contributor Author

kenlunde commented Apr 4, 2019

@stone-zeng & @Man-Ting-Fang: I will ask our designer to look into this issue. While Kozuka Mincho is considered a different design, I agree that the terminal of the Source Han Serif seems a bit odd.

@be5invis
Copy link

@kenlunde @stone-zeng Rounding error?

@MY1L
Copy link

MY1L commented Jan 16, 2024

We are planning to work with Arphic (Taiwan) to completely redesign the glyphs for bopomofo as part of the Version 2.000 update, which will also take WG2 N4980 into account.

“作为2.000版更新的一部分,我们计划与文鼎合作,完全重新设计注音的字形,……”
@kenlunde 请问,这个似乎没有实现?是否中间遭遇了什么变故?如果没有意外,SourceHanSerif以后会修改吗?

我最近在改善思源宋的“谚文汉字”㐃㪳㔔㫈…等(附带考据),可以提供这些字形修改后的源文件:
㐃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests