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

Incorrect form used for 父 in TW #376

Open
NightFurySL2001 opened this issue Jan 20, 2023 · 10 comments
Open

Incorrect form used for 父 in TW #376

NightFurySL2001 opened this issue Jan 20, 2023 · 10 comments

Comments

@NightFurySL2001
Copy link

NightFurySL2001 commented Jan 20, 2023

According to 國字標準字體, the top part of 父 should not be connected to the bottom part.

下撇、捺不與上兩點相接
image

Action

The three characters (斧爸釜) currently using the CN form should be remapped to the JP form. A new glyph might be required for 斧. The same modification was already done to HK except 斧 for consistency (#202 (comment)).
image

Remap TW & HK: 爸釜, New glyph: 斧

Extra

For best consistency, it is probably better to abandon the CN 父 for the three characters (斧爸釜). The CN glyph for 爹爺 is not connected too (notice the 多 and 耳). Also, all reference forms provided officially has the stroke disconnected.
image
Reference from Unicode and official documents/compliant fonts:
image

Remap and remove TW, HK & CN: 爸釜, Edit CN glyph: 斧爷

@celleo
Copy link

celleo commented Feb 2, 2023

I'm no professional, just bumped into this discussion. So I'd share my absurd thoughts here: most Chinese writings are not fixed to one dedicated presentation style. Spaces between radicals in Chinese writings are most from aesthetic consideration. So you can find many characters in ancient Chinese handwritings are not fixed to one dedicated presentation style. I read somewhere before that some font strokes in design are deliberately connected to save occupied space and/or beautify the looking of the whole character. So I'd suggest, connect the strokes when the character is used as radical for small sized displays, disconnect the strokes for large sized cases. Otherwise if technically difficult, adopt the simplified CN connected implementation, especially for a Gothic font (simplified font style vs. traditional classical styles), for easier user reading experience without creating more spaces and small strokes.

And, I don't suggest font designers stick too much to the TW 國字標準字體:

反对意见 (quoted from Baidu Baike)
国字标准字体规定了过于严格的笔划规则,并仔细考证了文字的来源。
但有些常见的异体写法,如“内”虽然在字典里一直属于“入”部,但书法史上一向写成“内”,包括王羲之等人的文字。该重视来源还是重视长年的习惯,确实引起过争议。
另外,过于严格的笔划规则,也使得书法上为了美观所做的调整都变成了错误写法。
如,教育部推行之国字标准字体,只能说是取其某片段文字而非整体文字之综观,就如“月”的肉字偏旁在书法上以楷书写为“月”字,但是行楷及行草才是采用上点下勾。而“充”字上部却书写为“一+ㄙ”而非“ˋ+一+ㄙ”,不符合历朝多数楷书古帖写法。 (国字标准字体采用前者写法原因是因为《康熙字典]》等字书多以三笔计算“充”字上部,而《康熙字典》以三笔计算的原因则是因为“充”字上部在篆体是“子”的颠倒,而“子”字三笔。国字标准字体制定时,大部分的文字有去考量笔画数应与《康熙字典》等字书一致。)
部分人士认为此类将汉字完全依照字书笔数、字源严谨规范的结果,反而失去文字之美。
又此标准是以楷书为母体制定而成,部分人士认为将国字标准字体套用于明体等印刷用字体上,反而会破坏该类字体原本设计阅读上的平衡感,而为了楷书(手写字体)与宋体(印刷字体)的统一,国字标准字体(标楷体)亦套用部份宋体字形。

More please refer to Zhihu topic https://www.zhihu.com/topic/19587919/top-answers

@hfhchan
Copy link

hfhchan commented Feb 2, 2023

I will strongly suggest that Source Han Sans do not join the strokes for 父 under any circumstances. This will make all the glyphs consistent with the existing JP glyphs, comply with the mandatory PRC standard, and be consistent with the Taiwan MOE standard.

Whether or not the Taiwan MOE standard is controversial should not be a concern here. The CN forms have compulsory standards which they need to adhere to, and the Taiwan MOE standard is consistent with it. There are no grounds for including extra glyphs that deviate from the Taiwan MOE standard.

@celleo
Copy link

celleo commented Feb 3, 2023

I will strongly suggest that Source Han Sans do not join the strokes for 父 under any circumstances. This will make all the glyphs consistent with the existing JP glyphs, comply with the mandatory PRC standard, and be consistent with the Taiwan MOE standard.

Whether or not the Taiwan MOE standard is controversial should not be a concern here. The CN forms have compulsory standards which they need to adhere to, and the Taiwan MOE standard is consistent with it. There are no grounds for including extra glyphs that deviate from the Taiwan MOE standard.

Please read this Zhihu topic. Taiwan MOE standard is consistent with others??? And except the recommended standard "GB/T 14245.2-2008" 64x64 dot-matrix glyphs (refer to the picture posted below), I can find nowhere the PRC mandatory standard of Hei (Gothic) font... As far as I know, latest Chinese glyph related mandatory standard GB 18030-2022 standard only uses Song.

And, please be awared that the glyphs/writing of Kai or Hei has never been consistent with each other besides Song. I believe, during the long evolution of printing glyphs, the basic and top priority rule of a font should be from aesthetic point and main stream usage (considering major parts of most characters have been fixed and stable during long history of usage), instead of rigidly sticking to the "source" of glyphs (if archeologic sourcing is the rule, all Chinese characters should be restored back to original Shang Dynasty shell-bone glyphs or even earlier Neolithic glyphs, without evolving to later Zhuan/Li/Kai/Xing/Cao, not mentioning Song/Ming fonts invented for printing usage). Below picture is part of the evoliton of "父". Which one should we adopt, connected or disconnected?
image

父字头黑体点阵
With glyph stroke complexity grows, the spaces are compressed and finally connected. (GB/T 14245.2-2008 64x64 dot-matrix Heiti)

@hfhchan
Copy link

hfhchan commented Feb 3, 2023

Taiwan MOE standard is consistent with others???

As far as this issue is concerned, the request by the MOE standard to use the unjoined form of 父 is consistent with the GB standards.

Latest Chinese glyph related mandatory standard GB 18030-2022

GB 18030-2022 is a character set standard, not a glyph standard. The only glyph standard in force now is 《通用規範漢字表》 which supersedes all previous glyph and orthographic standards.

The basic and top priority rule of a font should be from aesthetic point and main stream usage.

The designers of Source Han Sans have chosen to use the non-joined form in the JP region, which is also consistent with the JIS standards.

I do not understand what your proposal is. Are you suggesting that the JP forms should be modified to use the joined form for characters where 父 is compressed? There does not seem to be a strong argument for having the CN region and/or TW, HK regions to be supplied with extra glyphs which use a joined form, in violation of the CN mandatory standards and TW standards.

some font strokes in design are deliberately connected to save occupied space and/or beautify the looking of the whole character.

That is definitely true but note currently the joined forms are used for characters which have plenty of space, while the more compressed ones use the separated forms. This is directly contrary to what you suggest here.

@NightFurySL2001
Copy link
Author

NightFurySL2001 commented Feb 3, 2023

@celleo Notice the top row of these glyphs: all CN glyphs are specially made for CN (爹 has difference in 多; 爺 has difference in 耳; a new CN glyph with minor difference was used for 父). Characters with more condensed stroke used separate 父, while those with more space used combined 父.
image
This is indication that the font designers at Changzhou SinoType probably did not have an idea on which form to use.

Here are some points as to why we should use the JP separated 父 design:

  1. If we are to follow the original design of the Source Han Sans design, the form with 父 separated is the form that should be used.

  2. Song/Hei difference is insignificant here so it is better to take the standard Song and carry it over to Hei.

  3. All official standard featuring Hei (showin in picture is GB/T 13848-1992 《图形信息交换用矢量汉字黑体字模集及数据集》) shows a separated form, as well as Microsoft YaHei as approved by the government agencies.
    image

  4. TW MOE form suggest to use the separated 父 design too. The current form is wrong in terms of this.

  5. Current HK switched from CN to JP design due to aesthetics.

  6. Unifying this design difference between CN and JP to JP is the least minimal work: remapping CN, TW and HK to JP, and adjusting two glyphs (爷斧(CN)). It also frees up 2 glyphs. [using CN form will require adjusting 5 glyphs: 斧(JP)爹(JP)爺(JP)爹(CN)爺(CN), while using the inferior design of 爸 and 釜 for JP and KR]

What should be done:

  1. Remap 爸釜 of CN and TW to JP. (or at least remap it for TW first)
  2. Remove CN 爸釜.
  3. Redesign 爷斧 of CN and use it for TW and HK. (cannot use JP 斧 due to difference in 斤)

P/S: I am not advocating the use of TW MOE 國字標準字體 in this font. It is way better to use a region-agnostic form such as Kangxi dictionary or the Inherited Forms Component Checklist. This issue is already discussed in #6 with a worse outcome.

@celleo
Copy link

celleo commented Mar 26, 2023

@NightFurySL2001 I surely agree with changing if it's based on aesthetic point, with space tuning by sizes/points instead of simply unifying all characters to use the same radical forms. This should be left to judgement of seasoned font designers, because I'm no designer, qualified with neither font expertise nor art education (so please don't ask me to give solutions)... If there should be any solution, I'd suggest turning to the real origin & standard of modern CN Hei font 印研黑一体. BTW, I disagree rooting the change to inappropriate standards or misunderstandings to standards:

  1. There is no official standard for CN Hei except "GB/T 14245.2-2008" as I mentioned before (on my short-time unprofessional investigation). GB/T 13848-1992 is older and revoked. All other standards including GB18030 use either Song or Kai. I guess the reason of lacking Hei in character related standards is, it's too detailed & rigid to allow the maturity of this young font, considering its short evolving history comparing to Kai's over thousand & Song's hundreds of years.
  2. GB 18030-2022 is the latest CN standard, for both character encoding and Song glyphs (included in its Appendix). 通用汉字规范表 is a 2013 standard which aims to regulate the essential Chinese radicals and strokes, not trivial details such as spacing or sizing of them. Please be aware we can always see this kind of keeping certain flexibility against rigid essential rules on official GB standards (mindset might be to avoid frequent changes introduced by later evolution during usage), which created some inconveniences like the famous half/full width confusion of the U+2018/U+2019 quotation marks.
  3. Don't simply copy from JP fonts. CN fonts have a different evolution route and mindset than JP ones, although Japan and Korea shared a long history using traditional Chinese characters till mid 20th century. I learned from this topic, 黑体字: Song, instead of JP Gothic, is the major contributor during the evolution of Hei, carrying different formation traits from Japan gothic fonts (although it did inspire Hei a lot).

@NightFurySL2001
Copy link
Author

NightFurySL2001 commented Mar 27, 2023

  1. As I do not have access to GB/T 14245.2-2008 (and 印研黑一体), the shown glyph is GB/T 13848-1992. However, both standards are/were considered official even though one is revoked, and both show the same glyph (as shown in your comment): 父 is disconnected. There should be no issues here using an outdated standard when it is showing the same glyph.
  2. GB 18030-2022 does not determine the glyph standard of Chinese characters. 通用汉字规范表 is the only standard that China is using for glyph standard; GB 18030 did not specify any official status of the reference glyph it provides.

Quote from GB 18030:

字符 character:供组织、控制或表示数据用的元素集合中的一个元素。

It does not specify the glyphs provided are normative, the glyphs are only for reference. As the name of GB 18030 suggest: Information Technology—Chinese coded character set, it only deals with encoding, not presentation (fonts).

Quote from official announcement of 通用汉字规范表:

社会一般应用领域的汉字使用应以《通用规范汉字表》为准

Quote from 百度百科 规范汉字:

2013年6月5日,国务院发出关于公布《通用规范汉字表》的通知,明确了规范汉字的标准。

百度百科 通用规范汉字表:

体现着现代通用汉字在字量字级字形 等方面的规范。

实现了字形与用字的标准化。

第三,关于字形问题。字表对宋体字形进行了规范,依据《印刷通用汉字字形表》总结和制定了字形规则,对一些不符合字形规则的字的字形作了微调。字形调整的原则是:尊重汉字结构,遵循统一规则,严格控制特例。字形调整的原则和字形规则,不仅使表内字的字形保持了系统性,也使今后大批量汉字的字形整理有章可循,避免出现新的字形不统一现象。

This means that 通用汉字规范表 is a main reference of glyph (字形) standard, including the connection/disconnection of strokes.

Anyway, even if you want to think that GB 18030 is a glyph standard (instead of its original purpose of encoding standard), it still show 父 is disconnected in most characters.
image

  1. If you didn't notice, Source Han is based on Japanese Kozuka fonts. It definitely is a reason for the CN (and TW/HK) version of Source Han to reference the original JP design of Source Han. Also, there is a contradiction with the statement Song is major inspiration of Hei: if that is the case, then Hei is also standardized by Song, which as above mentioned is covered by 通用规范汉字表 (which shows 父 is disconnected).

Additional: even if not considering CN standard (as mentioned in the first comment in this issue), TW and HK still require modification on 父 component based on their own standards. Modifying CN is just an additional step that can be taken to free up CIDs and make 父 more consistent (as shown in picture: 父 in tight space like 爹爺 is disconnected but connected in 爷斧爸) with 通用汉字规范表 and GB 18030 (although not a glyph standard).

Unless you have anything more to provide regarding 父 component in Source Han (like glyph remapping/redrawing), any debates on which standard is appropriate and not appropriate is useless and just wasting our time: 通用汉字规范表 is the main glyph standard for China, GB 18030 only gives additional reference glyphs in place where 通用汉字规范表 doesn't cover (such as 繁体字 and 异体字) and the glyphs are not mandatory.

@celleo
Copy link

celleo commented Mar 29, 2023

I guess there was some misunderstandings & confusions in previous discussions. It might be brought by my poor expression in English (I was afraid of being accused by polluting Github with Chinese only text with limited audience). To be accurate and save time, Chinese wording might be appropriate:
首先,我并不反对做字形改变, 实际上我觉得指出这种不一致是一个很好的视角。考虑到我也不是字体相关的设计师或者工作者,所以我的观点也并不一定正确,也不是适合争论该怎么做的决策者。我只是从个人有限的认知出发,觉得这种修改应该是基于每个字的美感,由实际使用地区中有经验的设计师们参考资料和各方意见来做决定(可能应该分开,也可能应该全部相交,应当是主流人群使用和书写风格来决定的事情)。在汉字的书写中,笔画是否相接,只取决于字体风格、空间美观,只要大的笔画和构成原则没有被破坏从而造成疑义都是允许的。事实上即便不考虑有论文考据到的黑体和篆书的渊源,“父”作为部首在空间受限时上下相接可能是更美观的选项,因为更紧凑,少了一些空间的割裂感。(但我不是设计师,仅为个人审美的一家之言。)

我比较反对的是,用僵化的思维抑或错误的理由,或者不恰当地引用标准来要求去做这种改变,这样会走入歧途。一方面很多汉字作为单独字形和部首并不是完全一样的,不仅会根据具体情况进行变动,在汉字的演进中还会根据需要进行变形。远的如从笔画圆润的篆书进化到笔画迥然不同的隶书,再进化到适应毛笔书写变化的楷书:“人”跑到下面组合成新字时,直接就变成了“几”。近的从日常书写的楷书到为雕版印刷服务而诞生的宋体为例:“ㄋ”或者“辶”在楷体里面多数会是一个连笔,而宋体则会拆分为两笔甚至三笔。与已经高度成熟的楷体和宋体不同,黑体作为一个年轻的字体,固然极大借鉴了宋体和日本哥特体,但并不妨碍其做出一些适合自身特征和使用习惯的改变。我们不能简单地拿宋体或者日本哥特体的标准和做法,直接往黑体上面去套(大家可以拿来做参考并提出争议,但不应直接成为正确合理的依据)。另一方面,所谓“标准”恰恰是固化的,停滞演化和进步的,也是会不断修订的,所以不可僵化地看待和使用标准。对于汉字,大的字形原则如部首位置、笔画结构我们当然要遵守,但不可固步自封,否则西文中的a和ɑ先就要打个架分出胜负来。

具体到思源黑体基于日文哥特体作为基础字形来进行创作,这并不赋予日文哥特体超越设计风格以外的超然地位。日文有其社会长期使用的写法和习惯,中日韩固然有共同的汉字起源,甚至直到近代仍然在不断交流融合,但不可简单认为彼“汉字”一直就等同此“汉字”,试图统一各地文字的字形写法更是大错特错,完全忽略了各地因历史原因形成的文化差异(甚至我们可以进一步思考,中国作为汉字最主流的使用和起源地区,为什么不是日韩向中国靠拢,反而是中国向日韩靠拢呢?)。自日本脱亚入欧力图脱离中华文化圈起,经历中日各自的汉字简化方案到港台也各搞一套,汉字已然因政治或各种原因被人为割裂,否则Unicode中的统一CJK中为何很多字占用同一个编码但字形有细微不同呢?也正是基于此点,我认为节省CID并不是将日文字形copy为中文字形做法的一个合理合法的理由。故此我之前建议,对哪个地区的字形做修改,应该由该地区的专业人士根据众多资料、历史沿革和现实情况进行综合考虑后决定(如果一定要参考某个“标准”,愚意以为印研黑一体可能是黑体简化字形适合的参考,可惜印研所高昂的字体使用费导致其除了个别出版社书籍应用外完全没有社会普及度可言)。如果真的有必要在某个字体中统一汉字,恐怕首先得在各地区民间和官方组织的文化交流中推进统一,否则会在现实中遭遇困难重重。而如果仅仅在字体设计端去强行推动字形统一,只会增加字体遭遇各地阻碍甚至有被限制使用范围的风险。进一步举例来说,近代大规模汉字简化自新文化运动起(事实上2000多年来,汉字一直在向简化的方向演进)到1935年8月国民政府教育部公布了《第一批简体字表》,大陆此后顺应潮流大力推进,而台湾更多因意识形态原因固步自封,甚至搞起复古考据走回头路,这种连同源同种的文化都做不到的事情又何谈统一字形呢?汉字简化的出发点是降低学习和书写复杂度,让当时文盲占绝大多数的平民更易接受教育(从精英教育到平民教育),但一直被繁体字拥趸们冠以破坏汉字的帽子进行批判(我也并不认为所有的简化都一定是对的,个别字值得商榷,但不是完全抵制的理由),并不是以合作的心态参与,而无视汉字几千年不断进化的演变历史中并无绝对正确写法的事实,抱持这种占领道德高地的心态是很难一起合作解决问题的(甚至都走到了考据笔画强行纠正人们实际使用习惯的歧路上了)。文字,归根到底是由谁习惯使用的问题,如果脱离文化载体没人使用就只会逐渐被历史抛弃(例如朝鲜半岛、越南都已经没有多少资格加入汉字的讨论,因为已经没有实际使用环境,也没有几个人使用和认识了),正如风行一时后灭绝的“世界语”。甚且,我们更要警惕成为食古不化只钻故纸堆的孔乙己。如果古人的东西永远好用适用,就没有汉字演化,没有新文化运动,没有文化和文明的进化发展了。(不好意思,这个一不小心说得有点多,有些离题了。)

最后,说到援引标准,我觉得一定是先找最新的,然后再追溯旧标准,因为其可能因谬误而有变化和修订。有一定年头的标准不仅受限于起草人的认知和水平,还可能因不能及时更新而适应时代的变化:标准的更新可能要么不迫切,要么已经部分被别的新标准内容所涵盖。更重要的是,标准的应用领域往往也不一样,不可不察。通用汉字规范表是对文字使用的通用规范,事实上也说明了其引用的是GB13000-2010《信息技术 通用多八位编码字符集(UCS)》(=ISO 10646:2003,该标准主要目的是将GBK字符对应到Unicode编码表)。具体到信息技术领域内的字体(宋体),GB18030-2022《信息技术 中文编码字符集》才是适当的参考标准(GB2312->GBK->GB18030才是主要的标准制定和演进路径)。GB18030-2022同时也对GB13000-2010中没有的字符,指定了相应的Unicode编码,实际上是对GB13000-2010的内容进行增补(修订)。至于18030-2022是否对字形做出规定,请参考下列文本:
image

@NightFurySL2001
Copy link
Author

NightFurySL2001 commented Mar 30, 2023

TL;DR: SC and TW in this font has lots of problem and thus JP/KR form is better for Source Han. 通用规范汉字表 is the current glyph standard and not GB18030-2022. The connection/separation of CN 父 cannot be reasoned as purely aesthetical or due to standards.

本字体的简中和繁中都经验证出现诸多问题,日韩字形明显比中文字形更优。本字体参考日韩字形的美观参考并无不妥。

针对最后一点做出纠正:《通用规范字形表》才是中国汉字字形标注的唯一标准,GB18030-2022前言里面并未针对“字形”做出定义(而是提供“字符” character的定义,如我上一个comment截图),这代表GB18030-2022并不规定“字形”。附录前言定义的仍旧是“字符”,它只是给出了一个“参考”字形和代码,不代表字形是强制性部分。中国汉字字形标注如下追溯历史:

八、本表的字形依据《现代汉语通用字表》确定……

** 2009的征求意见稿参考《印刷通用汉字字形表》调整了44字的字形,也间接证明《通用规范汉字表》通过《印刷通用汉字字形表》定义汉字字形。附图如下。
image
** GB18030-2022里面援引《通用规范汉字表》(附录 E),而《通用规范汉字表》引用的GB13000.1《....汉字字序(笔画序)规范》只是定义了按照笔画排字序,不是字形,所以《通用规范汉字表》引用GB13000.1不是GB18030-2022定义字形的基础。
** GB18030-2022即使援引《通用规范汉字表》也仍旧有诸多问题,包括错误的《通用规范汉字表》字形

字体并不是信息技术领域单独拥有,而是从铅字、照排、电镀等等的媒介一起创造的产物,也在除了信息处理领域以外的情况使用(如印刷媒体),以信息技术霸占字体字形的定义是错误的思维。

目前已经公认中国的“规范汉字”字形是由《通用规范汉字表》定义,GB18030-2022 不定义字形,请详细查阅“规范汉字”的定义

三、字形
以1988年3月国家语委和新闻出版署联合发布的《现代汉语通用字表》为准。

最后,本串讨论的重点还是这样:思源黑体CN在制作时把空间狭隘的”爹爺”的“父”分开,但是明明空间充裕的“爷爸斧釜”却是接上,又该如何以美感解释?
image
另外,再讨论哪个标准制定了中国规范汉字单纯就是在浪费时间,无论是百度百科或维基百科都已经有诸多证明《通用规范汉字表》才是唯一的字形标准,在这里讨论也只是浪费资源和精力。我不会再回复任何与本issue无关的问题。

@Marcus98T
Copy link

Marcus98T commented Mar 30, 2023

With that, I request this issue be locked temporarily, but keep it open. Nobody wishes to see heated back-and-forth discussions debating the nitty-gritty details of standards and aesthetics, even in Chinese where the maintainers will not understand.

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

No branches or pull requests

4 participants