针对不支持字体特性的软件，关于中西标点冲突的非标准解决

[MY1L]

关于中西标点冲突，及统一码欠收录标点

（此处略去因历史原因，有些(半个)中文标点就是等同西文标点的问题。标点名及描述依新华字典）

1. 破折号：横线、两倍全角、对齐汉字、不中断两端不顶格，当前编码方案与—(U+2014)冲突，统一码或应收录 (见下文破折号章节)；
2. 省略号：六点、两倍全角、对齐汉字，当前编码方案与…(U+2026)冲突，统一码应收录；
3. 间隔号：圆点、全角、对齐汉字，与·(U+00B7)冲突；
4. 引号：全角，蝌蚪形(弯引号)，与“‘’”(U+201x)冲突，尤其隔音号就是｢’｣；
5. 着重号：形如汉字下一圆点，统一码欠收录；
6. 专名号：限古籍和文史著作，形如专名下一横线，专名之间断开（如“成都司马相如”，断在“都司”之间），欠编码方案，统一码难以收录；
7. 浪线：限与专名号配合，替换书名号，欠编码方案，统一码难以收录；

——新华字典没提的如示亡号没写。上述标“统一码应收录”是指这这些标点应当视为一个2倍字宽、换行不中断的标点，而不是需要连打2次的标点。

目前大多东亚字体对此有各异的策略，但皆不能解决中西混排出现难堪的情况，特别是——
把｢’｣做成全角，导致夹的西文｢I’m｣成了｢I’　m｣。思源也尤其依赖特性解决破折号，而且有问题。

破折号

我选择—(U+2014)默认为西文em线，维持Alegreya原状。
而西文标点⸺(U+2E3A TWO-EM DASH : omission dash)我考虑已知中西混排文献里不像｢’｣常用，不如说难得一见，则默认为两倍全角、对齐汉字、两端不顶格，充当破折号代餐。
不支持字体特性的软件需要复制粘贴使用。
思源的问题在连⸻(U+2E3B THREE-EM DASH)也做了还加入特性，不仅导致横排时撑行距（ichitenfont/I.Ming#18 (comment) ），而且遇到4连击————就很难看了，我认为特性应当考虑此类不按章法来的情况。

更新：留意到统一码码表认可⸺此标点用于中文，划去上文“西文”的描述。

省略号

我选择…(U+2026)默认为西文3点略号，维持Alegreya原状。
将⋯(U+22EF)做成全角、对齐汉字来冒充，因为这个符号是数学省略号，统一码没规定宽度，而东亚字体的“⋯”一般是设为全角的，如Adobe 宋体 Std、MS Gothic…
不支持字体特性的软件需要复制粘贴使用。
最佳解法当然是让统一码收个六点省略号，现在连代餐都没有😓

间隔号

我选择·(U+00B7)默认为西文中点，维持Alegreya原状。
将日文中点・(U+30FB KATAKANA MIDDLE DOT)做成全角、对齐汉字充当间隔号，这个在语义上应该问题不大？
不支持字体特性的软件需要复制粘贴使用。

引号

我选择默认西文弯引号，维持Alegreya原状。
注意到有提案：https://www.unicode.org/L2/L2023/23212r-quotes-svs-proposal.pdf 那么朱雀可以提前支持全角引号VS（变体序列），但问题是不支持字体特性的软件是否支持VS，似乎支持VS的软件更广泛？#19 (comment)
关于代餐符号，我只见过一个人用❝❛❜❞（U+275x HEAVY ~ COMMA QUOTATION MARK ORNAMENT，属于2700 Dingbats区段的Ornament，甚至不是标点）当蝌蚪引号的。是否有必要选择这个？

统一码欠收录、难以收录的标点

目前无解，请大家设计编码方案。网页CSS都很难做到专名之间断开而专名不断。

字体实例

我制作了一个示例：https://github.com/MY1L/Plur/releases/tag/ZhuQue
请检查有无问题。

关于半角问题

西文标点是比例宽度并非等于半角，同时默认与小写西文对齐，显得各种括号在汉字靠下位置。一个高级西文字体往往还内置一套与大写西文对齐的标点，但不直接暴露给用户，在遇到上下文为大写时自动通过case特性调用。朱雀目前借用的Alegreya就藏了52个case标点字形以及几十个lf数字（大写平齐）

不支持字体特性的软件是无解的，中文西文总有一方难看。难道要用私用区吗。
目前策略是除了上述冲突情况，仅位于3000中日韩符号及标点 FF00半角及全角区段的默认做成中文标点（因为西文必然不用），其它皆小写西文标点，依赖特性改变。

[MY1L]

为了避免制作撞车，补一个近况报告。

斜杠零

为了支持统一码的VS1

和zero特性，我修改了Alegreya若干零和制作了全部6个斜杠零：

/zero.zero/zero.lf.zero/zero.tf.zero/zero.tosf.zero/zeroinferior.zero/zerosuperior.zero
不支持字体特性的软件需要复制粘贴：【0︀】即2个字符0030 FE00

※后面的变体选择符FE00即VS1是不可见的。

比号（ratio）

目前许多手机系统字体有冒号与大写西文或平齐数字相遇时改为比号来显示比分或时间的特性，统一码文档也推荐（古典数字不用改）
比号外观类似冒号，但冒号与小写字母对齐，比号与大写对齐，可能比冒号宽一点高一点。

不支持字体特性的软件需要复制粘贴：【∶】

全角问号

西文问号维持Alegreya的“半边问号”原状，但中文问号则稍稍模仿了思源宋的做法。
|

字体实例

略，因为刚生成的可变字体已过时，我这边又改了。需要的话请评论索取。

[VentusUta]

作为中文字体，是不是把U+2026以全角U+22EF形式显示、U+00B7以全角U+30FB形式、U+2014以全角形式显示好一点（

这三个符号比较常用，感觉还是以中文的标准显示比较好，而且改成全角不会太影响西文的显示效果。
（参考中易宋体的处理）

[MY1L]

首先，当然会极大影响西文的显示效果，而且浪费了3个标点的码位：
（测试文本：La⋯tin…?）
当然开源字体分叉出一个为你专用的版本应该也是可以的。

其次，我已经提到，中文破折号是“相对汉字居中、两倍汉字宽、中间不断开、两端不顶格”，现在2个U+2014以全角形式显示，要么中间断开，要么两端顶格，既作不了破折号，西文也用不了，那，不就只是一个什么用都没有的废字形吗。
不理解U+2014以全角形式显示好在哪一点。@VentusUta 或许我没看懂你的意思，可以附图说明吗。

[VentusUta]

我的想法是作为中文字体，既然中西文总有一个会难看，（在不支持字体特性软件的情况下）还是应该优先照顾中文的显示效果。这些字符全部复制未免太麻烦了

对于U+2014做成全角是希望它能对齐汉字。
（不过这样断开／顶格其实是没办法的事……不过中文字体里两种实践其实都有）

[MY1L]

我想了半天试图理解。
这两种实践都是我几年前已经批评过的，“—”做成全角无论如何照顾不了中文的显示效果，以至于思源黑要通过OT特性替换为“⸺”。不觉得要求本应该用先进技术的开源字体遵循2个上个世纪的字体为你开倒车是否……🤔
本字体OT特性是可以读取locl（地区）自动切换字形，实际上不用复制，也就谈不上“复制太麻烦”。
面向广大的一般使用者就不得不提视窗的系统字体，微软雅黑“…·”都为西文形式（不能切换），几乎没人觉得有问题。如果使用者直到打印“…·”都不觉得有问题，那么实用角度上对使用者而言就没问题（更何况现今浏览器等软件都已支持本字体OT特性）
你对排版的要求显然不一般，那当然是分个叉，需要的话可以帮你现做一个低配的（只需丢弃3个码位即可），但“—”做成全角已经不是“中西文总有一个会难看”，而是“中西文都难看”（虽然你自己感受不到），所以我挺迷惑你对排版要求：
你对排版如果要求高到不能忍受破折号是错的，不允许破折号在中间换行，那直接把“⸺”加进输入法自造词了，不需要这个字形；
你要求如果不高，那除了“—”还可以用“―”U+2015 HORIZONTAL BAR，某地区iOS输入法打破折号直接就这个。

综上所述，分叉一个低配字体即可解决你上述需求，保证你感受不到难看，那就没问题了。我之后做一个。

[VentusUta]

好吧，受敎了orz

既然现代的浏览器等软件都支持字体特性，那您的处理方式我也没意见，就用当前形式好了。

[abs-c]

作为中文为主体的字体，或许可以优先考虑纯中文排版的情况，将间隔号、引号等标点的默认字形设置为全宽的，要照顾混排的话再想办法给西文做 OT 特性之类？

从一个业余使用者的角度看，这样建议的一个原因是，对于混排要求高的场合更可能会以 PDF 或者图片输出，相关软件对字体特性的支持往往更好，且字体、符号的选择和设置也可以更灵活；相反纯文本、HTML（电子书）等相对局限的格式更常排版纯中文内容，且这时一般也不会期待作者往文字里加变体选择符、甚至设置正确的语言地区等等，于是往往呈现的都是默认行为。这样的背景下，对冲突码位默认使用中文符号似乎更能达到各个使用场景的平衡。

[celestialphineas]

作为中文为主体的字体，或许可以优先考虑纯中文排版的情况，将间隔号、引号等标点的默认字形设置为全宽的，要照顾混排的话再想办法给西文做 OT 特性之类？

从一个业余使用者的角度看，这样建议的一个原因是，对于混排要求高的场合更可能会以 PDF 或者图片输出，相关软件对字体特性的支持往往更好，且字体、符号的选择和设置也可以更灵活；相反纯文本、HTML（电子书）等相对局限的格式更常排版纯中文内容，且这时一般也不会期待作者往文字里加变体选择符、甚至设置正确的语言地区等等，于是往往呈现的都是默认行为。这样的背景下，对冲突码位默认使用中文符号似乎更能达到各个使用场景的平衡。

正是由于会有大量的业余使用场景，才会将部分标点默认做成西文形态，因为这样做最不容易发生排版灾难（例如 don’t 的撇号间距过宽）。中文混排西文形态标点，整体来说间距安排是不完美但可接受的，但反过来，西文混排中文标点，一般来说完全不可接受。

而在专业使用和排版环境，反而可以期待文字工作者或设计师能充分利用字体特性，我们也因此准备了替代字，可以通过 OpenType 特性或变体字选择符调用。朱雀当前的标点特性是综合考虑了 MS Office、Web 和 Adobe 应用中软件特性的折衷，以「开箱就足够好用、有专业需求也能够满足」作为目标。我们做这些设计决策是经过了深思熟虑的，也测试过各个软件中的默认支持情况。

[abs-c]

作为中文为主体的字体，或许可以优先考虑纯中文排版的情况，将间隔号、引号等标点的默认字形设置为全宽的，要照顾混排的话再想办法给西文做 OT 特性之类？
从一个业余使用者的角度看，这样建议的一个原因是，对于混排要求高的场合更可能会以 PDF 或者图片输出，相关软件对字体特性的支持往往更好，且字体、符号的选择和设置也可以更灵活；相反纯文本、HTML（电子书）等相对局限的格式更常排版纯中文内容，且这时一般也不会期待作者往文字里加变体选择符、甚至设置正确的语言地区等等，于是往往呈现的都是默认行为。这样的背景下，对冲突码位默认使用中文符号似乎更能达到各个使用场景的平衡。

正是由于会有大量的业余使用场景，才会将部分标点默认做成西文形态，因为这样做最不容易发生排版灾难（例如 don’t 的撇号间距过宽）。中文混排西文形态标点，整体来说间距安排是不完美但可接受的，但反过来，西文混排中文标点，一般来说完全不可接受。

而在专业使用和排版环境，反而可以期待文字工作者或设计师能充分利用字体特性，我们也因此准备了替代字，可以通过 OpenType 特性或变体字选择符调用。朱雀当前的标点特性是综合考虑了 MS Office、Web 和 Adobe 应用中软件特性的折衷，以「开箱就足够好用、有专业需求也能够满足」作为目标。我们做这些设计决策是经过了深思熟虑的，也测试过各个软件中的默认支持情况。

感谢回复。理解这种考虑。（还是想稍微碎碎念一下如果只是想避免「灾难」其实 Office 设置西文字体或者 Web 简单搞个 fallback（这应该都算是常规操作？）就可以，像现在这样排全宽引号就挺麻烦的 hhh，一些软件变体字选择符支持也不太好）︁。大概算是个难以面面俱到的问题了，制作者的考量会更全面专业一些啦。