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

lower part of 辶 looks weird in TC #15

Closed
1abcd opened this issue Apr 6, 2017 · 5 comments
Closed

lower part of 辶 looks weird in TC #15

1abcd opened this issue Apr 6, 2017 · 5 comments

Comments

@1abcd
Copy link

1abcd commented Apr 6, 2017

default
The yellow circle shows the intersection part is too small or too thin.

@kenlunde kenlunde self-assigned this Apr 6, 2017
@kenlunde
Copy link
Contributor

kenlunde commented Apr 6, 2017

Thank you for the feedback.

The heavier the weight, the greater the contrast. Source Han Serif is somewhat unique in that it provides seven weights, from ExtraLight to Heavy. At the lighter weights, which have less contrast between the horizontal and vertical strokes, the intersection point is more obvious.

Also, the provided examples differ is both style and relative weight, making the comparisons more subjective.

Until I receive substantive comments to the contrary, and get feedback from the designers, I am labeling this as designed. I'll leave the issue open for the time being.

@tamcy
Copy link

tamcy commented Apr 6, 2017

As the original reporter of a similar issue in Source Han Sans, I feel tempted to write something here 🙂.
(My apology if what I'm writing isn't what the original author is referring to)

As some may know, the MoE and HK glyph standard is mostly about bringing the script form (手寫楷書/hand-written Kaishu) to other font styles. In English world, it would be analogous to setting a single-storey "a" and "g" in Serif fonts like Times New Roman as the standard form.

I am actually okay with this approach. For some components it looks really good and more modern than the traditional form. That said, I still think that it's better for some components to not follow the stroke of Kaishu too strictly. I feel that sometimes the authority has gone too far to preserve consistency to the extent that aesthetics is sacrificed (but hey, it's not enforced anyway).

For instance, the standard requires the two vertical strokes of the grass radical 艹 to be rendered slanted in Song/Mincho style to mimic that of the Kaishu style. I am not a font designer, but I've once talked to a respected font designer who also agree that the form of this component, as requested in the standard, is plain ugly in Song style. But that's another story. Now back to the 辶 component. Let's compare how the component looks like in different language:

shserif-i15-01

Among the others, the 辶 component in TW is no doubt the most complicated one. The problem, as I see, is that the current design (following strictly the MoE standard) is seeking too much attention. It has the most contrast. It has the most eye-catching components (four triangle-like protrusion, others have two). It'd be easy to be distracted to notice its shape instead of the word. The thicker the weight, the more obvious the issue. And I suspect this is why some commercial font products, while adopting the same abstract form, decided to tweak its skeleton a little bit to play down the effect:

shserif-i15-02

So what if Source San Serif adopts this approach? I spent some time to play around with the curve and here's the result:

shserif-i15-03

(The stroke form of the lower left part is taken from the bottom part of "今" of TW)

This way, people are still able to identify the radical, but it is less attention-grabbing, probably because of the smoother stroke, lowered constract and less eye-catching components. To me, it looks more elegant and not over-complicated. An added advantage is that it resembles less the form of the infamous default serif system font in Windows, aka 新細明體 (MingLiU).

Now compare this modified version of 道 with other languages:

shserif-i15-04

I don't know about MoE, but this modified form is considered acceptable for HK glyphs, as indicated in the current draft of the latest "Guidelines on Character Glyphs for Chinese Computer Systems".

But again, I'm no professional on this matter. Hope that we can see the opinions from HK/TW font designers, as they're probably more familiar when this issue.

@extc
Copy link

extc commented Apr 8, 2017

heavy

I haven't seen this form before. It hurts my eyes! The 辶 is too exaggerating.
The Sungti standard provided by MOE leaves SPACE between 辶 and 首.
moe

compared with the sample GIF provided by CNS11643.
cns11643

The existing MOE style song font in the market are Dynacomware and Arphic.
Both show smooth curve of フ i.e. the intersection of the third stroke and fouth stroke
while Source Sans Serif emphasize there are 2 distinct strokes.

arphicsong

Since the Songti style always refers to the Kaiti. So please take a look at the Kaiti style of CNS11643 in the above picture. 首 plays more important role in 道. It is larger than 辶 and this makes sense. Threrfore, for 辶 radicals glyphs, 辶 component should diminish 20% width because it is too eye-catching right now.

@1abcd
Copy link
Author

1abcd commented Apr 10, 2017

I use my mother language to say my feeling.
The lower left of heavy weight 辶 seems broken in Source Han Serif.
我以中文來寫一下我的感受
粗體思源明體的辵字旁我看第一眼就是一種快斷掉的感覺
這種形狀看起來也站的很不穩

I think the 辶 component @tamcy modified is better.
@tamcy 修改的版本看起來簡單俐落,比較好看些

Ming typeface of Sanmin book company has made an impression on me. And I search for it. The 辶 component is just like regular script (楷體).
default
from http://m.sanmin.com.tw/Product/index/001628246
以前我印象高中時使用了三民書局的教科書
裡面的明體字很讓我印象深刻
上網找了一下,才發現是三民書局自己的創作

another ming typeface from an old pc game (year of 1995)
default

An example of a modern new font 金萱 (year of 2016), it didn't follow the MoE glyph.
default
from https://www.justfont.com/fontdetail/199

以上證明教育部明體(審美觀)以前沒有走入民間過 現在民間也不一定遵守
自 Windows Vista 內建後大家才習慣見到教育部明體 (教育部標準宋體)

@kenlunde
Copy link
Contributor

Consolidated with Issue #36.

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

4 participants