导航
主页
鸣谢
下载页
其他语言
(不存在)
有疑问？
联系我们
其他
世界时间
TH-Times核心说明书
此页面用于详解TH-Tshyn(天珩全字库)中所附带的专用于复杂文本处理的字体TH-Times。字库可于本站下载页下载。

目录(链接仅用于快速定位)
§0 基本说明
§1 字体分支
§2 字库logo
§3 拉丁/希腊/西里尔/科普特/傈僳/亚美尼亚
　　3.1 连字
　　3.2 零宽附标
　　3.3 环绕附标
　　3.4 本地化字形
　　3.5 序数词
§4 五度标记法声调符号
§5 标准化变体序列与彩色字体
　　5.1 中日韩标点符号
　　5.2 彩色字体
　　5.3 本地化字形
§6 传统蒙古文/八思巴文
§7 右至左连写文种系列
　　7.1 镜像符号
　　7.2 阿拉伯文
　　7.3 叙利亚文
　　7.4 恩科文
　　7.5 曼德恩文
　　7.6 摩尼文
　　7.7 诗篇体巴列维文
　　7.8 哈尼菲罗兴亚文
　　7.9 粟特文
　　7.10 回鹘文
　　7.11 花剌子模文
　　7.12 阿德拉姆文
§8 假名与汉文
　　8.1 埼玉市地名字形
　　8.2 冲绳语假名
　　8.3 浊点附标
　　8.4 小假名
　　8.5 私用区
　　8.6 汉文训读
§9 注音符号
§10 苏州码子
§11 藏文/札那巴札尔文
§12 希伯来文
§13 它拿文
§14 撒玛利亚文
§15 傣泰文字系列
　　15.1 泰文
　　15.2 老挝文
§16~§1020 保留
§1021 未来计划
§1022 字体中的未定义码位
　　1022.1 中日韩部首补充
　　1022.2 小假名增补
　　1022.3 数学用字母数字符号
§1023 手机端的安装建议

§0 基本说明
　　TH-Tshyn一向致力于及时将全Unicode的字符统统收入，但由于中日韩的文字需要耗费大量的时间精力，导致对于复杂文本的处理，在2021年8月发布的3.1.0版本引入TH-Times之前一直处于空白状态，只是机械地如CodeCharts一般一个码位对应一个字形——我们一般将其戏称为“萝卜坑情结”，来源于证明整数与自然数一样多的时候常用的“一个萝卜一个坑”的证明方法。当然，作者深知这个做法是错误的，因此在有了一些时间之后动手制作了TH-Times——而更多的使用字库的“中日韩领域”的用户由于习惯了汉字本身的“萝卜坑”属性，根本连复杂文本是什么、需要做什么处理都不知道，这也是很可悲的一件事儿。只有将所有复杂文本都能够正确变形了，TH-Tshyn才算完成了“真正意义上的支持全Unicode”，而这还任重道远。
　　以下文本将分多条叙述目前TH-Times对部分复杂文本的支持情况，并提供字体测试。在测试位置会给出TH-Times当前的变形，标注出这是“符合Unicode所定义的正确变形”(简写：强制)还是“Unicode并未明确定义对应序列的变形，只是字体中的特有实现”(简写：非强制)。
　　TH-Times曾以Times New Roman 7.01为蓝本进行修改而得，属非盈利、学习研究型，不制作或出售任何商业作品。字形版权非字库作者所有。若有任何人以本字库的名义收取任何费用，本字库作者不承担任何连带责任。各个区块儿对应的字形来源将会在以下文本中分条叙述。版本号继承自原Times New Roman，故与TH-Tshyn并不同步。在TH-Tshyn的3.1.0版本中所带的TH-Times为7.02版；在TH-Tshyn的4.0.0版本中所带的TH-Times为7.03版。自TH-Tshyn的4.1.0版本起，TH-Times被完全重写，版本号变为8.00，但原本来自Times New Roman的大部分字形(例如拉丁字母、希腊字母、西里尔字母等)均有保留。
　　自8.00版发布后，发现了一系列较为无关紧要的bug，并在之后不久以补丁形式发布了8.01版。其中一部分bug为重写OpenType Layout代码时粗心所致，已修正；另一部分为变形引擎本身的问题，已修改代码以优化在特定变形引擎下的显示效果。
　　TH-Times自8.00版起的版本更新记录可见TH-Times版本更新记录页面。

§1 字体分支
　　TH-Times自7.03版起默认为ttc(TrueType Collection)格式，其中带有四个子字体，分别为“TH-Times”、“TH-Times_telex”、“TH-Times_grek”与“TH-Times_cyrl”。其中，“TH-Times”字体为该字体集的原版，自本页面第2章起所有叙述均为该字体的叙述。“TH-Times_telex”字体在原版的基础上增加了“输入越南语telex转写或输入带数字调的汉语拼音，自动变形为对应的越南语音节或带上标声调的汉语拼音”功能；“TH-Times_grek”字体在原版的基础上增加了“输入拉丁字母显示在一定转写规则下的希腊字母”功能；“TH-Times_cyrl”字体在原版的基础上增加了“输入拉丁字母显示在一定转写规则下的西里尔字母”功能。除附加功能外，支持的字符及字符的变形均完全相同。
　　经测试，在Win8.1的Word2013环境下(为严谨起见，未做测试的环境在此处不作评论)，ttc格式的字体会使字体的各种变形失效，将其拆分为ttf之后重新安装便能正常变形，作者暂不知其缘故。若在有使用需求的情况下遇到相同或相似的问题，可尝试自行使用工具将ttc拆分、卸载原来安装的ttc并重新安装ttf。

§2 字库logo
　　在TH-Times中曾存在六种不同字母系统下的字库logo，其分别为拉丁字母、希腊字母、西里尔字母、传统蒙古文、假名、注音符号；自8.00版本重写之后，拉丁字母的logo被微调，其余五个未被保留。下表为字体测试用表：
预期字形 您的浏览器 变形类型
TH-Fonts 非强制
　　需要注意的是，如果您的浏览器不支持彩色字体，在正确安装TH-Times之后上述logo均将显示为黑白样式。有关彩色字体的其它说明，详见彩色字体章节。

§3 拉丁/希腊/西里尔/科普特/傈僳/亚美尼亚
　　字体中支持Unicode15.1中定义的所有拉丁字母、希腊字母、西里尔字母、科普特字母、傈僳字母和亚美尼亚字母。同时根据Unicode Pipeline增补了将要收录于Unicode16.0的字母(码位已定且无特殊情况不会再有改变；但有再增加新字母的可能性)。拉丁字母、希腊字母与西里尔字母主要来源于原Times New Roman，并作出少量修改和增补，有零星一部分字形来自CodeCharts；科普特字母字形来自CodeCharts(含希腊字母区块儿的14个科普特字母)；傈僳字母修改自Times New Roman的拉丁字母部分；亚美尼亚字母来源于原Times New Roman，并修正连字字形。与此同时，自8.00版起，除科普特字母外，该五个文种中外形相同的字母均被合并到同一个glyph上，以最大程度节省glyph数量，尽量保证日后增加其它文种时总glyph数量不超过65535。

3.1 连字
　　字体中存在两种连字。一种在默认条件下直接生成连字，若需断开连字需手动插入Zero Width Non-Joiner(U+200C，以下简称ZWNJ)；另一种在默认条件下不生成连字，若需连字需手动插入Zero Width Joiner(U+200D，以下简称ZWJ)。连字是铅字时代的遗留产物，以“fi”组合最为常见，由于f的头部与i的点经常会相撞，当年的活字会将fi合起来做成一个字模；也因此，在字母显现形式(Alphabetic Presentation Forms)区块儿，为了与早期字符集的兼容性，也为一些常见拉丁、亚美尼亚连字单独提供码位予以收录。默认生成连字的情况也分两种，一种是两个字母的连字，有ct、fi、fj、fl、Qu、st、ſt、Th等的组合及这些字母的衍生字母组合(如fí、Qù等)；另一种是无限个字母的连字，例如当拉丁字母f和t连续出现时，能无限相连。
　　从严格意义上来说，分属一个复合词的两部分的字母不应当连字，如英语offline的fl、mistake的st；德语Schifffahrt的后两个f、Auflauf的fl等等，此时需手动插入ZWNJ，因为字体内部不可能内置所有语言的复合词词库进行判断；但在并没有如此严格要求的场合下，即便连字也无大碍。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
first 非强制 普通非强制连字
física 非强制 带附标的派生非强制连字
Schiff‌fahrt 非强制 默认连字、ZWNJ断字
Schieſ‍splat‍z 非强制 带有ZWJ的连字

3.2 零宽附标
　　零宽附标即non-spacing mark。在Unicode中，并非所有带有附标的字母均存在单独的码位——因为这样不经济，会浪费很多位置，且可扩展性弱。现存的预组合字母一般是为了兼容早期的已有字符集不得不收录，或是早期技术并不是很发达的年代无法实现附标的正确归位而不得已收录的。例如汉语拼音方案中单元音ê的四个声调就只有ế和ề具有单独码位，并且它们的存在并非源于汉语拼音，而是源于越南语国语字，只是碰巧同形。
　　在字体中，零宽附标也是很忌讳“萝卜坑情结”的，如果只是单纯地把附标做成一个没有宽度的字形，并不能把附标很好地放到前一个字母上应该在的位置，这是因为，第一点，在比例字体中字母的宽度不是固定的；第二点，字母的高度更不是固定的。因此需要根据不同的字母把附标放到不同的相对位置上去。而在附标之上叠加附标则更忌讳“萝卜坑情结”。Unicode中收录了许多各种各样的附标，并且每次更新都有可能增加新的附标。在Unicode的核心规约中也定义了这些附标的实现原则，而市面上的字体暂且不说附标收得全不全、能不能及时更新，就连已经收了的附标都有一部分不能很好地按定义准确归位。我们并不希望核心规约所定义的实现原则只是一种“可望而不可及的理论”，将其真正实现才是应该做的。
　　需要注意的是，附标的归位除了需要依赖字体中的代码外，还需依赖软件或系统所带的变形引擎。对于一些较近收入Unicode的字符，在较旧的软件或系统上，即使有了合适的字体，仍有可能不能正常变形。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
i̐˞ N̡̄ ᴉ̤̈ ō͘ 强制 普通附标归位
ú͡i u͡͏́i 强制 CGJ的附标结合作用
j+ü᪻̄=jū 强制 括号附标
nnᷠ᪻ᷠ᪻᪻ᷠ᪻᪻᪻ᷠ᪻᪻᪻᪻ᷠ᪻᪻᪻ᷠ᪻᪻ᷠ᪻ᷠn ŋ᪽᪽᪽᪽ ⲁ⳱⳰⃐ 强制 附标的双向叠加

3.3 环绕附标
　　环绕附标即enclosing mark，其本身带有宽度，并且基底字母会受到其影响而移动一段距离。在常规条件下，左至右排列的文本中出现在右边的字符不可能给出现在左边的字符的左边添加宽度，因此这需要字体中代码的配合才能实现，也必须抛弃“萝卜坑情结”。理论上，环绕附标也允许无限叠加，但在实际操作时，环绕附标的叠加除了移动位置外，不同层的附标大小也应当不同(例如方块儿外部套圆圈儿和圆圈儿外部套方块儿肯定不能是一样的效果)，这需要占用字体内的字形，实际实现时总会存在上限。在TH-Times中，此类附标被设定为只能加一层，若输入多个则会以“虚线圈儿外部套环绕附标”的字形作为提示出现在整个“基底+第一层环绕附标”的序列之后。这在理论上是一种“错误”，但考虑其实际使用价值和技术限制，不得已才作出妥协。但是在第一层环绕附标的前后输入零宽附标时两种附标都能够正常变形。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
A⃢ λ⃠ ю⃞ Ϣ⃣ 强制 普通环绕附标归位
б҉ г꙱ д꙲ 强制 计数用环绕附标归位
І⃣ Ц⃣ Щ⃣ 强制 环绕附标宽度自适应
ɨ̃᪾ a⃝⃝͊ 强制 环绕附标与零宽附标的组合使用

3.4 本地化字形
　　对于同一个码位的字符，在不同的地区也存在着不同的写法。TH-Times中，拉丁字母部分针对土耳其语、立陶宛语、马绍尔语和简体中文的环境做了本地化字形；西里尔字母部分针对简体中文的环境做了本地化字形。土耳其语与立陶宛语均为字母i上添加附标时上方的点儿不消失(与i相关的预组合字母也适用，例如土耳其语的“rahîm”一词，若放置于土耳其语的环境下，则î将带点儿；原Times New Roman并未对í以外的预组合字母进行本地化，这是错误的)。马绍尔语为L/N/l/n下的commaaccent附标变为cedilla附标。简体中文为汉语拼音中字母a与g由双层变为单层、锐音符(acute)由上粗下细变为上细下粗。
　　若在土耳其语或立陶宛语语言环境下欲使用不带点儿的i与附标的组合，请将附标置于U+0131之上；若在马绍尔语语言环境下欲使用commaaccent附标，请使用字母加零宽附标U+0326的组合字符。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试环境
rahîm M̧ajeļ gá 强制 英语
rahîm M̧ajeļ gá 强制 土耳其语
rahîm M̧ajeļ gá 强制 马绍尔语
rahîm M̧ajeļ gá 强制 简体中文

3.5 序数词
　　TH-Times针对英语的序数词缩写做了特殊处理，使得在数字之后出现的相关字母能够自动变为上标形式；但这要求数字前方出现的第一个Script非Common非Inherited的字符不得为拉丁字母以外的字符，否则根据变形规则，Script为Common的数字字符将继承前方非拉丁字母的字符的Script，从而导致上下文检测被阻断，使得无法变形。若欲手动阻断符合搭配的序列变为上标，请在数字与字母之间插入ZWNJ。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
2nd 12th 22nd 非强制 序数词正确搭配
2th 12nd 22th 非强制 序数词错误搭配
2nd α2nd a2nd 非强制 前方是否有其它文种字符

§4 五度标记法声调符号
　　五度标记法的声调符号位于U+02E5~U+02E9(杆位于右侧，一般用于标记原调)和U+A712~U+A716(杆位于左侧，一般用于标记变调)。在Unicode核心规约中只给出了两个字符以及三个字符的连字的例子；但声调语言的声调结构并不一定都是简单到只用三个以内的相对高低就能描述清楚的，在不与核心规约的定义产生冲突的前提下，为以防万一，字体中直接做了无限个字符的连字，理论上只要不在中间换行就能够一直连下去。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
˥˩˨˦˧˥˩˨˦˧˥˩˨˦˧ 非强制 右杆声调无限相连
꜔꜓꜕꜖꜒꜔꜓꜕꜖꜒꜔꜓꜕꜖꜒ 非强制 左杆声调无限相连
　　需要注意的是，如果您的字体显示为15根完全断开的杆，这是绝对错误的；如果为部分相连或是有规律地两个一组，这是实现了一部分功能，但实现不全面的；如果三个三个相连为5组，这符合核心规约中的定义，即使与TH-Times不同也不能说是一种“错误”。

§5 标准化变体序列与彩色字体
　　标准化变体序列，即Standardized Variation Sequence，简称SVS，为一个普通字符和一个变体选择符(Variation Selector，简称VS)所构成的序列。该类序列由两部分组成，一部分与emoji无关，其定义可见于CodeCharts或Unicode数据库中的StandardizedVariants.txt，理论上其所使用的VS范围为U+FE00~U+FE0D，但截至Unicode15.1，实际只有U+FE00~U+FE02正式投入使用；另一类与emoji有关，其定义可见于Unicode数据库中的emoji-variation-sequences.txt，其规定为在字符后添加U+FE0E表示普通文本样式、添加U+FE0F表示emoji样式，而具体字形则不作规定，只要在符合描述的范围内(例如不能把笑脸做成哭脸等等)各家可自由发挥。
　　在TH-Times中，目前支持Mathematical、Mathematical alphabet script variants、East Asian punctuation positional variants、Phags-pa、Manichaean分类下所有被定义的标准化变体序列。其中关于Phags-pa、Manichaean分类下的字符的叙述，见本文后续对应的章节。Myanmar、Egyptian hieroglyph rotational variants、Egyptian hieroglyph expanded variants分类下的序列将在日后对应区块儿加入TH-Times时同步加入。CJK compatibility ideographs分类下的序列无加入TH-Times的计划，因为TH-Times不将支持中日韩越统一表意文字区块儿的任何内容，该些区块儿由各分支字库承担，将逐渐支持各地的地区字形标准。Mongolian分类下的序列字体亦支持，其虽然在该数据库中，但并非使用VS的序列，故此处不作过多提及，相应内容见传统蒙古文章节。

5.1 中日韩标点符号
　　标点符号的书写规范各地的规定并不相同。句号等中国大陆标准中常书于左下角(竖排则为右上角)的标点符号，在港台地区则为居中书写，在日韩地区同中国大陆；感叹号等中国大陆标准中常居左书写(竖排则为居右)的标点符号，在港台地区与日韩地区均为居中书写。有时在纯文本中有必要两种情况同时出现，此时并无法直接进行本地化，因此小林剑博士(Dr. Ken Lunde)提出将此类标点符号的位置加入标准化变体序列，通过控制字符可手动控制标点符号的书写位置，并得到通过。字体中，同时支持使用变体序列调整位置和使用本地化调整位置两方案。本地化只会调整默认情况，即不添加VS时；添加VS后本地化自动失效。
　　此外，中国大陆所使用的弯引号也是长期以来存在争议的话题。有人认为，位于General Punctuation区块儿的弯引号(单引号U+2018与U+2019；双引号U+201C与U+201D)为“西文引号”，中文亦使用该些码位属于“寄人篱下”。这是不对的。除了专门标明是中日韩所使用的标点符号外，其他标点符号从来只区分“全半角”而不区分“中西文”。还有人认为，西文使用的引号是不区分前后的U+0027和U+0022(即俗称的“傻瓜引号”)，位于General Punctuation区块儿的弯引号就是给中文用的，这更是错误的。ASCII中只存在一种引号是打字机时代的历史遗留问题，早期的打字机甚至没有数字0和1，直接用大写字母O和I代替；而西文中所使用的弯引号确实与中文所使用的弯引号占了相同的码位。另，西文中也存在各式各样的引号，如德语使用类似逗号的写法(单引号即为一个，双引号即为两个)作为前引号，而使用与中文前引号相似的写法作为后引号(使用同一码位)。傻瓜引号存在半角和全角两个码位是因为对应的字符集存在，Unicode的本意便是兼容各地区各种各样的字符集来达到防止乱码的目的，便于信息交换。而区分“全角弯引号”与“半角弯引号”的字符集从未存在过，因此分开收录的想法是不可能通过的，也是多余的。
　　但在实际使用中，其字形确有区分的必要。将全角引号置于西文中，或将变宽/半角引号置于中文中，都是极其不美观的。大家平日所使用的手机字体，一般调用顺序西文字体在前、中文字体在后，导致中文文本中的引号常显示为变宽引号，这也引起了部分人的不适。小林剑博士曾提出给引号亦提供标准化变体序列来手动切换样式(见http://www.unicode.org/L2/L2014/14006-sv-western-vs-cjk.pdf)，虽未曾通过，但字体中也引入了这个方法进行手动切换。应对不添加VS的普通文本时，字体将默认字形设为中文的全角引号，若语言环境为西文，或前后存在西文字符，则通过字体中的代码自动变为西文的变宽引号，这种方式能够解决绝大部分引号所出现的场合。VS主要用于控制中文文本中出现西文字符或西文文本中出现中文字符的特殊情况。此外，锡伯文(该书写系统隶属于传统蒙古文)亦使用弯引号，其宽度与中文的全角引号稍异，尤其竖排时的写法仍是弯引号，与中文写法大相径庭，字体中通过字符对Script的继承来判断是否属于传统蒙古文(锡伯文)从而进行变形，但可能仍然存在一些边缘情况无法完全照顾到，因此同样地，引入VS3(U+FE02)作为弯引号的“锡伯文样式”。
　　对于两个连续出现的全角标点符号，若满足“前者的右半部分(若为竖排则为下半部分)为空，而后者的左半部分(若为竖排则为上半部分)为空”，则进行标点挤压，减少半个全角字符的宽度。过多的余白会让版面显得不美观，而绝大多数纯文本环境并不会主动提供标点挤压，因此字体也给出了最基本的挤压的实现。只需满足上述条件便会挤压，无论是否添加VS。但挤压需依赖变形引擎，部分变形引擎并不支持挤压，即使字体中存在代码也无法实现。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
0 0︀ ∅︀ ∅ ℰ︀ ℰ︁ ℰ 强制 数学相关SVS
She said, “Okay.”
她说：“好的。”		 强制 引号自动变形、标点挤压
あ，︀あ，︁ア、︀ア、︁ 强制 标点符号SVS
　　注：由于TH-Times中并未收录中日韩越统一表意文字，所以字体测试表格中的汉字字体与预期字形列的图片有出入的可能，属正常现象。后同。

5.2 彩色字体
　　由于历史原因，目前存在多种彩色字体格式，有微软提出的COLR/CPAL表对、Adobe和火狐联合提出的SVG表、谷歌提出的CBDT/CBLC表对和苹果提出的SBIX表。较为流行的格式为后两种，因安卓与苹果的流行而流行，但利用这些表的字体在Windows上却根本无法读取，并且这些表内嵌入的是png格式的点阵图，放大会失真。自Win10的某个版本起所支持的彩色字体便是第一种格式，这种格式在较新的安卓系统上也能被支持，稍旧一些的安卓系统便只有部分软件能够读取其彩色部分，而无法读取彩色部分也不影响字体能够被正常读取，只是字形会变成黑白字形。COLR/CPAL表对所使用的技术为拆解字形并分别上色，故支持矢量，放大不会失真，能够与非彩色的字符完美融合在各个环境中；只是因为其需拆解字形的缘故，越是丰富的颜色就需要越多的字形，而字体本身存在65535字形的限制，故此类字体的颜色将会偏单调一些，一般也不太会有渐变效果。
　　TH-Times中所采用的彩色字体格式便是微软提出的COLR/CPAL表对。字体中包含一小部分的emoji，凡是字体中收录并且在Unicode的emoji数据库中存在的字符，一律制作了彩色字形(尽管有些偏黑色的字形看上去仍像是黑白，但在指定文本颜色时还是能看出不同)。这其中，若是不在emoji-variation-sequences.txt中所定义的，即不区分文本样式和emoji样式的字符，不得不处理成彩色；在emoji-variation-sequences.txt中所定义的字符按使用需求，酌情将部分字符的默认字形处理成彩色、另一部分处理成黑白，但都能够通过手动添加VS的方式在两者之间切换。由于emoji的制作难度相对较高，故短时间内TH-Times无法支持全部emoji，但会以支持全部为目标逐渐添加。
　　除第二章节所提到的字库logo与emoji之外，TH-Times还对另一些字符制作了彩色字形，目前有日本将棋、麻将牌、多米诺骨牌、扑克牌(包含塔罗牌)、中国象棋(同时针对韩国将棋棋子做了本地化处理)和诗篇体巴列维文的标点符号。
　　日本将棋棋子字符本身属于emoji，本就应当做彩色；但棋子上并没有字。有字的棋子在Unicode中没有任何单独码位，也没有任何明文的定义，一般的做法应当是用“棋子字符+对应汉字”的形式呈现，但一来TH-Times无添加汉字的计划，二来棋子放置在前方其在变形时的Script可能受前方字符影响而导致变形失败，因此选择了“棋子英文名(King、Rook、Bishop、Gold、Silver、kNight、Lance、Pawn)缩写+棋子字符”的呈现方式。小写字母表示普通棋子，大写字母表示升级棋子；特殊地，小写k表示“王将”，大写K表示“玉将”，这是双方同一个棋子的不同名字，不表示升级。
　　麻将牌区块儿原本只有红中存在emoji样式，但所有麻将牌均做成彩色显然是更合理的做法。并且字体中还针对日本麻将的白板与一条的字形做了本地化。若在非日语环境下欲需手动切换，可在麻将牌字符后加入Tags区块儿(U+E0000~U+E007F)的J、P，并以CANCEL TAG(U+E007F)结尾；若在日语环境下欲手动切回 ，可手动添加Tags区块儿的C、N，同样以CANCEL TAG结尾便可。日麻中还存在多种红宝牌，常见的为点数为五的三种数牌，但实际上所有奇数数牌均存在红宝牌的形式，甚至连白板也存在，字体对这些特殊牌均提供了支持，对应序列为“原麻将牌+ZWJ+红色方块儿(U+1F7E5)”。若您的环境不支持彩色字体，显示为黑白时，红宝牌的图案上将会多出一个小圆点儿以示区分。在富文本中，非日语环境下日麻的本地化字形也可用ss01调出、红宝牌也可用ss02调出。
　　调用中国象棋区块儿的韩式本地化字形方法与日麻类似，可切换语言环境，可使用Tags区块儿的K、R，也可用ss01。
　　诗篇体巴列维文存在两个彩色的标点符号，分别为U+10B99和U+10B9A。其需要被染色是因为古籍中本就以颜色来区分这两个标点符号。在无法调用彩色字体的环境中，红色的圈儿将被空心圈儿代替。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
⭐︎⭐️ ㊙︎㊙️ 🀄︎🀄️ 强制 emoji相关SVS
#️⃣ 2️⃣ 强制 emoji序列
🐱 🐶 非强制 TH-Times特色emoji
R☖ n☖ k⛉ P⛉ 非强制 将棋序列
🀝‍🟥 🀢 🂁 🂡 🩬 非强制 非emoji彩色字符
🀆󠁊󠁐󠁿 🀐󠁊󠁐󠁿 🩠󠁋󠁒󠁿 🩩󠁋󠁒󠁿 非强制 Tags

5.3 本地化字形
　　如前两节所述，中日韩标点符号、麻将、中国象棋也存在本地化字形。通过添加VS或Tags等固然是可行的手动切换的方案，但在一些特定的语言环境下，默认就能将字符变为对应语言环境下的本地化字形，无需添加任何额外的字符。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试环境
文字，文字、 强制 简体中文
文字，文字、 强制 繁体中文
🀆 🀐 🩠 🩩 非强制 简体中文
🀆 🀐 🩠 🩩 非强制 日语
　　注：由于日麻与韩国将棋一般不会出现在对方的语言环境下，因此字体中为了节省代码，将日语环境与韩语环境的本地化合并(由于麻将和象棋的Script属于common，本地化相关的代码需要重复写在每一个Script下面，部分Script本身存在本地化字形时需要合并相关feature，若日韩分离则需要引入十余组新的feature，将多出百余行较为鸡肋的代码)，故通过日语环境也能调出韩国将棋；同理，在韩语环境下也能调出日麻。

§6 传统蒙古文/八思巴文
　　传统蒙古文与八思巴文均为“自上而下书写，从左到右换行”的文字，但由于技术限制，在Unicode收录字符时，把字母逆时针旋转了90度(俗称“趴下”；另有“躺下”一词俗指顺时针旋转90度，使文字行进方向及换行方向同阿拉伯文，但在竖向排版时这种处理方式会让文字行进方向变为反人类的下至上)，变为横排左至右，以方便在正常行高下与其它文种混写。受排版美观影响，本章字体测试用表中未将其竖向排列(尽管技术上能够支持)。
　　传统蒙古文区块儿中同时收录了胡都木蒙文、托忒蒙文、锡伯文、圈点满文、无圈点满文、达斡尔文、蒙文阿礼嘎礼、托忒文阿礼嘎礼和满文阿礼嘎礼，多达9个书写系统。该区块儿的变形异常复杂，且各家的方案仍争论不休。TH-Times中的传统蒙古文区块儿字形来自Mongolian Baiti，并根据民委方案等已有的变形规则总结出一套适用于整个区块儿的“大一统变形规则”，基于此补充了少量缺失的字形，并重写变形逻辑相关的代码。具体变形规则及增删某些规则的原因可见《蒙古文字变形规则说明》一文，此处不再过多赘述。
　　八思巴文区块儿字形微调自Noto Sans PhagsPa，修正原字体中放反了的pha(U+A84D)和ba(U+A84E)，并通过字体中的代码大幅节省了字形数量，以在字母之间自动生成字干的方式衔接。另，八思巴文区块儿存在一些标准化变体序列(定义见第5章)，用于手动切换一些用于书写梵语的镜像字母是否需要根据上下文镜像。
　　由于传统蒙古文为连写体，同一个字母在单词的不同位置出现时存在不同的写法，蒙文区块儿的变形除字体中的代码外依赖于系统的变形引擎。在Unicode11.0中加入的U+1878与在Unicode14.0中加入的U+180F在目前的许多系统上仍不被支持，此时即便字体中有正确的代码也无法完成变形(类似情况后同，后文不再重复)。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ᠨᠣᠮ‍ᠯᠠᠪᠠᠢ 非强制 带有ZWJ的历史连字
ᠪᠢᡸᠢᠨ 强制 U+1878能否为变形引擎所支持
ᠰᡝᡴ᠏ᡨᡝᠮᠪᡳ 强制 U+180F能否为变形引擎所支持
ᡬᢅᠣ 强制 baluda附标归位
ꡩꡖ︀ ꡪꡞ 强制 梵语镜像字母变形及SVS

§7 右至左连写文种系列
　　截至目前的Unicode15.1，存在11个右至左连写的文种(连写即同一个字母在单词的不同位置出现时存在不同的写法，上一章中的传统蒙古文和八思巴文亦属于连写体，但文本行进方向非右至左)，分别为：阿拉伯文(Arabic)、叙利亚文(Syriac)、恩科文(N'Ko)、曼德恩文(Mandaic)、摩尼文(Manichaean)、诗篇体巴列维文(Psalter Pahlavi)、哈尼菲罗兴亚文(Hanifi Rohingya)、粟特文(Sogdian)、回鹘文(Old Uyghur)、花剌子模文(Chorasmian)、阿德拉姆文(Adlam)。TH-Times对这11个文种提供了完整的支持。

7.1 镜像符号
　　在右至左文本中出现的一些标点符号、数学符号需要变为镜像字形。一些成对出现的符号，例如各种括号，出现在右至左文本中时，变形引擎会根据Unicode Character Database中的数据自动调用相当于其对称字形的字符在字体中的字形，并非机械地翻转原码位对应的字形，也无需字体中存在任何代码；但对于一些不成对出现的符号(主要为各种数学符号，在阿拉伯文中尤其常见)，需要根据文本行进方向通过字体中的代码替换为镜像字形。需要注意的是，对于右至左非连写文种(例如后文中的希伯来文)，镜像同样适用。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
د(س) 强制 成对符号默认翻转
؜∑ل∠ى 强制 不成对符号翻转

7.2 阿拉伯文
　　字体中支持Unicode15.1中定义的所有阿拉伯文字母。同时根据Unicode Pipeline增补了将要收录于Unicode16.0的字母(码位已定且无特殊情况不会再有改变；但有再增加新字母的可能性)。字形主要来源于原Times New Roman，并作出一些修改和增补，有零星一部分字形来自Scheherazade New(主要为作为附标的字母)。
　　阿拉伯文区块儿中存在一些前置连接标记(Prepended Concatenation Mark)，在字符序列中置于数字字符前方，最终显示效果应贯穿整个序列直至遇到非数字字符为止。此处的“数字”可以是一般意义下的“阿拉伯数字”(即基本拉丁区块儿的数字)，也可以是阿拉伯文专用的数字(位于阿拉伯文区块儿)；特殊地，U+0605亦可用于科普特数字。一般而言这类字符可根据数字字符的序列长度延伸至无限长，但对于U+06DD这个完全包围在数字外面的字符，其无法无限拉长，故容纳的数字数量有限，字体中继承了Times New Roman的数量上限，即最多三位数。需要注意的是，虽然阿拉伯文的行进方向为右至左，但阿拉伯文中的数字仍然为左至右，因此这些字符也应当按照左至右的行进方向进行排列和变形，而一些变形引擎会误将这些字符按照右至左的行进方向变形，使得其显示效果向前贯穿而非向后。此类情况为变形引擎的错误，与字体无关。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
1234؀5678 强制 阿拉伯数字
١٢٣۝٤٥٦ 强制 阿拉伯文数字
؅𐋡𐋠𐋠𐋭𐋠𐋨𐋠𐋷𐋰𐋦 强制 科普特数字、附标归位
　　阿拉伯文在连写之上也存在一些强制连字，除跨书写系统普遍存在的lam(U+0644)及其派生与alef(U+0627)及其派生的连字之外，还有神名“安拉”和“穆罕默德”的连字。这两个连字在仅输入基本字母时，附标会自动出现；若在其中输入任何附标(包括U+034F，Combining Grapheme Joiner，简称CGJ)，则连字本身的附标将消失，仅保留输入的附标。而在Unicode16.0中，会增加一个用于古兰经的较为特殊的附标Combining Alef Overlay，码位为U+10EFC，在其之后叠加上附标时上附标会歪到右侧。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
مَلَࢁُُمِّن 强制 lam-alef派生连字、附标归位
الله محمد 强制 神名连字
ࢁُوْلَ𐻼ٓىِٕكَ 强制 特殊附标叠加
　　哈萨克文为阿拉伯文的其中一个子书写系统。不同于传统蒙古文区块儿的音位模型，阿拉伯文区块儿一般被认为是形位模型。哈萨克文固然亦可以按字形直接输入，但U+0675、U+0676、U+0677、U+0678四个字符却是为音位模型而设立的。因此可以说，在Unicode中哈萨克文存在两种编码模型。能正确支持音位模型的字体几乎不存在，但其作为Unicode的一部分，TH-Times有义务去支持；并且使用音位模型有方便排序、方便用程序进行转写等优点。
　　根据哈萨克文的规则，如果一个单词中第一个元音是前元音(阴性元音)，且该单词中没有[k]、[ɡ]、[e]这三个只可能出现在阴性词中的音，那么需要在单词整体的右上方添加一个hamza标记(U+0674，high hamza)以与阳性词作区分。又，在元音前后表示半元音[j]和[w]的字母yeh(U+064A)和ve(U+06CB)也可以单独作为音节核，在阳性词中分别读作[əj]和[uw]，在阴性词中分别读作[ɨj]和[yw]，但Unicode中却没有与U+0675、U+0676、U+0677、U+0678这四个字母功能相同的字符yeh和ve存在，这给一部分yeh或ve作为音节核的单音节阴性词带来了困扰。考虑到其实际读音，但又不能影响其它书写系统的正常运作，字体中给出了利用带有ZWJ的序列的一种特有的实现方式——即先按实际发音输入元音字母，随后输入ZWJ，再输入yeh或ve，字体会自动连成一个单独的字母，这样就能够区分作为音节核的yeh或ve的阴阳性了。
　　此外，U+0677与U+06C7上方形状类似逗号的发音符号，在早期版本的Unicode的示例字形中被误当作damma附标(U+064F)，但实际上其来源不同，并且U+06C7并不存在标准分解形式，不应混淆。虽然Unicode的示例字形已经修复，但市面上多数字体仍然是错误的；且后者不仅仅出现在哈萨克文中，维吾尔文、柯尔克孜文等书写系统也有使用，正确区分显示不同文种中来源不同的字母或字母组合是非常有必要的。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
باسپا سٶز 强制 哈萨克文音码模型
بٸ‍يت تٷ‍ۋ 非强制 音节核半元音字母的ZWJ连字
وُ ۇ 强制 易错形近字母区分
　　TH-Times中，在波斯语、喀什米尔语、马来语、信德语、乌尔都语语言环境下一些标点符号、数字、字母存在本地化字形。除信德语的字母meem(U+0645)及其派生外，其余本地化字形均直接继承自Times New Roman。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试环境
𞺌،۴٫۶ 强制 阿拉伯语
𞺌،۴٫۶ 强制 波斯语
𞺌،۴٫۶ 强制 喀什米尔语
𞺌،۴٫۶ 强制 马来语
𞺌،۴٫۶ 强制 信德语
　　注：喀什米尔语与乌尔都语环境下的本地化字形完全相同，故表格内举喀什米尔语以赅乌尔都语。

7.3 叙利亚文
　　叙利亚文存在三种较为常见的风格，分别为古典风格(Estrangela)、西部风格(Serta)和东部风格(Madnhaya)。TH-Times同时支持这三种风格，可通过本地化进行切换，默认为古典风格。其中，古典风格字形微调自Estrangelo Edessa；西部风格字形微调自Serto Jerusalem；东部风格字形微调自East Syriac Adiabene。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试环境
ܠܫܢܐ ܣܘܪܝܝܐ 强制 古典风格
ܠܫܢܐ ܣܘܪܝܝܐ 强制 西部风格
ܠܫܢܐ ܣܘܪܝܝܐ 强制 东部风格
　　叙利亚文中存在专用于单词缩写的标记，自缩写部分起至词尾结束在字母正上方划一条横线。印刷体中横线两端常常带一圆点，且若横线较长，其中间也会带一圆点。在字符层面，需要在缩写部分开始的正前方输入U+070F，变形引擎将通过一种特殊的拉伸方式将横线拉至词尾结束处，宽度自适应。
　　在需要延长字干、或通过手动插入字干来调取字母的连写形式时，叙利亚文使用阿拉伯文区块儿的tatweel(U+0640)。由于tatweel的Script_Extension值中存在Syrc(即叙利亚文)，理论上在编码层面如此操作并无不妥，但是由于各设备自带的字体往往会将阿拉伯文与叙利亚文分开，很少能够见到同时支持阿拉伯文和叙利亚文的字体，在常规的字体fallback逻辑下，U+0640往往会调用阿拉伯文字体，导致与周围的叙利亚文字母无法正常衔接。TH-Times中同时包含了阿拉伯文与叙利亚文，并针对叙利亚文环境及三种风格的环境分别给tatweel制作了本地化的字形，因此能够打破这一僵局。后文中其它需要用到tatweel以延长字干的文种亦有相同问题，但不再重复赘述。
　　使用叙利亚文书写经文时，常常会用到阿拉伯文区块儿的一些元音附标。然而，在Unicode Character Database中，阿拉伯文区块儿的元音附标的Canonical Combining Class(后文简称CCC)小于组合用附加符号区块儿(Combining Diacritical Marks)的字符的CCC，根据字符序列规范化的规则，在调用字体之前，变形引擎会先自动把组合用附加符号区块儿的字符调整至阿拉伯文区块儿的元音附标字符之后；这显然并不符合预期结果，因为组合用附加符号区块儿的字符的作用是改变辅音的读音，应该出现在元音附标之前。此时需要在两个附标之间插入CGJ(U+034F)以阻止变形引擎将附标自动交换。需要注意的是，一些变形引擎在调用字体之前并没有根据附标的CCC先交换顺序的步骤，即使显示出来的效果符合预期了，也反而应该视为错误的变形结果。叙利亚文的这种情况从字符序列层面本身就是应该插入CGJ的。
　　在叙利亚文扩展区块儿，收录了11个书写马拉雅拉姆语专用的字母。由于这些字母仅存在东部风格，与其它字母混用时，若其它字母以古典风格或西部风格显示，则无法良好衔接，因此只要一个单词之内存在马拉雅拉姆语专用字母，无论处于什么环境中，整个单词都会变为东部风格显示。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ܒـ܏ܝـܗ 强制 缩写标记、tatweel本地化
ܡُܨ݁͏ْ͏َܛَܪِܒَܗ̈͏ً 强制 CGJ阻止附标自动交换
ܦܛܢܢࡪܡ 非强制 东部风格自动扩散

7.4 恩科文
　　TH-Times中的恩科文字形来自Ebrima，并作出少量修改(主要为合并一些附标)和增补。

7.5 曼德恩文
　　TH-Times中的曼德恩文字形来自向Unicode技术委员会提出申请收录该文种的提案。

7.6 摩尼文
　　TH-Times中的摩尼文字形微调自Noto Sans Manichaean。
　　摩尼文存在一组特殊的连字，能够改变连写类型。就Unicode Character Database中的数据而言，字母sadhe(U+10ADD)的连写类型为“右连”(即只能和前方的字母连接，无法和后方的字母连接，以此类推)，字母nun(U+10AD7)的连写类型为“左连”。理论上，sadhe与nun相遇时无法连接；实际上，其不但能够连接，且sadhe与nun的连字的连写类型为“右连”——换言之，若sadhe与nun的连字之后还有其它能够向前连写的字母，理论上需要连写，实际上却无法连写，需要特殊处理。
　　摩尼文数字拥有与字母同样的能够连写的属性。其中有一个较为特殊的数字，即摩尼文数字10(U+10AED)，其左右两侧衔接点高度不同，需要特殊处理。
　　另，摩尼文区块儿存在一些标准化变体序列(定义见第5章)，可用于手动切换一些字母的异体写法。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
𐫝𐫗𐫡︀ 强制 特殊连写类型、SVS
𐫬𐫫𐫯 𐫭𐫬𐫫𐫫 强制 摩尼文数字617

7.7 诗篇体巴列维文
　　TH-Times中的诗篇体巴列维文字形微调自Noto Sans PsaPahlavi。

7.8 哈尼菲罗兴亚文
　　TH-Times中的哈尼菲罗兴亚文字形来自向Unicode技术委员会提出申请收录该文种的提案。此外，对于字母da(U+10D0A)与字母la(U+10D13)的独立形与词尾形、字母dda(U+10D0B)的所有连写形式，字体中提供了风格变体，在富文本中可通过开启ss01以调用。

7.9 粟特文
　　TH-Times中的粟特文字形来自向Unicode技术委员会提出申请收录该文种的提案。在连写时，存在一个特殊的字母mem(U+10F3A)，与前文中提到的摩尼文的数字10类似地，其左右两侧衔接点高度不同，因此会给在其之后的字母创造一个比基线略高一截的“第二基线”。此外，对于字母zayin(U+10F35)、字母heth(U+10F36)、字母kaph(U+10F38)、字母nun(U+10F3B)、字母sadhe(U+10F3F)、字母taw(U+10F42)的独立形与词尾形，字体中提供了风格变体，在富文本中，前四者可通过开启ss01以调用；后两者可通过选择开启ss01/ss02/ss03/ss04之一调用，或通过aalt手动选择想要的异体字形。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
𐼼𐼺𐼰𐽀𐼸𐼻𐼹𐼿 强制 第二基线
𐼸𐼴𐽂𐽐𐼷 强制 连字、附标归位

7.10 回鹘文
　　回鹘文为传统蒙古文的前身，曾被提案作为传统蒙古文区块儿已有的字符的FVS和SVS加入Unicode，后被否决，于Unicode14.0单独设区。该区块儿字形微调自Noto Serif Old Uyghur。在连写时，存在一个特殊的字母mem(U+10F79)，与前文中提到的摩尼文的数字10类似地，其左右两侧衔接点高度不同，因此会给在其之后的字母创造一个比基线略高一截的“第二基线”。此外，对于字母kaph(U+10F77)与字母sadhe(U+10F7D)的独立形与词尾形，字体中提供了风格变体，在富文本中可通过开启ss01以调用。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
𐽷𐽰𐾁𐽹𐽰𐽸𐽳𐽷 强制 第二基线
𐽷𐽳𐽶𐽺𐾂𐽶 强制 连字、附标归位

7.11 花剌子模文
　　TH-Times中的花剌子模文字形来自向Unicode技术委员会提出申请收录该文种的提案。
　　花剌子模文区块儿有一个比较特殊的字母aleph(U+10FB0)，它的连写属性为“双向”，且词中形也正常存在，但却意外地缺失词尾形。因此若它出现在词尾或不可向前连写的字母之前，且前方字母能够向后连写时，需对前方字母进行特殊处理(即词首形变为独立形、词中形变为词尾形)，而其本身则使用独立形。原提案中认为，这种情况应该在aleph之前插入ZWNJ以手动阻断连写；但aleph根本不存在词尾形，因此默认情况下直接阻断更妥。此外，原提案中还提到，字母zayin(U+10FB8)和字母pe(U+10FC1)也常常见到不向后连写的情况；但它们和aleph的情况存在本质区别，因为zayin和pe只是“存在不向后连写的情况”，与此同时“向后连写”的情况同样也是存在的，因此对于不向后连写的情况需要手动插入ZWNJ以阻断。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
𐾽𐾼𐾻𐾰 强制 词尾aleph自动阻断连写
𐾰𐿁‌𐾲𐾾𐿄𐾾 强制 ZWNJ手动阻断连写

7.12 阿德拉姆文
　　TH-Times中的阿德拉姆文字形微调自Noto Sans Adlam旧版(最新版已经从衬线体改为无衬线体)。阿德拉姆文连写与否皆可，但根据Unicode中对字符连写属性的定义，默认情况应处理为连写。若欲手动切换为非连写，可在每两个字母之间插入ZWNJ(通用性较好，纯文本亦可使用，但较为繁琐)，也可开启ss01(仅富文本可用，但较为方便)。
　　阿德拉姆文有一个特殊的字符——鼻化标记(U+1E94B)，它拥有宽度，但连写属性却是“透明”(即该字符在连写变形阶段会被忽略)。因此当它出现在两个字母之间时，需要在连写变形阶段之后特殊处理。另，U+1E94A一般作为上加点出现在字母顶端，但如果存在其它上附标，则其会变为下加点出现在字母底部。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
𞤸𞤭𞤲𞥋𞤣𞤵 强制 鼻化标记连写
𞤃𞤋𞥅𞤔𞤌 𞤥𞤭𞥅𞤶𞤮 强制 长元音标记区分大小写
𞤔𞥊𞤫𞥊𞥅𞤼𞤵𞥅𞤲 强制 U+1E94A位置变化

§8 假名与汉文
　　假名在Unicode中分布于多个区块儿，除最常用的平假名区块儿、片假名区块儿外，还有阿伊努语小假名区块儿、假名扩展、小假名增补、半角片假名等。TH-Times中的假名字形主要来源于三番明朝(其修改自IPA明朝，对部分假名的细节处理做了调整，详见http://www.akenotsuki.com/eyeben/)，并据此适当修改、增补了一些字形。此外，台湾语假名的声调符号字形来自CodeCharts。

8.1 埼玉市地名字形
　　平假名的sa在一般情况下，写作两画或三画均可(且手写常常作三画，即右至左的运笔处断开)，而埼玉县埼玉市(日语：埼玉県さいたま市)为了“营造统一感”，其官方规定，在写地名时必须采用两画的字形。在他们的官方文件中也能看到普通的sa写作三画与地名的sa写作两画同框出现的例子。因此在字体中，特地添加了当sa出现在地名中时由三画变成两画的变形功能。当然，在非正式的场合，用三画的sa书写该地名严格意义上也不能算“错误”，但是这是“不够规范的”。若该序列出现在了实际非该地名的词组中，欲切换回三画，请使用ZWNJ阻隔之。字体测试表格请见本章节末尾。

8.2 冲绳语假名
　　冲绳语假名，为船津好明以普通的平假名为原型发明的一套专用于记录冲绳语(首里方言)中特殊的音节的假名方案。例如音节ti，在日语中常写作片假名大写te+小写i的组合，而在冲绳语假名中，即为平假名te与i的合字。由于ti在日语中一般用于记录外来语词汇，故一般使用片假名，对应的平假名序列并无太大的实际意义，此处正好能够借来以连字的方式直接实现为对应的冲绳语假名而不对日语文本产生较大影响。音节ʔwi、ʔwe原为平假名u与wi、we的合字，但平假名的小写wi、we码位处于扩展区，许多系统的变形引擎并不支持其连字，且输入也较为不便，因此实现为平假名u与小写i、e的序列。带有喉塞音的拨音使用促音+拨音的序列。与拉丁字母章节的连字部分所述相同地，若欲断开连字，请插入ZWNJ阻隔之。附带说明：字体中假名区块儿也存在数个需要手动插入ZWJ才能连成合字的情况(此与冲绳语假名无关)。字体测试表格请见本章节末尾。

8.3 浊点附标
　　在平假名区块儿中存在两个零宽附标，分别为浊音点和半浊音点，其主要用于与假名结合，但也可与其它文种结合(因其Script属Inherited，所以序列符合规范，与注音符号的结合也存在用例，字体中的该部分实现详见注音符号章节)，且不存在多个浊点叠加的情况，理论上只要给字形做成零宽即可在绝大部分情况下正确归位。但是对于小假名而言，位于高处的大浊点并不美观；对于部分右上角被占用的大假名而言，直接将浊点加到右上角的固定位置也会造成重叠甚至穿插，这时候，为了美观起见，仍需调整其大小与位置。字体测试表格请见本章节末尾。

8.4 小假名
　　除散落在基本的平假名、片假名区块儿的小假名与阿伊努语使用的小假名区块儿外，在第1平面的小假名增补区块儿亦有一些小假名。小假名增补区块儿的来源最早可追溯至2016年字库作者以《广辞苑》中的文本提交小写wi和we的提案，随后引来数位日本专家用早年的文献和外国地图上的音译文本提交了许多各式各样的小假名，但至今小假名增补区块儿的绝大多数码位都处于暂时予以保留的状态，截至Unicode15.1，真正加入Unicode的只有9个。由于带浊点的假名能通过零宽附标的方式实现，在如今的技术条件下不可能再予以分配单独码位，对于普通的小假名，结合已经分配的码位和已经加入Unicode的假名，容易推算出所有暂未收录的小假名在小假名增补区块儿理应所在的位置——Unicode15.0新增的两个小假名也证实了推算的正确性。故，即使CodeCharts中暂未有部分小假名的身影，字体中也已经在推算的码位上收录了所有应有的小假名。这些码位只有可能在日后新增对应的假名，不可能作其它用途也不可能临时更换策略收录其它假名，因此提前加入字库并无影响。下表将列出Unicode中所有小假名所在的码位(包括推算的部分；表格中所列为对应的大假名，防止因未安装或无法安装字库导致无法显示)：
U+ 0123 4567 89AB CDEF
304x あい うえ お
306x つ
308x や ゆよ わ
309x かけ
30Ax アイ ウエ オ
30Cx ツ
30Ex ヤ ユヨ ワ
30Fx カケ
31Fx クシスト ヌハヒフ ヘホムラ リルレロ
1B13x きくこさ しすせそ たちてと なにぬね
1B14x のはひふ へほまみ むめもら りるれろ
1B15x ゐゑをん キコサセ ソタチテ ナニネノ
1B16x マミメモ ヰヱヲン

8.5 私用区
　　早在3.0.0版本的字库中，增补私用平面B(即第16平面)的U+1017E0~U+10183F这96个码位上已被安放了96个假名。4.0.0版本在U+101840~U+10185F新加入了32个假名，并同时引入TH-Times。这些假名中有小写的wi和we(在其正式获得Unicode编码前便已加入字库，为兼容旧版本，这些码位暂不撤除，并且保留仍存在其他用途，详见下文)、较常用的带浊点的预组合假名与台湾语假名。
　　除小写的wi和we外，在输入符合Unicode标准的序列时，也会调用这些被安放至私用区的预组合字形。台湾语假名的上加横线为U+0305、下加圆点为U+0323，均可组合输入。但在部分程序中并不支持组合，此时便可选择私用区的码位作为备用。此外，在纵向排版时，一般默认将文字也旋转90度，而汉字、假名等字符是不旋转的，这需要程序或系统有对应的文件对每一个码位属于哪种类型作出规范，而Unicode中新加入的字符甚至新加入的区块儿在一些较旧的软件中往往无法被识别。例如在Word2013中，标准码位的小写wi和we在纵向排版时仍会被旋转90度，这是我们不想看到的，此时若使用私用区的码位代替之，便可达到想要实现的效果——当然，私用区的码位在使用的时候需谨慎，因为Unicode并不对该区块儿的任何码位作出任何定义，完全由用户自行规定，如若将Word导出为PDF，那么使用私用区的码位是完全没有问题的；但如若需将Word格式的文档直接传送给他人，请切记，除非告知对方安装对应字库，否则不要使用私用区的码位。

8.6 汉文训读
　　汉文训读体的文本在竖排时一般在汉字的左下方标返点(必选)、在右下方标送假名和虚词(可选)，而横排时往往会将返点标至汉字右下方、送假名和虚词标至右上方。目前许多字体的汉文返点区块儿的字形均做在了右上方，这是不符合习惯的。此外，送假名和虚词虽然不是必选项，但是在许多地方也是会出现的，目前Unicode并未给“片假名的上标形式”专开区块儿收录，因此为了在纯文本中能支持汉文训读体的文本，字体针对片假名做了一些特有的实现——若是在富文本中自然无此需求，但富文本也不需要将返点单独收录，直接用对应的汉字下标(若是竖排则为左标)即可，既然返点开了区块儿单独收录，甚至前些年还有提案要增加新的返点用于欧文训读，那么作者认为，在纯文本中支持片假名的上标是有必要的。
　　由于需要上标的假名出现的环境不固定(有些出现在返点之后，有些出现在汉字之后；并且返点的Script属于Common，其在变形时会继承前方汉字的Han属性)，因此无法直接通过上下文判定是否需要返点；故字库采用“片假名+Zero Width Space(U+200B，以下简称ZWSP)”的序列进行实现。若返点之后没有上标假名，而是直接紧跟汉字或标点符号，在有些变形引擎下返点的宽度会意外地消失，此时若考虑多平台兼容性，可在返点之后亦插入ZWSP。需要注意的是，若返点之后有上标假名，则返点之后不可插入ZWSP，否则上标假名将无法缩进。此实现方式不会对正常的日语文本产生任何影响，因普通的日语文本中没有使用零宽空格的需求。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
小さい‌たま
ごを持って
さいたまに
来てください		 非强制 平假名sa的笔画数
てぃんさぐぬ花
ふゎむれーうた		 非强制 冲绳语假名
く゚ て゚ ィ゙ ㇷ゚ 强制 浊点附标归位
楚人ニ​有㆘リ​鬻㆓グ​
盾ト​与㆒㆑ヲ​矛者㆖​。		 非强制 汉文训读假名上标

§9 注音符号
　　即使在一般的宋体/明体中，按习惯注音符号也会被做成楷体的样式；但在TH-Times中，所有注音符号均被宋体化——这只是风格的差异，并无对错之分。拼接注音符号所用到的笔画来源于思源宋体。
　　当前Unicode中所收的注音符号可用于书写汉语官话、粤语、闽南语和苗语。对于所有表示声母的字符和汉语官话、粤语、闽南语、苗语中所用得到的韵母的组合，字体默认采用了拼合的方式以方块字的视觉效果显示每一个音节(儿化音韵尾、入声韵尾除外)。若需阻断拼合，请手动插入ZWNJ。同时，由于汉语官话所用的注音符号上也常常会加上声调，因此拉丁字母章节中所述的所有附标也能对注音符号进行使用，包括零宽附标和环绕附标。
　　汉语官话的儿化音韵尾默认变形为小字(横排靠下，竖排靠右)；闽南语注音符号曾有方案将鼻音韵尾写作单独的小字，而非韵母的一部分，由于Unicode未单独收录这些字母，维基百科上相关词条中使用了大字加下加点附标(U+0323)的形式代替，因此TH-Times也提供了“可用作韵尾的字母+下加点附标”显示为小字的变形。若需阻止该变形，即将下加点附标原封不动地归位到大字之下，可在大字与下加点附标之间插入CGJ。
　　目前仍有一些其它方言所采用的注音符号方案中的字符暂未加入Unicode。部分存在塞音清浊送气三对立的方言(例如吴语)的注音符号方案中，出现了用不送气清音的符号加浊音点表示浊音的方案，因此，注音符号也能同浊点附标一同使用。但这些方言所采用的方案的韵母的字符并不一定存在于Unicode，即使存在也不能够保证韵母组合能够被汉语官话、粤语、闽南语、苗语用到，因此极大概率存在无法拼合的情况。
预期字形 您的浏览器 变形类型 测试内容
ㄍㄡ̌ㄌㄧ̀ㄍㄨㄛ́ㄐㄧㄚ̄ㄕㄥ̄ㄙ̌ㄧ̌
ㄏㄚ̍ㆻㄒㄧㄥㄉㄧㆰ̄ㄉㄧㆰ̄ㄊㄧㆩ		 非强制 音节合字、零宽附标归位
ㄉㄨㄤㄉㄨㄤ⃞ㄉㄨㄤ 强制 环绕附标归位
ㄇㄧㄠㄦ ㄉㄧㄚㄇ̣ ㄇ͏̣ 非强制 小字相关变形
ㄅ゙ ㄐ゙ ㄕ゙ ㄏ゙ 强制 浊点附标归位
　　注：环绕附标归位的测试中，变形类型的“强制”仅指附标归位的变形，注音符号本身的音节拼合应当属于“非强制”。
　　按中国大陆的习惯，在横排时韵母i通常写作一竖；然而在竖排时，或在台湾地区，其通常写作一横。因此字体中也对此做了本地化处理。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试环境
ㄊ‌ㄧ‌ㄢ ㄉ‌ㄧˋ 强制 简体中文
ㄊ‌ㄧ‌ㄢ ㄉ‌ㄧˋ 强制 繁体中文

§10 苏州码子
　　TH-Times中，拼接苏州码子所用到的笔画来源于思源宋体。字形根据京张铁路所使用的标志及Night Koo向Unicode技术委员会提交的提案(见https://www.unicode.org/L2/L2023/23167-suzhou-nine.pdf)制作，部分字符与CodeCharts中所示字形有些许差异，可以认为是CodeCharts的示例字形存在错误。此外，苏州码子的1、2、3在连续书写时须纵横交替，但鲜有字体能够正确支持。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
〦〧〨〩 强制 与CodeCharts有差异的字形
〡〢〣〡〢〣 强制 纵横交替

§11 藏文/札那巴札尔文
　　藏文与札那巴札尔文在辅音丛的堆叠方式上有一定的相似性，且均可用于书写梵语、藏语，因此置于同一章内叙述。类似的文字还有索永布文等，但TH-Times目前暂未支持。
　　TH-Times中的藏文区块儿字形微调自Microsoft Himalaya，并修正巴尔蒂语所使用的扩展字母涉及的变形(原字体中未对这些字母作出任何的变形)、修正并同时适配在多种不同的变形引擎下藏文数字加占星术附标U+0F3E、U+0F3F时的字形的视觉效果(部分系统下不变形，即附标完全在数字右侧；部分系统下变形过度，即附标完全在数字左侧；部分系统下变形符合规范，即左附标位于左侧、右附标位于右侧)、修正占星术附标U+0F18、U+0F19的变形逻辑使之能够正确归位。
　　札那巴札尔文区块儿字形微调自Noto Sans Zanabazar Square。书写藏语时，上加字需写作较扁的形式，且和基字相接，与书写梵语的辅音丛时不同；然而Unicode却只给上加字r分配了码位(U+11A3A，Cluster-initial Letter RA)，未给上加字l和上加字s分配码位。Andrew West曾向Unicode技术委员会提交过这两个上加字(见http://www.unicode.org/L2/L2018/18132r-n4945r-zanabazar-add.pdf)，但未获得通过。但由于其梵藏对立确实存在，字体中仿照天城文的Eyelash RA的处理方式，通过“辅音+subjoiner(U+11A47)+ZWJ”的序列实现藏语上加字的显示，以与梵语辅音丛进行区分。
　　下加字同样存在梵藏对立，因此藏文的下加字y(U+11A3B，Cluster-final Letter YA)、r(U+11A3C，Cluster-final Letter RA)、l(U+11A3D，Cluster-final Letter LA)、w(U+11A3E，Cluster-final Letter VA)获得单独编码，然而其Cluster-final的属性却使得其下方无法叠加其它辅音——自然也包括再叠加下加字，因此两个下加字连续出现时变形引擎会自动插入一个虚线圈儿(U+25CC)；可是藏语却用得到双下加字的音节(例如grw-、phyw-)，因此字体中对于出现在两个下加字之间的虚线圈儿做了删除处理——然而这却也带来了副作用，即使在两个下加字之间确输入了虚线圈儿的字符(而非变形引擎“画蛇添足”所插入)，也会被字体中的相关变形代码删除。这种情况几乎不会被用到，但确有需求时可通过在虚线圈儿之后插入ZWNJ以阻断上下文检测，从而阻止虚线圈儿被删除。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ཨིན་ཏེ་ཁཱ༹བ། 强制 巴尔蒂语扩展字母变形
༢༿༾ ༦༙༘ 强制 数字加占星术附标
𑨠𑨰𑩇‍𑨋𑨼𑨆𑨍𑨰 𑨰𑨸𑨰𑩇𑨋𑨼𑨉𑨙𑨢𑨴 非强制 上加字梵藏对立
𑨍𑨼𑨾 𑨟𑨻𑨾 强制 藏语双下加字

§12 希伯来文
　　TH-Times中的希伯来文字形来自原Times New Roman。希伯来文在手写时常常为连写体，然而在印刷时一般按字母断开，因此Unicode并未将其当作连写体收录，字体中也同样未做成连写体。一部分字母拥有特殊的“词尾形”，即当它们出现在单词末尾时写法有不同，但Unicode并没有将这些字母放到同一个码位上、并根据上下文自动判断是否在词尾从而进行变形，而是与希腊字母小写sigma(U+03C3；词尾形U+03C2)相似地，词尾形被赋予单独码位。而希伯来文的变形主要在于对附标的处理。
　　希伯来文与阿拉伯文类似地，元音附标通常只出现在诸如儿童图书、祈祷书、诗歌等需要明确标注元音的地方，一般情况下的正式文本仅书写辅音字母。而附标叠加时通常横向书写，与多数文种的纵向书写不同。特殊地，当带有短音符的元音附标(U+05B1、U+05B2、U+05B3)与表示重读的附标(U+05BD)组合使用时，重读附标有可能出现在元音附标之左、之中或之右，可以通过ZWJ、CGJ来处理这些不同的情况。由于U+05BD的CCC值大于U+05B1、U+05B2、U+05B3的CCC值，默认情况下变形引擎会将U+05BD交换到较后，故重读附标默认出现在元音附标之左；通过交换元音附标与重读附标的字符顺序，再在其之间插入CGJ阻止自动重排序，可使重读附标出现在元音附标之右；在两者之间插入ZWJ，发挥其“强制连字”功能，可使重读附标出现在元音附标之中。目前市面上鲜有字体能够支持这三种情况的自由切换，但在Unicode的核心规约中有明确规定，因此TH-Times不得不提供正确的支持。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ואקטוא‍ליה 非强制 带有ZWJ的连字
חֱֽ חֱ‍ֽ חֽ͏ֱ 强制 附标间的位置关系

§13 它拿文
　　TH-Times中的它拿文字形来自MV Boli。它拿文的正字法规则较为简单，所有元音均为附标且不可省略(与阿拉伯文、希伯来文等不同)；若辅音作为韵尾出现，则添加表示空韵的附标(U+07B0)。附标原则上无法叠加(即便实际上字体中也处理了叠加的情况，以清晰地展现有意或无意输入的不规范序列)，除此之外便是简单的右至左排列，除非“萝卜坑”字体，否则一般难有错误变形的情况，故本章不提供字体测试用表。

§14 撒玛利亚文
　　TH-Times中的撒玛利亚文字形微调自Noto Sans Samaritan。撒玛利亚文与希伯来文类似地，元音作为附标横向叠加。若一个辅音上只有一个元音附标，这个元音附标一般出现在辅音字母左上角；但若一个辅音上有多个元音附标，第一个元音附标通常出现在辅音的正上方，之后向左叠加。鲜有字体能够做到正确摆放附标的位置。有一些元音或半元音字母与附标具有相似的字形和高度，但存在宽度，在这些字母之后添加零宽的元音附标时，元音附标也需要变成带有宽度的字形。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ࠄࠠࠪࠍࠬࠔࠝࠌ 强制 元音附标连用特殊归位
ࠅࠧࠕࠩࠚࠟࠆࠠࠋ 强制 零宽元音附标增加宽度

§15 傣泰文字系列
　　傣泰文字系列中包含许多文种，其编码模型五花八门。TH-Times目前仅支持泰文和老挝文，这两个文种都是按视觉顺序编码的，并且存在需要归位的附标；后续版本将逐渐加入其它文种，有与婆罗米系文字类似的以逻辑顺序编码的柬埔寨文等，也有以视觉顺序编码且不存在附标的纯“萝卜坑”文种，如西双版纳傣文等。

15.1 泰文
　　TH-Times中的泰文字形来自Noto Serif Thai。泰文除书写泰语外，常常也被用来转写梵语、巴利语，或书写亚维语。在书写泰语时，字母yo ying(U+0E0D)与字母tho than(U+0E10)若存在下附标，则需要把字母本身下方的笔画删除；无下附标时(无论有无上附标)则需保留。然而在转写梵语、巴利语时，无论是否有下附标，通常都省略其下方的笔画。TH-Times为了能够正确支持用泰文转写梵语、巴利语时的正字法，同时又不影响书写泰语时本身的正字法，规定在这两个字母之后紧接着输入CGJ可手动删除下方笔画，使CGJ担任与下附标相似的功能。
　　在书写亚维语时，会用到两个位于组合用附加符号区块儿的附标，其中上附标U+0303用于表示元音的鼻化、下附标U+0331用于表示辅音读音的改变。Unicode的核心规约中提到，这两个附标需要紧贴着辅音字母书写，即出现在一切泰文的元音附标及声调附标之前；但由于U+0303的CCC值为230，U+0331的CCC值为220，均大于元音附标及声调附标的CCC值，使得在默认情况下若这两个附标与元音附标或声调附标连用时，它们会被变形引擎自动交换到元音附标或声调附标之后导致显示出错。原则上这需要变形引擎进行特殊处理，但目前未见有任何变形引擎能够提供这方面的正确处理，因此TH-Times在字体层面强行提供了解决方案。然而，在Windows的变形引擎Uniscribe下，按逻辑顺序输入附标时反而会导致两个附标之间被自动插入虚线圈儿，因此在泰文环境下出现在U+0303或U+0331后的虚圈儿会在变形过程中予以删除，以保证Windows上能够变形正确。与札那巴札尔文相似地，若确需在此处显示虚线圈儿，可在虚线圈儿之前插入ZWNJ以阻断上下文检测，从而阻止虚线圈儿被删除。
　　泰文的部分元音附标与声调附标通常写在辅音字母的右上角，当其后方出现较高的前置元音字母(U+0E42、U+0E43、U+0E44)或带有写在辅音字母正上方的元音附标的音节时，若不作任何调整则会导致字母或附标重叠。也有些字体将较高的前置元音字母左侧间距做得非常大，这样一来虽然不会和前方写在辅音字母右上角的附标相重叠，但若前方字母不带有此类附标，则字母之间空隙过大，会造成误当作添加了空格的视觉效果。这种调整虽然不是强制的，但从美观角度而言却也是有必要的。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ชฺญ͏าติ 非强制 梵语特殊字母
งุ̱ ก่̃ 强制 亚维语特殊序列
ให้ได้ เกินไป 非强制 间距调整

15.2 老挝文
　　TH-Times中的老挝文字形微调自Noto Serif Lao，并增补了于Unicode12.0加入的一些专用于转写巴利语的老挝文字母。在老挝文中，niggahita附标(U+0ECD)具有多种用途，例如可表示老挝语的长元音/ɔ:/，可表示梵语、巴利语的鼻化元音，也可以与表示长元音/a:/的字母(U+0EB2)联合使用来表示老挝语中的特殊元音/am/等。特殊元音/am/虽然拥有独立的码位U+0EB3，但变形引擎在预处理字符序列时会将其分解为U+0ECD与U+0EB2，且若前方辅音字母上有任何的上附标，被分解出的U+0ECD还会立刻被进一步重排序到所有的上附标之前——若是手动按顺序输入U+0ECD、U+0EB2，是不会被重排的。但无论如何，最终参与变形的都是U+0ECD，即niggahita附标的码位对应的字形。然而，根据《基础老挝语》中的叙述及大量实例，表示/ɔ:/的niggahita需放置在辅音字母的正上方，而与U+0EB2联合使用表示/am/的niggahita却需要放置在辅音字母的右上方，这其中蕴含着较为复杂的技术细节(见https://zhuanlan.zhihu.com/p/618065951)，鲜有字体能够正确做到这一点(《基础老挝语》排版用的字体可能并非严格按照Unicode标准制作的字体)。此外，与泰文相同地，老挝文也有必要进行一些间距的调整以达到美观的效果。下表为字体测试用表：
预期字形 您的浏览器 变形类型 测试内容
ບໍ່ມັກຢູ່ນຳໝູ່ 强制 两种niggahita的不同归位
ພຸທ຺ຘໍ 强制 巴利语专用字母
ໄມ້ໂທ ບໍ່ໄດ້ 非强制 间距调整

§1021 未来计划
　　下版本将增加一些中亚、东南亚的文种，并适量增补emoji。若时间充裕，将对婆罗米系文字作出整理，确保于其它已存在的区块儿无隐患、无明显错误变形且字符数量全后引入字体。若在使用时有发现任何文种的变形错误情况，再次确认非因变形引擎不支持而是纯粹字体中代码有误后，通过本站联系页所留的联系方式尽早告知作者，若问题属实，将及时修复并予以感谢。

§1022 字体中的未定义码位
　　存在一些Unicode仍作保留而字体中已经存在字形的码位。目前这些码位主要由三个部分构成，按码位顺序为中日韩部首补充、小假名增补、数学用字母数字符号。

1022.1 中日韩部首补充
　　目前的中日韩部首补充区块儿(U+2E80~U+2EFF)存在一个“怪异”的情况，即一系列已定义的码位中间有一个码位(U+2E9A)被跳过了。通过查阅早期资料(见http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1923.pdf)可知，该码位应为作为部首使用的“无”字，且竖弯钩需与横相接触。当时在此处挖空给出的理由是“在康熙部首区已经存在，这是个重复部首”。然而，康熙部首区存在的“長”和“鬼”在部首增补区依然能够存在，究其原因，是由于字形存在细微差异，部首增补区的字形偏新字形(長字竖提相连、鬼字竖撇相连)而康熙部首区的字形偏旧字形(長字竖提分离、鬼字竖撇分离)。这样看来，“无”也并非重复，康熙部首区的字形竖弯钩并未与横接触。作者曾向Unicode申请在CodeCharts中通过箭头指向“被重复”的U+2F46，并于Unicode15.1获得正式通过。字体中将这个字形加入的原因是因为既“有据可循”，又“这个码位被注释定义过，且将永久被保留，不可能用作其它用途”。

1022.2 小假名增补
　　小假名增补区块儿位于U+1B130~U+1B16F，具体请见假名章节的相关内容。

1022.3 数学用字母数字符号
　　数学用字母数字符号区块儿(U+1D400~U+1D7FF)中也存在着数十个“洞”，其原因是这些字符在字母式符号区块儿(U+2100~U+214F)已经收录，而出于区块儿收字的规律性，这些码位被跳过。在CodeCharts中也用箭头明确注明了每个被跳过的码位其“理应”安放什么字符、这个字符当前在什么位置上，可以知道的是，这些码位由于“被注释定义过”，因此理论上也将永久被保留，而字体中加入的原因，则是在不会出现混乱的前提下既“有据可循”，又“出于规律性”——毕竟字体能不能显示是字体的事情，而用户用哪一个码位不是字体本身所能决定的。这些未定义的码位自然不推荐去使用，但万一出现“由于规律性导致错误使用”的状况，作为一种提示存在也未尝不可。

§1023 手机端的安装建议
　　在手机端安装字库的方法，下载页的手机字库一栏已给出链接，其中有详细说明。但说明中只给了可用于照猫画虎的方法，并未给出安装建议。目前已知的是，手机自带的字体即使非“萝卜坑字体”，但其支持的变形仍有限，上文中的字体测试表格即可说明许多问题。若将自带字体的调用顺序置于TH-Times之前，字库内的许多变形是无法被调出的——假设字库中有一个连字需要调用A和B两个字形，结果A出现在了系统自带的字体中，B没有，导致A调用了系统自带的字体而B调用了字库，这时显然无法连字。这也是许多设备上蒙古文的附加成分字形会出错的直接原因——U+202F优先调用了西文字体。上文叙利亚文一节中的例子亦说明了这个问题。这也是TH-Times欲把各文种的复杂变形集中到一个字体中的原因之一——另外的原因，例如上文中提到的弯引号问题，这些都是在跨字体时无力解决的，因此只有合并才是最优解。
　　简而言之，TH-Times应置于最先调用的位置，否则其存在完全没有意义。而其它字库或天珩全字库中的其它字体则建议置于最后调用的位置，防止其“萝卜坑字体”属性影响TH-Times中暂未支持、而系统自带字体已经提供支持的一些复杂文本的变形。如果想要让汉字部分也调用天珩字库，但苦于这个方法会使得基本汉字使用系统自带字体，请在确保您想要使用的字库已经置于系统调用的字体列表中后直接将系统自带的汉字字体删除即可。删前建议留备份。
本页面最后修改于 公元2023年10月14日(星期六) 凌晨3:50 (UTC+8:00)