中文（传统印刷）能否处理 Unicode 的原规格分离原则？ #11
Comments
|
目前开发分支【传统印刷】版本使用 Unicode 字形映射，不遵循该实践。 我个人倾向于不遵循该实践，并且不是很同意《检字表》的做法。 因为这个问题完全可以由使用者自己去纠正。 使用 Unicode 映射，字体的使用者可以通过自己的选择来决定使用哪个字符；相反，如果两个字符都映射到旧字形，则完全抹杀了使用另一个字形的机会。日语中「剣」和「劍」也有这个情况，应该允许用户有机会同时使用两个字形，殊地区分流版本应该只是提供一种字形风格，而不是限制为某个语境。 我理解《检字表》推荐的做法实际是为了推广正确使用传承字形，但是虽然看起来是正确的，但是按照规范来说仍然是用了错误的字码。 |
|
我感觉是统一字形比较好。毕竟旧字形并不像Unicode Charts那样，没有成文规定，而且意思也是一样的。 |
这 Unicode Charts 跟原规格分离原则无关。
我是指出这一点，是因为我相信大多数用户根本就不屑于学习异体字，或者根本就懒得学习，而输入法总是提供普通字形。就算在输入法中提供了异体字，也很难找到它们，那么他们还不如去管。我承认，如果他们选择了异体字，未来的输入法会让他们更容易找到。 而且我实际上是说不必做所有的重映射。例如，"剣" 和 "劍" 可以保持它们的原样。 |
|
我不是文字和字体方面的专家，想听听其他人的意见。 |
|
我仍然觉得，这个问题应该由字体的使用者来主动解决，而不是由字体强制性解决。 既然他能在主流为台标的情况下，仍然明确的选择了使用传统印刷版本，那就应该相信他有相应的知识能够正确的处理这个问题。 |
我理解你的观点，我自己也学过不同的代码点，教育很重要。不幸的是，现实并不是这样的。正如我之前所说，你可能会认为人家应该知道这些异体字和不同的 Unicode 代码，但是有很多人并不知道，他们可能很无知，只是为了好玩而使用。在大多数情况下，它可能并不明显。在某些情况下，这就导致了字形的不一致，他们认为这种不一致是可以接受的，因为他们可能不知道不同的代码点。而且，即使意识到了不同的代码点，试图用另一个代码点取代每一个受影响的代码点也会变得很烦恼的。 换句话说，我认为大多数人不具备这样的技术知识，这就是为什么一些字体试图通过强制旧字形的标准来解决 Unicode 的原规格分离原则的问题。 But Ko 的源样黑体就是这样一个例子。不过，源样黑体v1.500版已经恢复了一些更极端的重映射变化，因此，与v1.300版本相比，v1.500版再分开 "研" 和 "硏"、"併" 和 "倂"、"教" 和 "敎" 还有 "啟" 和 "啓"。Windows XP 的细明体也是这样做的，但程度更小一些，比如 "為" 和 "爲"、"啟" 和 "啓"，但是 "青" 和 "靑"、"神 (U+795E)" 和 "神 (U+FA19)" 是分开的。
裁剪图片取自 http://zhungkiyau.blog.fc2.com/blog-entry-342.html 我只是根据经验说，也说得够多了，我不想再争论了。我将等待其他更多经验的人在此期间说出他们的意见。 |
|
目前传承字形就是用 源样黑体1.5 作为参考字形的，其他版本以思源黑体作为字形参考。 你的观点仍然在用户素质和传承字形推广这个点上，单纯该论点目前无法说服我。 这个项目本身对传承字形不持有立场倾向，也没有推广义务。 该问题可以暂时保留，如果有其他的观点，可以留言。 |
|
另外请教一下，这个 wiki 里面 https://zh.wikipedia.org/wiki/%E6%9C%AA%E7%B5%B1%E4%B8%80%E6%BC%A2%E5%AD%97%E5%88%97%E8%A1%A8 是不是包含了 原规格分离原则 的所有情况，可否以这个wiki 来作为可靠的参考文档？ |
|
这个问题其实还蛮棘手的。 如果字体计划是在有限范围内使用，且不接受用户输入/输出使用，那么直接将对应的字映射过去是没问题的。但是，如果有出现用户输入输出使用这个字体，那么建议两个/多个码位最好是分开显示以保障显示安全/避免混淆，尤其牵扯到用户名和网址显示的时候需要更为小心（见 Unicode Domain Phishing）。 建议如果要分开显示，有三种处理方法：1. 保持跟 Unicode 的映射方法；2. 在 Unicode 的基础上，把两个字符（一个常用一个不常用）互换显示（强烈不建议）；3. 两个都做成印刷字形，常用码位放正形，不常用码位放异体（或相对更旧的字形），制造显示差异。 如果要保障显示安全/避免混淆，跟回1是最好的方法，或者根据源样黑体的合并也不妨是一个好的处理方法（毕竟是繁中制作者，知道哪些字符是可以合并显示而不影响用户使用）。 如果要严格遵循《推荐形体表》，可以跟第3个建议，有部分码位是可以保留不处理的，例如 卽-即 和 旣-既 （《推荐形体表》不建议使用皀，因此可以差异显示），其他码位则需要更进一步的分化。 |
|
我認為十分應該把兩個字碼位置都做成印刷字形。 |
這個情境不適用，在.cn/.hk/.tw/.中国/.香港等等的網域下，一旦注冊了含一個異體字的網域後，採用其他異體的網域會自動禁止注冊。
絕大多數平台都只允許注冊英文用户名並容許設置顯示名稱。顯示名稱本身就不去重。 |
如果字體的使用目的是給用户設定來日常閲讀的話，我難道把網頁上程式上所有內容拷貝一次，人手把異體字換掉後再閲讀嗎？ 如果字體的使用目的是用來製作宣傳的話，那麼的確有可能製作者會想能夠使用到異體。但實際上絕大多數使用者也不知道有此事，你看一看市面上有多少商業宣傳，用日文字體時不會把「包」「港」調用兼容字，就知道了。 But Ko 那些逆向改動要照顧主要是人名。 除非你字體打算做全 GB18030，作為系統字形用於輸入法，否則不建議區分。不過要是做全 GB18030，不用新字形也沒有意義哦。 |
|
上面各位有提到过输入法无法输入旧字形的问题，但是我实际测试并不存在该问题。 我没有做更详细的测试，仅用上面对话中出现的例子做了简单是尝试。 |
不是任何人都使用「macOS + 搜狗输入法 + 简体中文系统语言」， （而且以前我也跟別人聊過這問題，大家的反應都是很難很難打出/根本打不出。 |
|
@aikahiiragi 我觉得输入问题，跟操作系统关系不大，主要是输入法的问题。
我是个简体中文用户，并没有对输入法做个特别的调教。Android 手机试了百度输入法，也可以打出。 我不是很了解目前繁体中文主流输入法的情况，如果能够提供目前主流的输入法品牌，我稍后会做一些测试。 |
|
说说我目前的一些想法： 目前支持异体字合并的主要理由都是使用者普遍对传承字形认识不足，或者工具使用存在困难。并不存在字体技术上的问题。（比如，某个旧字形在码表中不存在，必须占有某个现有字形，这种问题，并不存在） 合并异体字，会造成下面两个问题： 此外，还有一个我比较在意的问题，就是我不希望这个项目对传承字形持有某种倾向。 @hfhchan 老师之前给我提供过很多目前港台使用字体的混乱现状的案例。这根本原因是大部分使用者都不是文字和字体方面的专家。我在尝试自己制作字体前，对字体方面的知识仅有如何使用，我甚至都分不清思源黑体5个变种差别具体是什么。这些都是我花费很多成本才越过的门槛。 对于传承字形，我花了很多时间去研究《检字表》和其他传承字形字体，才基本搞清楚了大概的框架和概念。而这些文档，都是面向字体制作者，和文字爱好者的小圈子提供的。根本不存在一个面向只是想简单的使用字体的普通用户的文档。 强制通过字形修正，是一种治标不治本的方式，因为用户可能压根就没有意识到这个问题。他可能根本不知道 為" 和 "爲 的差别。这样对推广传统印刷体没有事实上的帮助。为什么不明确的向用户说明这个问题呢？ 所以，是不是可以创建一个项目，就叫做《如何正确的使用传统印刷体-10分钟手册》，它是一个简单的在线网页，并推荐所有提供传统印刷字体的项目，在显眼的位置，展示这个链接。文档应该包含如下内容： 介绍部分：
步骤： 工具可能包含：
我不知道上面的想法是否可行，近期会做一些调用并开始一些实验性制的工作。 |
|
我创建了一个新的组织来尝试推动这个工作，见： |
|
我覺得風向轉很快，一眨眼就向了一個可能不太正確/不太對應問題的方向發展。 這世界上有這麼多部電腦/手機，有各種不同版本的平台，各套不同的輸入法， 相反，TakWolf 閣下覺得「合併異體字會造成的『問題』」其實並非問題—— 前輩大大時常強調：科技以人為本，是應該方便人的使用，而不是設一堆所謂科技格式、科枝標準，去限制人的使用，把人的一些正常使用說成是錯。 強迫用戶去輸入罕用字碼才能出現傳承字形，這才是真真正正的治標不治本方式。 要治本，必須看清楚這個「本」，這個根本的問題，在哪裏？ |
但是人家确实很简单就证明了确实不存在输入困难的问题，还是个大陆用户。阁下能否提供证明，在繁体中文软件环境中确实存在输入困难的问题，且无法有效解决？
Unicode 当初设计有问题，大家都懂。但这已经成为既定事实，无法改变。在软件行业，当初拍脑袋就制定了行业标准，结果后来发现存在问题，这样的案例多了去了，你不能要求把标准都改了来适应新的问题。兼容性在软件行业非常重要。 @aikahiiragi 阁下需要论证，通过字体强制合并的方式，比优先使用正确的字符，是一种更好的做法。
按此理论，作为台标和港标的版本，理应不应存在旧字形，是不是应该把两个字符都合并为新字形呢？ 这个项目定义为泛CJK字体，传承字形版本不止包含旧字形，也包含简体字和日语汉字，这些都是“不应该存在”的汉字。如果你只用传承字形版本来做中日文混排，也会存在“各种奇怪”的字形问题，比如，一个日语汉字，是否应该采用旧字形的写法，还是采用日语写法？（尽管这个字不存在与传承字形中） 以最常见的“為”和“爲” 为例，这两个码都在日语 JIS 规范里面包含，都是正确的字形，在 Unicode 里面都有正确的语义。 客观现状是，目前繁体中文是以台标为主的，所以使用上“為”成了高频码位，而 “爲” 成为了低频码位（不是错误的码位）。 总结来说，这个问题本质上，码位使用频率的问题，而不是标准正确与否的问题。因此不应该由字体来解决这个问题。 |
|
插播一条。希望大家讨论的时候能客观的描述观点，就事论事，不要带有个人情绪。大家能来这里提出意见我个人非常感谢，我会参考所有人的建议的。但是不要因为争论闹得不开心就得不偿失了。希望大家讨论的时候能保持冷静，感谢🙏 |
|
謝謝 TakWolf 說明。我也希望討論上是建基事實上，然後以論證去交鋒不同論點，對事不對人。 感謝 fcwatcher 雖然跟我立場相反，但能夠親自說出「Unicode 当初设计有问题，大家都懂」這一點。 而有問題的，就是有問題。 竊以為，明知有問題，卻非但不考慮怎麼改善，還要其他使用者犧牲自己的權益，去遷就那問題，這種事情及這種思想，是更大的問題。 原則上，Unicode自稱只是提供字碼標準而非字形標準。所以，要是認為依 Unicode 某些顯示例子的字形才是「正确的字符」，這種思維，我個人覺得並不正確。
如果要顯示日文標準的時候，那就當然是使用日文標準字形的字型。無論選傳承字形字型，選台標字型，選港標字型，還是選陸標字型，都不可能滿足「要顯示日文標準」這個需求。如果有人想顯示日文標準，卻選用非日標字型，很明顯，這是那位人士的錯誤。 一套台標字型，不支援所謂舊字形碼位，把所謂舊字形碼位合併作台標表上的新字形，我完全不反對。因爲那套字型已說明是台標字型，我絕對不會懸木求魚，希望它能顯示出一個半個傳承字形。 因此，同理地，當我選用一套傳承字形字型時，我希望它顯示出來的，全都是傳承字形。 |
|
首先，以我個人理解，根據這issue名字，這是專門討論Ark Pixel Font的「中文-传统印刷（zh_tr）」版本的字型。既然是討論「中文-传统印刷（zh_tr）」版本，而不是討論「泛CJK版本」，當然以傳承字形的需求更優先。否則，輕易以其他因素去干犯、去凌駕傳承字形的需求，那麼成品就不配稱為「中文-传统印刷（zh_tr）」版本。（相反，要是這個版本是叫作「泛CJK版本」，那麼我當然不會要求這個版本要以傳承字形需求作最高標準，去凌駕泛CJK方面的需求。） 然後，極為重要的一點，什麼叫「正確」？什麼叫「錯誤」？要判斷正確與錯誤，先要知道根本的立足點。「利用電腦科技來處理漢字」，應該立足在「電腦科技」上，迫使「漢字」屈就「電腦科技」；還是應該立足「漢字」上，以「電腦科技」去遷就「漢字」？ 我認為，「漢字」才是主體，而「電腦科技」只是用來處理好「漢字」的一種應用技術而已。絕不應本末倒置。 過去，如果有追蹤字嗨、傳承字形之美等fb群組，甚至在這些群組出現前的一些相關論壇，一直留意「電腦科技」vs「漢字」之間的爭議，不論是誰都可以看到，一些IT界人士，時不時就搬出他們自己人為定出來、只有較短時間、且沒做好本份有許多問題的所謂「標準」，然後自大地要漢字界別去犧牲、去屈就，以自己的IT角度，高高在上地、踐踏其他界別地，聲稱它們對漢字界別的破壞是「沒有問題/不會產生嚴重問題/没有人能够明确的证明存在事实上的困难」（事實上在漢字界別早有極大量的指出），無視漢字界被其玩弄而導致的諸多嚴重影響。「我目前没看到哪个异体字码位被 Unicode 明确标记为错误的」——爲甚麼只有Unicode標記爲錯誤才算錯字？漢字本身的字理字源沒有say嗎？！No stake in the society嗎？！ 尤其是傳承字形方面，IT界自己定出違反字形學術的標準，收錄在傳承字形的學術角度上確確切切是錯字、錯誤形體的字元，然後強行稱自己的標準是正確，用自己定出來的這些錯誤標準，反指早就存在的、在字源字理上是正確的形體，或其字理字源的學術條件，才是「錯誤」云云。到底是誰自己找彆扭？甚至到底是誰自私自大，覺得自己的一套必須凌駕他人的一套？覺得用自己界別定出來那年資短短的所謂標準，可以剝奪人家界別比你早很久很久就存在的學術學理？覺得自己那套正確錯誤觀，有權改寫他人早就有多年嚴謹論證的學術正誤判斷？ P.S.：在時間上，Unicode比Big-5短。在Big-5時，為爲沒有區分碼位，新字形字型製作成9筆的字形（而這字形在傳承字形的字理上是錯寫），傳統字形字型製作成12筆的、符合從甲骨文到今天一直傳承演變的字形，毫無任何問題。後來Unicode出現，才把這個本來沒有區分的常用碼位，強行分配給錯寫字形，把正寫字形發配到邊疆碼位，這才是順時序的事實。fcwatcher口中說「传承字形用户认为，你是高频的，就应该显示我希望的字形，从而改变了标准」這根本是顛倒時序、顛倒因果、顛倒事實的中傷。 有些開口「计算机行业」閉口「IT標準」的朋友，在人家處理字源字理問題時可有半點關心過？然後人家解說好了，到實行一個技術來讓人家這方面的標準或需求獲得處理時，卻突然跳出來，企圖以技術這個客體去凌駕主體本身，這有道理嗎？ 要是Ark Pixel Font推出名為「泛CJK」或類似名稱的版本，那麼用IT界的什麼泛CJK那一套去凌駕其他標準，我沒有異議。但這個版本名為「中文-传统印刷（zh_tr）」版本的話，我個人實在無法接受以其他標準凌駕傳承字形需求、掛羊頭賣狗肉的行為。 （如果本層語氣重了請容許我先致歉。我不是想針對個別人士，只是說出已經積壓已久的不合理現象，這些問題都早就可在我說過的論壇和群組上看到。） |
|
人家泛CJK指的是字符收录范围，不是字形风格！中文-传统印刷才是字形风格。 这个问题，根本没有上升到「電腦科技」vs「漢字」这么高的层面上来，就是一个很简单的问题。 Big5 把 Unicode 分配给了 现在唯一的问题就是，按照台标的高频字码 （下面的部分带有主观情绪：） 这个行为，对推广传承字形没有任何帮助。互联网是的文字仍然在使用着台标字码，那些手机电脑里面装着系统默认的台标字体的人，看到的仍然是台标字形。他们没有任何机会了解传承字形，只有你自己看得到，自我感动。 相反，应该鼓励用户使用异体码位，在互联网内容产生差异，才能着实的影响普通用户。 |
|
我半个赞同aikahiiragi的观点。在他的基础上，也应该“鼓励用户使用‘异体’（旧字形）码位”，才是我的观点。 |
|
一般輸入文字的人不會注意或在意字形，再加上大部分漢字新舊字形沒有分離的 Unicode 碼位，不合併基本上沒什麼好處。為了應付標準而給字型使用者添麻煩，並不理想或實用。 設計良好的拉丁文字型會自動把一些字母組合顯示為合字（ligature），不按原本 Unicode 碼位逐個顯示。中文字型也沒有必要硬從 Unicode。 如果有特殊情況需要顯示原本的 Unicode 碼位，可以把未合併版做成一個樣式集（stylistic set）。 |
|
身爲《檢校表》的主編，我希望可以就這問題說說。 首先，決定編《檢校表》和硏訂傳承字形推薦形體，主力原因就是希望漢字文字學的學術考量，即字理，在漢字資訊應用領域中能獲得應有的尊重。 希望字理能獲得尊重，說白了，就是我們一直以來，在漢字資訊應用領域上，接觸過很多不尊重甚至是直接踐踏漢字字理的人。而無獨有偶，他們全都是來自IT界。我無意說整個IT界都是如此，也許就只是樹大有枯枝，不過這些枯枝的確以他們的IT界身份自居。 漢字一套是傳承了上百上千年的字符系統，本身有其正誤雅俗的內部規律。古往今來許多學者一直硏究，有它的價值。 當然，一套這麼龐大的符號，自然有其不同面向。我們沒有逼迫其他人用字時都以字理爲字先，大家使用漢字時有其他面向，並無問題。只不過，我們這些希望重視字理的人，本身的希望不但不是錯，背後更有嚴謹的學術支持，那麼，我們希望有重視字理的面向，這點應該是我們的選擇權。 遺憾的是，上堆那些IT界枯枝，就是不尊重我們的選擇權。把他們那些訂立了才僅僅數十年的自製「標準」擧得高一高，要全世界都只能依從，並聲稱文字學界歷來的標準都不是「標準」，竄改「標準」一詞的客觀定義。這字形爲什麼是正確、這字形爲什麼是錯誤，他們完全無法從文字學的準繩上說出半句因由，卻藉着他們自立的嬰兒標準，盲目地否定累積了上百上千年學者心血的標準。 如果本計劃的製作主TakWolf眞心想了解，想知道更多，其實在【傳承字形之美】群組上有大量舊帖，找不到的話，也很歡迎開新帖詢問。之前看到製作主你前來的發帖申請，即使你沒有回答必答題，我已第一次破例，批准了你的發帖和會員資格。我倒是奇怪，後來製作主你卻自刪了，令我莫名其妙。只要是尊重的、善意的交流，眞心希望增加傳承字形的知識，我們無任歡迎。 單就「爲」字來說，從字理和字源的角度，這字在甲骨文中，上方是「爪」或「又」，即一隻手，下方是「象」，能夠以手牽着體型龐大的大象，使喚大象爲人類效力，並不是誰都可以做到，因此能做到的人就是「有爲」。及至篆隸，象形側寫，仍可看到其長鼻、龐大身軀和四腿。傳承到楷明，字理仍然保持。哪怕清朝已亡，但此時此刻的當下日常生活中，仍四處可見這個符合字理的正寫。那麼，傳承字形推薦形體理所當然採用此形。 至於首筆爲點的九畫寫法，是把「爪」與象形黏合，雖然書寫上簡快了一點，但違反了字理。因此在字理的角度，這是一個錯字。在其他面向時，這錯字也許獲接納，但在重視字理的面向時，既然正形通行，就不應使用欠缺字理的錯形。 因此，傳承字形推薦形體中，只可以採用傳承至今仍十分通行的正寫，決不會出現首筆爲點的九畫訛寫。如果一套字型，眞的是符合傳承字形推薦形體，無論它採用什麼技術、什麼科技，都應當尊重傳承字形推薦形體的字理考量，保持「採用從『爪』的正寫，不會出現九畫訛寫」之結果。否則，要是那套字型無法尊重這點，就會變成樓上佟兄所言的「掛羊頭賣狗肉」之實，我們就無法承認它符合傳承字形推薦形體。 以Unicode來說，它們的官方說法的確是自稱「不處理字形，只處理編碼」。而不管是U+7232還是U+70BA，都一樣是解作「do, handle, govern, act; be」、官話讀「WEI4 WEI2」、粵語讀「wai4 wai6」的字。這樣的字，在傳承字形推薦形體中，就只有從「爪」的正形這一種形體。不論要把U+7232、U+70BA都製作成此形，把U+7232製作成此形而U+70BA留空，還是把U+70BA製作成此形而U+7232留空，至少不是違反字理。然而，一但把任何一個碼位，製作成九畫訛寫，這就是違反了傳承字形推薦形體。 在一些IT朋友眼中認爲是「何樂而不爲」的事情，正正就是逾越了我們所重視的字理底線。一些IT朋友口中的「兼容」，以結果而言，就是以我們的底線失守（或佟兄所言的「犧牲」）而換來的，這並不是「兼容」——因爲其結果與我們的底線並不相容。一些IT朋友在此聲稱「傳承字形一定要以【字理】作爲理由，強迫字體開發商去打破現有標準，製造不相容」，事實上，我們一直以來遇到的，是「IT界一定要以【Unicode】作爲藉口，強迫字體開發商去打破傳承字形的字理標準，製造不相容」這情況。 Big-5編碼公佈於1983年12月，距今還未滿39年；Unicode編碼公佈於1991年10月，更只有短短30歲。作爲處理漢字的編碼，本來它們的製訂者本身，應有責任去理順漢字的不同面向，使不同面向的使用者在使用其編碼時，都不受影響。尤其是越是年輕的一套，理應越是對既存的學術標準不相悖才對。 奈何有關製訂者在好些方面尸位素餐，特別是對傳承字形方面，幾近是無視，不管學界如何提出異議，他們也只是用自己內部自製的說法去自圓，去敷衍，就是不肯改變。在現代文明社會上，大家都應該知道：兼容是雙向的，尊重也是雙向的。單方面要求我們棄守底線，這絕對不是兼容，這對我們確實不尊重。身爲使用者，我們絕對有權選擇較尊重我們、較兼容我們的一套，甚至訂立眞正符合我們需求的一套，而不是盲從逼迫我們放棄底線的霸權。 套用老前輩李郁周敎授的話：「製訂者在公眾場合或私下裏，即使心有戚戚然焉，卻依然大言不慚地說：『既經政府公佈實施，不能再改。』甚至說：『已經輸入電腦，不能再修正。』把我們這些小老百姓嚇唬得一楞一楞的，好像我們都不懂法規產生的程序，不懂電腦的程式設計；好像標準字體比法律偉大、比憲法穩定；好像不妥當或錯誤的電腦資料要永遠使用下去。法律、憲法不合時代、不合環境、不合潮流、不合社會、不合道理，都必須透過合理的方式適時地修正。標準字體算甚麼？電腦程式又算甚麼？」 Big-5編碼並沒有像樓上一些IT朋友般過時。現在絕大部份繁體字型，不論它們是採用舊字形或新字形，都是以Big-5編碼的收字範圍爲基礎，新添少許港臺造字而成。資源沒有那麼雄厚的字型開發者，甚至連Big-5次常用區也不會造得齊備。就以我個人的編輯工作實際遭遇爲例，有一家出版機構，平時的內文是使用傳承字形，但其實那套字型是某字型公司的「新秀麗體」。因此，雖然它顯示作從「爪」的爲字正形，但那字形是放在U+70BA的碼位上。即使作者的來稿打成U+7232，我也要把全文取代作U+70BA，才可以在出版機構內部顯示出這字。 而U+70BA這碼位，卻正是有IT朋友認爲必須製作成九畫訛形的碼位。 要擧實際情況還有很多很多很多，如果大家眞心想了解，我不怕說。但我很怕，我如此花時間（其實我的硏究進度壓力很大，實在擠不了多少這樣的時間）說了後，製作主TakWolf或者其他參與討論的IT朋友，只不過又双叒用自家的「測試」，或者自家的IT界語言或主張，繼續聲稱是其他問題，堅持要在字型中放進九畫訛寫。 如果是這樣，我的時間花得毫無價值，我可沒有時間再花下去。（不計算事前的構思時間，寫這一篇回應，已花了我三小時半。） 我們本身就有成員從事Unicode方面的工作多時，以我們的理解，Unicode不但從沒禁止在一套具體字型上有兩個或以上碼位同形，甚至全球極多字型都有這種異碼位同形的情況。連Unicode自己的示範，也不見得會讓人以眼球分辨出U+0041、U+0391及U+0410的「A」形。我們的《檢校表》、《推薦形體表》中，要求把U+7232、U+70BA都製作成從「爪」的正形，絕不違反Unicode的規定。這作法已經是我們在保持我們底線時，對Unicode所作的最大兼容。本身在Unicode那邊的朋友也不反對我們的作法。要是有朋友認爲連這一點兼容都不允許，認爲要遵守Unicode就等於必須踐踏我們的底線採用訛寫，而他們的主張又被三人成虎推到變成定律一般的話，那麼我們就只有直接宣佈「Unicode踐踏傳承字形，反對使用Unicode」。但事情眞的如此嗎？ 個人觀看製作主TakWolf的貢獻，似乎過往是走IT路線的，因爲這字型計劃，才接觸到傳承字形，一時之間想不通也好，不明白傳承字形核心原則和處理也好，鑽了牛角尖也好，都不爲奇。只要肯公平和友善溝通的話，不妨多在【傳承字形之美】群組上交流，多了解傳承字形的準則，多了解文字學的知識。我們無任歡迎！希望製作主不用再刪帖，我們期待着與閣下的友善交流。 |
|
感谢 @SyaoranHinata 长评。 首先解释一下 Facebook 的问题以避免误会。我在传承字形小组发帖后又删除确有其事。实际的情况是，我同时在 传承字形 和 字嗨 两个社区发了帖子。（我自己平时并不使用 Facebook，这两个小组都是我通过周边了解到然后随手关注的） 在传承字形发的帖子是：希望能找到一个在传承字形语义下，应该替换的完整的异体字的列表。和这个 ichitenfont/inheritedglyphs#19 意思基本相同。 我在字嗨发的帖子，就是当前线程的主题，即字体开发者是否应该遵循原规格分离原则的问题，并且也贴了《检字表》的建议原文。（当时的想法是这个问题在传承字形小组问没有任何意义，一定会给我肯定的建议。字嗨看起来貌似并不都是传承字形派的人，可能会给出不同的意见，其实就是想听听一些反对派的意见） 但是第二天在字嗨的帖子被管理员隐藏了，理由是：《检字表》不属于字嗨的讨论范围 我当时怕其他人觉得我是在引战，即故意挑起传承字形和教育标准的争论。但我并无此意，感觉这么问确实有点问题，容易吧事情扩大化。 实际就是这个情况，没有啥其他的意思。对造成的困扰，十分抱歉。 |
|
謝謝製作主補充。不用抱歉吶，言重了。 我們無法替字嗨群組說話吶，我們群組的理念跟字嗨群組不同。但我們群組上，只要不違反版規，我們極少會直接砍帖的。如果閣有有心交流，絕對不用退出我們群組啊。 的確，在談論到傳承字形和敎育標準時，觀感上會顯得火藥味重。不過，其實我們並非容不下敎育字形。我們不能接受的僅是： 1.逼迫我們都只能使用敎育標準，不能使用傳承字形。 2.把傳承字形說成是錯/錯字/錯誤，視敎育標準字形爲唯一正確形體。 換言之，其實只要承認學術事實和尊重彼此權利，在我們群組上要良性交流是沒有問題的。 無奈的就只是過去不少相關的爭論，一些有關人士就是連這些很基本的條件都做不到。這方面我們也感到無奈和可悲。 如果製作主有興趣，在閣下覺得適合的時候，透過不同的途徑跟我們友善互動、交流都可以啊。 |
|
個人建議不要糾纏是否有輸入法能支援異體字。簡中輸入法在中國大陸市場按法規需要遵守 GB 18030，再舊一點的也通常支援 GB 13000.1，所以原格分離分開的字，理論上都得支援。台灣、香港、澳門，沒有類似規定。 「替換字符」這個問題是，網頁尚可安裝插件替換字符，應用程式界面和內容不能。 希望一致的話，只能從字體層面解決。 一點明體是從用户者出發，因為繁中用家採用傳承字形的合理權益在數年內被微軟及蘋果無理剝奪，在這個背景下自己擔起任務做字體，繼而去給設計師指南。 這個出發點是給用户製造一個「文字寫法一致有系統」的閲讀體驗，而不是給設計師製造一個可以由設計師指定寫法的產品。 話説之前有日本人在一點明體要求把歩也映射到步以求統一。一點明體團隊無耐因涉字過多、資源不足而婉拒，影射字符限於大五碼範圍。可見「要求一致」不只限於中文環境。 |
|
我想在座许多人对统一码有误解。 含青部件的字不区分倒是可以讨论，这个是确实需要字体来区分的，当然可以用异体选择符只用一个字体来支持，也可以用 |
|
注意：為/爲（为）除了本字和偽/僞（伪）、蒍/蔿（𫇭）外，其他字如 鄬䧦㺔噅寪撝溈噕嬀㬙譌䃣䈧䞈䦱 （𰻦𠯠𰌷㧑沩妫𰵑𰦨𧹑𰿫）皆无分码。 |
|
古語有云：知錯能改，善莫大焉。尤其是來自學界老教授的批評，絕不是無的放矢。 然而，有人就高高舉起一個叫「Unicode（统一码）」的東西，大大聲說就是不能改，就是要永遠使用下去，感謝一些人示範了來自IT界的狂妄、乞人憎。 說起來，那個「知錯能改，善莫大焉」的出處，各位有聽過嗎？這句說話本來是士季向晉靈公進諌時說的，士季還說「君能補過，袞不廢矣。」可是晉靈公仍舊不改，甚至要殺諫臣。結果晉靈公還是自取滅亡。 |
|
對了，樓上大大已說過，許多家字型廠商的舊字形字型，都在U+70BA碼位上造「爪頭為」，也有多家傳媒機構統一用這些字型和這個編碼。看來是不少業界公司都集體地「自娱自乐」，集體地要U+70BA碼位顯示作「爪頭為」呢。 這個 ark-pixel-font 計劃，既然有zh_cn、zh_hk、zh_tw多支，那麼在zh_tr這一支上，跟隨這麼多的業界大頭一起「集體自娱自乐」又有需要被一些狂妄、乞人憎的傢伙惡言相向嗎？呵呵。 |
这不挺好的嘛，所以我没提。（如果没理解错的话） |
是小学课文内容。这种内容我就很喜欢了，马上下文会提到。
似乎有些人还觉得，啊，统一码什么玩意怎么还不能改啊，怎么这么狂妄把自己当天经地义了，我就要改，就要。 这个字 🔫 U+1F52B Pistol。苹果觉得，这个字太暴力了，对美国社会影响太不好，但恰好，我苹果公司就是这绘文字世界的规则，我要改动，其它公司都还得跟着我改，因为我苹果恰好是统一码规范的实现者：绘文字用的彩色字体是苹果先做的。苹果大手一挥，自iOS 10.0起把这手枪改水枪了，你们再也不能打出手枪这个字啦，天下大吉！
苹果确实违背了统一码定义，Pistol无论如何都不该是水枪。那大家都不能打出手枪这个字形了，会有什么后果呢，顶多是世界上暴力内容发不出去了，我苹果做了多大的善事积多少德呀！ 但这个字是2015加入统一码的，苹果2016年才改，这一年间发生了很多事，推特上许多人愤怒于白皮警察枪击黑人，只发 白皮警察 手枪 黑人 的3个绘文字以示抗议。 这种直接歪曲了历史的后果，就是有些人乃至一个公司觉得我就动一个字符又咋了的心理。 我早就想谈这段历史，虽然有意用口头语描述，但这不是一个故事，而是已经发生的历史错误，苹果也不只这次已经干了又干了，由于它自己就负责统一码的绘文字落实（彩色字体、输入法、排版引擎……），统一码还没法管。我相信将来还会有人再犯，口中还说着各种自以为能积德的道理，自以为在进谏。如果有这样想法的某些人知错能改，善莫大焉。 我绝对不同意把字体里的“為”搞得像“爲”这种自欺不欺人的行为，苹果能欺所有人，是因为它真有全世界苹果手机上的字体的控制权，且没有政府去管它。但我没看见这儿有人能控制全世界的中文字体，或两岸三地加日韩的语文机构。 现在我十分确定在座有些人对统一码有误解。和ISO有些不同，统一码实际上是协调机构，它对汉字编码分配的权力来自全球政府（统一码要求每个汉字都有标某源，比如M源来自澳门），可以看到连英国人都已经塞了汉字。
「樓上大大已說過，許多家字型廠商的舊字形字型，都在U+70BA碼位上造爪頭為……有多家傳媒機構……不少業界公司」楼上大大不好告诉你，真实原因可能会侮辱你所在地区。 有一个人对我早指出的统一码错误视而不见：
你觉得我为什么随手就能甩出这些错误？因为我是IT界的专家（嘘）。你在那装模作样地「示範了來自IT界的狂妄、乞人憎」「晉靈公進諌」完全没有打算作建设性交流，示范了何谓无知无畏，我也不指望你能“知错”，但我希望你起码有点看人的眼光：“IT界”是什么东西？随便点几下鼠标就能看出来我是画色图的，闭着眼扣帽子乞人憎有趣吗。 不过在这聊天很有趣，我想记载下来传阅给更多人。 |
|
上面有人說到交流，交流是雙方的，如果對方來到發言是建設性的，其他人當然也建設性地對待才合理。 可是如果對方一來到，就是發動嘴炮，這叫其他人怎樣「建設性」地跟他「交流」呢？ 要是這樣的人還要怪罪其他人「不建設性」，就真的不知這是「有趣」，還是「白痴當有趣」。 我也好，多位大大也好，也在上面說過。「以電腦編碼記載漢字」，電腦編碼只不過是載體，漢字才是本體。那麼，爲甚麼只有Unicode標記爲錯誤才算錯字？漢字本身的字理字源沒有say嗎？！No stake in the society嗎？！ 這種「以Unicode壓倒漢字字理」的行為，對漢字本身的學術來說，本來就是破壞性而不是建設性的。漢字學界許多學者的批評，都是有實在的道理、有建設性的。 不過，有自認為不是IT界的人，一來到這討論上，就毫無建設性地發動嘴炮，就以他自己覺得的Unicode規則來蠻橫地、霸權式地壓過來，用粗體去寫「确实要永遠使用下去」，這樣去壓過學界老教授的批評。又用什麼「自娱自乐」的帽子，強行扣到Unicode組織人士都認為OK的、出版業界都如此做的實際解決方法頭上，聲稱那是所謂「誤解」、所謂「錯」的。 開嘴炮的人強詞奪理，還把黑白顛倒過來。明明是後起的Unicode拼命奉媚某些政權的所謂標準而不尊重文字學界，把編碼弄得三不像，嘴炮者卻盲目地以Unicode（而且是用他自己的狹窄解讀方式）為正，說Unicode就是要讓別家政權的權力「越出國界」安插本來不屬於那標準的東西進來，換言之嘴炮者的眼中，Unicode是個強姦犯。 漢字真正的對錯，例如為什麼「點頭為」違反字源字理、「爪頭為」怎樣符合字源字理，嘴炮者說也不敢說，因為他根本無知，卻還無知無畏，踐踏學界聲音。我在上方已清清楚楚地直指問題：
嘴炮者現在又這樣跳出來重覆這種行為，並不會顯得自己有建設性，相反只呈現了他自己是無視道理的跳樑小丑。 其他的政權標準如何任讓Unicode安插，我沒興趣，反正我不會選擇用它。大大的造字計劃，在那些版本中，跟隨Unicode安插，我都沒有意見。唯獨是名為「zh_tr」版本，就理所當然必須遵守傳承字形的標準和需求，拒絕違反字理的安插，向強姦說不。否則，如果結果是掛羊頭賣狗肉，那麼這個根本就不是「zh_tr」版本。 雖然我說話不懂圓滑，但我只是針對問題和誤點，有碗話碗，有碟話碟。對於在道理上明顯不通，卻恃着語言暴力開嘴炮的人，我沒興趣。嘴炮者只是重複已被反駁、已證明不成立的論點的話，相信真正想作建設性思考及交流的人，都能分辨道理，我不用再回應那些無聊也無恥的嘴炮。 |
|
抱歉各位，这个问题很久没有回复。说一下我目前的想法以及解决方案的计划。 我个人的想法和态度：这个项目最开始是参考和对标思源黑体的，繁体只有港标和台标。我自己并不是字体和语言学方面的专家。制作过程中才发现， 但是，这个版本 繁体印刷体并没有一个现代的绝对的可参考权威或者标准。《检字表》虽然影响力较大，但是我仍然只能将其视为民间标准之一，不能将其视为传统印刷体的绝对标准。 因此，不命名为【传承字形】，而是用一个更概况的命名，可以保留一些可操作空间，留有余地。 我是通过这个项目才了解到繁体中文标准之争的这个问题的，我对那些在当前这种环境下，仍然在积极推进【传承字形】相关工作的人员是抱有敬意的，我认为这些工作很了不起。但我自己并不是业界相关人士，我个人对语言标准的问题本身并不持有任何立场。从我的角度看，不管是传统印刷体，还是港标台标，他们都是客观存在的需求，都受到尊重。我会平等的综合的考虑目前存在的问题，来尝试找到解决方案。 再来说说目前的计划将异体字统一替换为传统印刷体版本，从技术的角度上来说不是一个安全的方案，有一些代价。 但是，如果单独构建一个【传承字形】的版本，这个版本中完全采用《检字表》的方案，使用定制化的构建规则，则没有问题。 传承字形版本计划放置到：https://github.com/TakWolf/ark-pixel-font-inherited 这个方案的想法之前就已经想好了，但是因为主项目要进行 等宽和比例字体的拆分 ，会重构整个构建程序，因此便推迟了。这个工作会在主项目完成新的构建系统后开始。 这也确定了一个大致的风格，就是主项目采用比较中立的、安全的方案；而在子项目中使用特定环境的构建规则。 之前的 https://github.com/TakWolf/fusion-pixel-font ，也是使用独立的项目来解决的。 |
|
鉴于当前这个讨论串已经开始偏离问题本身，变成立场的争论，不再具有参考意义；另一方面回复有点太长了，也不方便阅读。 我计划在 2 天之后关闭这个线程（视情况锁定）。 在此之前，大家仍然可以对上面我提出的暂定的解决方案本身进行讨论和留言。 在这之后，如果大家有任何针对该问题的的想法和建议，可以随时打开新的讨论线程。 谢谢各位老师！ |
|
我個人也許不能認可「民間標準」一詞可能蘊含的潛臺詞，但我也認爲另開一個獨立的項目專門做傳承字形倒也不失爲一個好的解決方案——至少仍可滿足傳承字形用戶的需求。 狼人小林 先生所言「繁体印刷体并没有一个现代的绝对的可参考权威或者标准。」這說法我應該是完全不認同的。因爲《康煕字典》、《大漢和辭典》等權威字典的字頭，這些具有學術權威的傳承字形標準，在學界內外，都有許多人重視，無疑是可供參考的；這些標準不僅適用於印版字體，而且直至今日現代亦不過時。至於「现代的绝对的可参考权威或者标准」，是指有「政權確立」或「國際組織背書」嗎？（我決定還是以截圖引用《傳承字形部件檢校表〈附錄二：關於傳承字形的謬說與事實〉》中有關內容全文。本來是因爲覺得會 over，恐冒犯 狼人小林 先生，當時我想着「狼人小林 先生畢竟沒有也不會扭曲「標準」一詞定義吧？」我先在此提前說聲「對不起」。） 我個人覺得標準不必「絕對」，只要他「本身合於衡量事物的準則，可供同類事物比較核對」不就好了嗎？ 《檢校表》倒也沒有完全「字理至上」——表中前言有這麼一段內容（附圖）。 若此評論給 狼人小林 先生帶來了麻煩，我將刪除掉。
|
|
先為我幾次爭辯道歉，可能麻煩到大大了。只是我不明白為什麼一個真正有效而且過去都確實這麼做的解決方法，會惹來一些IT界人士或者高舉他對Unicode的片面理解的人士嘴炮，為了自己和大家（喜歡傳統印刷字形、會選用這些字體的人）的選擇權，的確要說說我的論點。如果另外立項可以沿用符合大家的需求，同時免於被嘴炮，我同意可以另外立項。 本身因為像素字體空間有限的地方，是像素字體先天的限制，若已盡了力但仍受此限制，我覺得大家都能體諒的。不過除了這種限制以外，就希望能盡量呼應大家的需求。過往的字型廠商處理舊字形字體時，的確各施各法，「Adobe 繁黑體」跟「Adobe 明體」之間也有大量出入/矛盾。就是因此，大家更希望可以有個統一應用的舊字形標準，而「傳承字形標準化文件」正好就有這個功能、又有人維護、又開源，所以才渴望可以標合這個標準，使大家切換不同的舊字形字體時，可以無痛無縫切換，不會換了字體後又要改文檔上的一批字（這樣改也很可能會改漏改錯）否則又變成錯訛字或者缺字。 |
|
打扰一下，问个问题，我不是特别清楚zh_tr和编码的关系，听大家讨论有些懵。我知道unicode编码，简体有gb2312-gbk-gb18030系列，繁体我只知道有big5，这些编码和unicode能通过iconv或者各系统提供的转码接口或映射表转换。那zh_tr和zh_cn这些是啥？我还一直以为ttf里的编码都用的unicode呢。
jun louis
***@***.***
…---- 回复的原邮件 ***@***.***>发送日期2022年05月31日 19:36 ***@***.***> ***@***.***>主题Re: [TakWolf/ark-pixel-font] 中文（传统印刷）能否处理 Unicode 的原规格分离原则？ (Issue #11)
抱歉各位，这个问题很久没有回复。说一下我目前的想法以及解决方案的计划。
我个人的想法和态度：
这个项目最开始是参考和对标思源黑体的，繁体只有港标和台标。我自己并不是字体和语言学方面的专家。制作过程中才发现，
客观上确实还存在一种印刷体写法。这个写法并不能被港标和台标囊括，需要独立分流，因此才加了这个版本。
但是，这个版本 zh_tr 从一开始就命名为【中文-传统印刷】，而不是【传承字形】。这个版本也不完全遵循（也没有承诺过遵循）《检字表》。原因是：
繁体印刷体并没有一个现代的绝对的可参考权威或者标准。《检字表》虽然影响力较大，但是我仍然只能将其视为民间标准之一。
《检字表》是完全字理至上的，这种做法是不是好的我现在没法客观的评估。实际上字体制作方面我并不是只参考《检字表》，也参考了很多其他资料，比如 Adobe 繁黑体，他们在处理上并不完全遵循《检字表》。另外就是像素字体空间有限，检字表里的写法并不一定合适。
因此，不命名为【传承字形】，而是用一个更概况的命名，可以保留一些可操作空间，留有余地。
我是通过这个项目才了解到繁体中文标准之争的这个问题的，我对那些在当前这种环境下，仍然在积极推进【传承字形】相关工作的人员是抱有敬意的，我认为这些工作很了不起。但我自己并不是业界相关人士，我个人对语言标准的问题本身并不持有任何立场。从我的角度看，不管是传统印刷体，还是港标台标，他们都是客观存在的需求，都受到尊重。我会平等的综合的考虑目前存在的问题，来尝试找到解决方案。
再来说说目前的计划
将异体字统一替换为传统印刷体版本，从技术的角度上来说不是一个安全的方案，有一些代价。
主项目在策略上会比较保守，因此应该不会采用这个方案。除非有一种更安全的技术方案。
但是，如果单独构建一个【传承字形】的版本，这个版本中完全采用《检字表》的方案，使用定制化的构建规则，则没有问题。
传承字形版本计划放置到：https://github.com/TakWolf/ark-pixel-font-inherited
这个方案的想法之前就已经想好了，但是因为主项目要进行 等宽和比例字体的拆分 ，会重构整个构建程序，因此便推迟了。这个工作会在主项目完成新的构建系统后开始。
这也确定了一个大致的风格，就是主项目采用比较中立的、安全的方案；而在子项目中使用特定环境的构建规则。
之前的 https://github.com/TakWolf/fusion-pixel-font ，也是使用独立的项目来解决的。
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#11 (comment)",
"url": "#11 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
@louisliangjun 这个thread讨论的是字符的字形（glyph，即字符显示的形态），而不是字码映射（character mapping）。zh_cn（中国），zh_tw（台湾），zh_hk（香港），zh_tr（传统印刷）是各地区的语言/地区代码。例如，“骨”在zh_cn的上半部是向左折，而在其他地区都是向右折。 目前的情况在于，部分字符是Unicode按照来源分离编码，导致部分传统印刷字形和手写字形分开显示，如“青”和“靑”。以简中输入法为例，如果要以 GB2312 编码显示印刷字形的“靑”，则字体必须要在“青”的码位上做下面是“円”的“靑”才可以正常输入（仅支持 GB2312 的输入法是不可能输出“靑”的码位，因为 GB2312 选择把“青”<39 64>映射至 U+9752）。这个问题原本应该是由字体层面处理，但是收到来源分离而搞出乱子。 以现实的繁中输入法为例，无论台湾香港都是使用 BIG5 进行编码，而 BIG5 的编码人员选择将“為/爲”映射至 Unicode 的U+70BA“為”。这样一来，普通的繁中输入法只能输入对应到U+70BA的“為”，不可能输入U+7232的“爲”。问题在于，繁中字体厂商如果要显示爪头“爲”，就只能放在 BIG5 对应的 Unicode U+70BA“為”。因此，一般的繁中传统印刷字体都是在 U+70BA“為”显示爪头“爲”，也在 U+9752“青”显示下面是“円”的“靑”。 |
|
感谢回复，学到了！谢谢！
jun louis
***@***.***
…---- 回复的原邮件 ***@***.***>发送日期2022年06月01日 13:15 ***@***.***> ***@***.******@***.***>主题Re: [TakWolf/ark-pixel-font] 中文（传统印刷）能否处理 Unicode 的原规格分离原则？ (Issue #11)
@louisliangjun 这个thread讨论的是字符的字形（glyph，即字符显示的形态），而不是字码映射（character mapping）。zh_cn（中国），zh_tw（台湾），zh_hk（香港），zh_tr（传统印刷）是各地区的语言/地区代码。例如，“骨”在zh_cn的上半部是向左折，而在其他地区都是向右折。
目前的情况在于，部分字符是Unicode按照来源分离编码，导致部分传统印刷字形和手写字形分开显示，如“青”和“靑”。以简中输入法为例，如果要以 GB2312 编码显示印刷字形的“靑”，则字体必须要在“青”的码位上做下面是“円”的“靑”才可以正常输入（仅支持 GB2312 的输入法是不可能输出“靑”的码位，因为 GB2312 选择把“青”<39 64>映射至 U+9752）。这个问题原本应该是由字体层面处理，但是收到来源分离而搞出乱子。
以现实的繁中输入法为例，无论台湾香港都是使用 BIG5 进行编码，而 BIG5 的编码人员选择将“為/爲”映射至 Unicode 的U+70BA“為”。这样一来，普通的繁中输入法只能输入对应到U+70BA的“為”，不可能输入U+7232的“爲”。问题在于，繁中字体厂商如果要显示爪头“爲”，就只能放在 BIG5 对应的 Unicode U+70BA“為”。因此，一般的繁中传统印刷字体都是在 U+70BA“為”显示爪头“爲”，也在 U+9752“青”显示下面是“円”的“靑”。
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#11 (comment)",
"url": "#11 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
原发帖人最后说一句，坦白地说，我并不完全理解这整个对话。我所要求的只是对一些常用的汉字进行简单的重新映射（我甚至从来没有要求过 "传承字形" 的版本），而这却变成了一个大麻烦。 我的要求应该被认为是未解决的，因为我们都知道 "旧字形" 的繁体中文有许多不同的变体，甚至很难决定哪些汉字应该被重新映射。 也是因为创作者坚持认为他必须遵循一些技术标准，而不是同意一个简单的变通办法。我盲目地猜测，这是与 "ark-pixel-font/assets/design/12/4E00-9FFF CJK Unified Ideographs/" 代码部分对Unicode字形的命名惯例有关。 很抱歉我的帖子是机器翻译的，所以有些地方可能被误解了。 |
|
感谢回复，学到了！谢谢！我理解就是说 青 这个字有两种写法，本应该用两个字体，但是unicode把这个字变成两个字了，我还以为unicode每个区段交给不同国家处理呢，看来不全是
jun louis
***@***.***
…---- 回复的原邮件 ***@***.***>发送日期2022年06月01日 13:15 ***@***.***> ***@***.******@***.***>主题Re: [TakWolf/ark-pixel-font] 中文（传统印刷）能否处理 Unicode 的原规格分离原则？ (Issue #11)
@louisliangjun 这个thread讨论的是字符的字形（glyph，即字符显示的形态），而不是字码映射（character mapping）。zh_cn（中国），zh_tw（台湾），zh_hk（香港），zh_tr（传统印刷）是各地区的语言/地区代码。例如，“骨”在zh_cn的上半部是向左折，而在其他地区都是向右折。
目前的情况在于，部分字符是Unicode按照来源分离编码，导致部分传统印刷字形和手写字形分开显示，如“青”和“靑”。以简中输入法为例，如果要以 GB2312 编码显示印刷字形的“靑”，则字体必须要在“青”的码位上做下面是“円”的“靑”才可以正常输入（仅支持 GB2312 的输入法是不可能输出“靑”的码位，因为 GB2312 选择把“青”<39 64>映射至 U+9752）。这个问题原本应该是由字体层面处理，但是收到来源分离而搞出乱子。
以现实的繁中输入法为例，无论台湾香港都是使用 BIG5 进行编码，而 BIG5 的编码人员选择将“為/爲”映射至 Unicode 的U+70BA“為”。这样一来，普通的繁中输入法只能输入对应到U+70BA的“為”，不可能输入U+7232的“爲”。问题在于，繁中字体厂商如果要显示爪头“爲”，就只能放在 BIG5 对应的 Unicode U+70BA“為”。因此，一般的繁中传统印刷字体都是在 U+70BA“為”显示爪头“爲”，也在 U+9752“青”显示下面是“円”的“靑”。
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#11 (comment)",
"url": "#11 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
I'd like to clarify that in the ISO 10646 standard, the source references (i.e. mappings to the national character set standards) are a normative part of the standard, while the representative glyphs (i.e. the glyphs shown in the code charts) are an informative part of the standard. (Normative 是「規定性」，Informative 是「描述性」) That means, if you are developing a font for the Taiwanese market, and you are covering common characters, and you wish to show the customary handwritten form ⿰言兑, you should associate it with T1-6B29 (T1 and T2 cover characters for general use), and thus mapped to Unicode it at U+8AAA. You do not need to consider that U+8AAC is already encoded with the shape ⿰言兑. To reiterate, ISO 10646 is NOT a glyph standard, it is a character standard. And the character is defined by its mapping to the source, not the glyph shape provided. Please refer to this classical example:
As you can see the UK form of U+30C28 is identical in shape to the J form of U+82B2. The character at U+82B2 is designated as a variant of 花, hence it should be designed as according to the corresponding national conventions. The character at U+30C28 is the simplified form of 菕, hence it should be designed as according to PRC conventions. The identity of the character is more important compared to the actual glyph. |
這種所謂「代價」本身是錯誤理解 ISO 10646 架構與正確了解 ISO 10646 架構所出現的衝突而已，上面有幾個人在吵什麼「自娛自樂」，本身連 ISO 10646 的架構也不了解。 這個問題也不限於繁體中文 locale。如果你開發一套「傳統印刷體版本」的字體，而你的字形產品對象是中國大陸市場，正確做法應該是把 G0-3B46 即 U+9EC4 直接做成「⿳廿一⿱由八」，即管已經存有 U+9EC3。你完全不用管 ISO 10646 上面 U+9EC3 和 U+9EC4 的字形。 （如果你是開發公安部系統相容字體，那麼就另外一個説法。你需要依據 GB18030 把 U+9EC3 和 U+9EC4 造成不同形狀。同一時間，GB18030 也規定，當常用字字源是「月」旁，對應的「肉」旁字得用「點、提」。但是當常用字字源是「肉」旁，對應的「月」旁字則會和此「肉」旁字完全同形作兩橫。） |
你不懂編碼架構就不要在這裏瞎吹。 統一碼聯盟是美國的一個資訊業界商會，他們同時是在 ISO 下面美國的代表機構之一。 中日韓編碼由 IRG 負責，IRG 是 ISO 轄下的 JTC1/SC2/WG2 轄下的工作組。ISO 就是你口中的那個協調方，統一碼聯盟不是。統一碼聯盟是其中一個參與方，英國也是。 IRG 制定的中日韓漢字擴展區需要過 ISO ballot process，由各個國家代表通過。中國、日本、英國、美國等都是投票國。 統一碼聯盟承諾和 WG2 保持 The Unicode Standard（簡稱統一碼） 和 ISO 10646 的字符集一致而已。The Unicode Standard 涵蓋範圍比 ISO 10646 廣，各國承認的是 ISO 10646 不是 Unicode。
什麼分配權力什麼權力投放你瞎扯夠了沒有，你連基本事實也沒有搞清楚，編碼技術要求和意識形態扯都一起，你還好意思。 |
参见 https://zh.wikipedia.org/wiki/%E6%9C%AA%E7%B5%B1%E4%B8%80%E6%BC%A2%E5%AD%97%E5%88%97%E8%A1%A8
比如 "値 (U+5024)" 和 "值 (U+503C)"，因为中文用户使用的是常用的代码点U+503C，但真正旧字形就在U+5024（日文常用的代码点）。所以为了统一旧字形，建议将U+5024映射到U+503C。
还有 "為" 与 "爲", "眞" 与 "真", "俞" 与 "兪", "尙" 与 "尚", "靑" 与 "青", "飮" 与 "飲" 等。请挑选具有旧字形的Unicode编码点，并将其重新映射到通用的中文编码点。
你不需要做所有的重映射。
The text was updated successfully, but these errors were encountered: