Qing Lee
Qing Lee
当初重构 ctex 2.x 的时候，我考虑过这个问题。我记得那时的 babel 代码写的比较死，给的接口很少，需要大改，并且那时中文社区也没有使用 babel 的习惯，就没做了。 粗看了一下，现在的 babel 好像比那时候灵活多了，可以重新考虑一下。
目前 `ctex` 中使用的是 `\ctex_set_upfonts:nnnnnn` 内部函数等来定义字体，还没有提供公共接口。由于原理类似，这个公共接口将 `zhmCJK` 包的代码稍微改改就能用。只是考虑到用 uptex 的普通用户会比较少，一直没有做。 另外在传统引擎下使用西文 otf 字体需要一系列较为繁琐的转换，不建议折腾。
设置颜色是通过 `\special` 命令插入代码交由驱动来完成的，会产生 `whatsit` node。xeCJK 是在宏层面处理的，我们可以对 `\textcolor` 进行特殊处理，但是很难兼顾到所有的情况。 你可以考虑用 `lualatex` 编译，这时 `ctex` 依赖 `luatexja` 作汉字支持，它使用的手段更加底层，可以很好的解决这一问题。
这是有意设计的，因为不知道用户会喂什么参数进来，冒然展开有一定风险，处理得比较保守。这行为也与 LaTeX 的 `\@text@composite` 类似，都是先将参数字符串化再来判断。
嗯，当初模型没选好，做法激进了些。 另外，xeCJK 在标点后面加的 `\vrule` 的宽度是通过 `\XeTeXglyphbounds` 直接从字体中取得的。但 `\XeTeXglyphbounds` 似乎对 language 标识的支持有问题，导致顶楼的例子中，繁体中文居中的标点度量信息不准确。 简单的例子： ```TeX \font\zhs = "[SourceHanSerifSC-Regular.otf]" at 10pt \relax \font\zhti = "[SourceHanSerifSC-Regular.otf];language=ZHT" at 10pt \relax \font\zhtii = "[SourceHanSerifTC-Regular.otf]" at 10pt...
目前居中标点是在 `FullLeft` 和 `FullRight` 类当作特例处理的，实现起来比较省力，其实并不合理也低效。
与 https://github.com/CTeX-org/ctex-kit/issues/249 类似，原理所限，目前没有简便的处理方法，除非整个重构 xeCJKfntef，不依赖 ulem 包的机制，完全通过 `\XeTeXinterchartoks` 来处理。
xeCJK 的补丁使用了 `\scantokens` 来改变命令参数中的 `\lstinline` 的参数字符的 `\catcode`，然而参数记号 `#` 在传递过程中会双写，导致这个问题。listings 包在这里是使用传统的 `\lowercase` 技巧，可以避免这个问题。 目前，一个回避问题的方法是像对`{}`和空格这些特殊记号一样，用 `\` 转义： ```TeX \passthrough{\lstinline!\#!} ```
当时用的是 adobe 的字体，宋体的间隔号比较细，为了突出显示就用了黑体。
当时依赖 LuaTeX-ja 做中文支持的时候，LuaTeX-ja 的功能还没现在这么全面。你上面提到的这些功能包括比较重要的直排都是后来陆续开发出来的，我们没有进一步跟进，这确实是需要改进的地方。