Repository navigation
Documentation：ctxdoc文档类影响xecjk文档中的mdcode中盒子内部+和-符号的基线 #1060
Description
这是对 #1054 的一点补充。注意到在 xeCJK-v3.10.5-rc5 中的文档文件xeCJK.pdf中（Page.5），还存在关于 \mdcode 高度不平齐的问题：
考虑如下的两个MWE：
\documentclass{article}
\usepackage[fontset=fandol]{ctex}
\ExplSyntaxOn
\XeTeXcharclass`- = \xeCJK_class_num:n { Default }
\ExplSyntaxOff
% https://github.com/CTeX-org/ctex-kit/blob/47639ff1eb2cc7b2c0a0c05c1cb2385c99936ebd/xeCJK/xeCJK.dtx#L244-L281
\usepackage{menukeys}
\begin{document}
你好+和-你好\texttt{+}和\texttt{-}你好
你好 + 和 - 你好 \texttt{+} 和 \texttt{-} 你好
你好+和--你好\texttt{+}和\texttt{-}你好
你好 + 和 -- 你好 \texttt{+} 和 \texttt{-} 你好
你好~\menu{+} 和~\menu{-} 你好~\menu{\texttt{+}} 和 \menu{\texttt{-}} 你好
\end{document}
这是对的齐的。
但是如果切换文档类为 ctxdoc，则由于字体改变，出现了符号的不对齐(汗...)
\documentclass{ctxdoc}%<----------
\ExplSyntaxOn
\XeTeXcharclass`- = \xeCJK_class_num:n { Default }
\ExplSyntaxOff
% https://github.com/CTeX-org/ctex-kit/blob/47639ff1eb2cc7b2c0a0c05c1cb2385c99936ebd/xeCJK/xeCJK.dtx#L244-L281
\usepackage{menukeys}
\begin{document}
你好+和-你好\texttt{+}和\texttt{-}你好
你好 + 和 - 你好 \texttt{+} 和 \texttt{-} 你好
你好+和--你好\texttt{+}和\texttt{-}你好
你好 + 和 -- 你好 \texttt{+} 和 \texttt{-} 你好
你好~\menu{+} 和~\menu{-} 你好~\menu{\texttt{+}} 和 \menu{\texttt{-}} 你好
\end{document}
根因在这里：
Lines 82 to 88 in 47639ff
Activity
[-]Documentation：`ctxdoc`文档类影响`xecjk`文档中的`mdcode`中盒子内部符号的基线[/-][+]Documentation：`ctxdoc`文档类影响`xecjk`文档中的`mdcode`中盒子内部`+`和`-`符号的基线[/+]github-actions commentedon Aug 7, 2026
🐛 Bug 分析 #1060
\mdcode以基线为轴缩放menukeys盒子；该盒子的深度占比大于汉字，缩放后外边框仍向基线下方伸出过多。ctxdoc选择的字体度量使这一偏差更明显。当前分析使用的提交
47639ff1eb2cc7b2c0a0c05c1cb2385c99936ebd已包含修复：缩放后根据汉字实际墨迹深度上移盒子，使外边框底边与周围汉字对齐。因此，Issue 中的现象不是仍待修复的当前缺陷。📋 详细分析
复现路径:
ctxdoc文档类加载menukeys。xeCJK文档中的\mdcode形式缩放\menu盒子。代码定位:
xeCJK/xeCJK.dtx:245-279问题原因:
\box_scale:Nnn围绕基线同时缩放盒子的高度和深度。menukeys生成的盒子在基线以下所占比例比汉字大，所以仅把总高度缩放到一个汉字宽度不能保证视觉基线对齐。当前实现测量汉字深度，并按字形墨迹与声明深度的实测比例1.131计算目标深度，再用\box_move_up:nn上移缩放后的盒子。提交记录显示该修复在\small、正常字号和\large下均进行了像素墨迹检查，同时通过了文档构建和 xeCJK 测试。由 codex / gpt-5.6-sol 生成；本流程只分析，不自动修改代码。
Explorer-cc commentedon Aug 7, 2026
分析完全脱离重点，现在的问题不是「盒子和汉字的相对高度问题」，而是「盒子内部的符号的基线不符合预期」。要注意区分。
Explorer-cc commentedon Aug 7, 2026
这本质是个 CMUTypewriter 字体符号的基线问题，本着有问题必问的原则，我在这里开了个帖子。
在 ctex-kit 端，我不知道为何
ctxdoc.cls要选用cm-unicode包提供的这个 Typewriter Font，如果切回lmtt能解决的话，切回去似乎也行...myhsia commentedon Aug 7, 2026
@Explorer-cc 原来是这样啊, 那我知道了, 你试试 l3doc
myhsia commentedon Aug 7, 2026
@myhsia 如果依旧, 那就是因为 l3doc 的默认字体, 有个 lm-default 选项