zhspacing.sty 是否可以不要写死字体，在 Linux 下没有SimSun

[XiangyunHuang]

ctex-kit/zhspacing/zhspacing.sty

Line 574 in 85a3ed9

\ifLaTeX@e

是否可以不要写死字体，在 Linux 下没有SumSun，我想使用 Fandol 系列字体，导言区

\documentclass{ctexbook}
\usepackage{zhspacing}
\zhspacing

报错信息如下

kpathsea: Running mktextfm SimSun
/home/cloud2016/.TinyTeX/texmf-dist/web2c/mktexnam: Could not map source abbreviation  for SimSun.
/home/cloud2016/.TinyTeX/texmf-dist/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input SimSun
This is METAFONT, Version 2.7182818 (TeX Live 2017) (preloaded base=mf)

kpathsea: Running mktexmf SimSun

! I can't find file `SimSun'.
<*> ...:=ljfour; mag:=1; nonstopmode; input SimSun
                                                  
Please type another input file name
! Emergency stop.
<*> ...:=ljfour; mag:=1; nonstopmode; input SimSun
                                                  
Transcript written on mfput.log.
grep: SimSun.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input SimSun' failed to make SimSun.tfm.
kpathsea: Appending font creation commands to missfont.log.
! fontspec error: "font-not-found"
! 
! The font "SimSun" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!...............................................  

[Liam0205]

zhspacing 本质上是 XeLaTeX 刚出来那会儿 Yin Dian 制作的实验性质的宏包。目前来看，其功能是 xeCJK 的真子集。所以，建议用 xeCJK 而不是 zhspacing。

基于类似的原因，现在大家都没有维护 zhspacing 的动力。当然，欢迎提 PR。

[stone-zeng]

这个跟 zhspacing 没什么关系，而且用了 CTeX 这个包大概也可以不用了。

想用 Fandol 的话，你可以给 ctexbook 文档类加选项 fontset=fandol。

另外，中易宋体是 SimSun。

[XiangyunHuang]

抱歉，SimSun 一不留神打成了 SumSun，我知道 zhspacing 包是用来解决中英文之间的空格，包括代码块中中英文之间的空格。我的问题是如下代码块

'鸢尾花数据的散点图'

经过编译，pdf 文档显示的效果却是

所以我用 zhspacing 包来处理，但是就会报上面提的错误，pdf 文档也出不来，我试了 xeCJK 还是不能解决。

系统 CentOS

cat /etc/redhat-release

CentOS Linux release 7.4.1708 (Core)

tex 环境

tex -v

TeX 3.14159265 (TeX Live 2017)
kpathsea version 6.2.3
Copyright 2017 D.E. Knuth.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the TeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the TeX source.
Primary author of TeX: D.E. Knuth.

[Liam0205]

'鸢尾花数据的散点图'

你的测试代码使用了英文引号。这种情况不在 zhspacing 或是 xeCJK 的处理范围之内。事实上，这是错误的用法。

中文的引号，应当使用直角引号（「『』」）或者弯引号（“ ‘ ’ ”）。正确的做法应该是：

\documentclass[UTF8]{ctexart}
\begin{document}
杀人犯「陈世峰」的名字常被误作「陈世『锋』」。

杀人犯“陈世峰”的名字常被误作“陈世‘锋’”。
\end{document}

[XiangyunHuang]

1. 那是因为正确的代码就是应该带英文引号的，如下

Python 2.7.5 (default, Aug  4 2017, 00:39:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('鸢尾花数据的散点图')
鸢尾花数据的散点图
>>> print("鸢尾花数据的散点图")
鸢尾花数据的散点图
>>> print(“鸢尾花数据的散点图”)
  File "<stdin>", line 1
    print(“鸢尾花数据的散点图”)
          ^
SyntaxError: invalid syntax
>>>

Windows 上 zhspacing 的表现是正常的，如上图，但是会用 SimSum 替换掉我之前设置的字体。

2. 在 Linux 上测试，我用的 XeLaTeX 引擎，会自动调用 fandol 字体。

3. 源码是这样的：

R 代码块及其执行结果

# Embedding code
print('鸢尾花数据的散点图')

显示 Python 代码块

print('鸢尾花数据的散点图')

[leo-liu]

首先，不要用 zhspacing。你如果只用 \documentclass{ctexbook} 这一句，会发现中文一切正常，不需要你自做聪明。

其次，讲真，如果你看了 zhspacing 的文档的话，就知道它是可以自己设置字体的，也就是直接在文档中重定义 \zhfont。而且你还举了源代码，更不应该有这种疑问。

第三，我再说一遍，不要用 zhspacing。它仅仅是出于历史原因而存在，请忘掉它。

第四，部分 Linux 用户乐于在仔细查看官方文档之前轻信网上过时的资料，并在读源代码的时候一知半解，对此我深表遗憾。在这个基础上写出来的冗余代码，我称之为穷折腾。为了照顾这种情形，我只好把 ctex 文档中的例子再抄一遍：

\documentclass[UTF8]{ctexart}
\begin{document}
中文文档类测试。你需要将所有源文件保存为UTF-8 编码。
你可以使用XeLaTeX、LuaLaTeX 或upLaTeX 编译，也可以使用(pdf)LaTeX 编译。
推荐使用XeLaTeX 或LuaLaTeX 编译。
\end{document}

如果你不愿意读代码里面的汉字我可以再解释一遍：不只是你在 Windows 下用这段代码，在 macOS 下也是用这段代码，在 Ubuntu、Debian、CentOS、SUSE、Fedora 或者别的什么 Linux 发行版下面，还是用这段代码。在急着探究什么 Linux 丰富配置之前，先把基本用法搞明白。

[Liam0205]

所以你的问题不是在正文当中使用标点，而是在代码抄写环境使用英文引号。那这件事情和 zhspacing 就更没关系了，和 xeCJK 也关系不大。

你在代码抄写环境发现引号显示于 Windows 和 Linux 不同，原因和 zhspacing, xeCJK, CTeX 统统都没关系。因为在代码抄写环境，使用的是 ttfamily。上述不同的根本原因是你在 Windows 上和 Linux 上使用的西文 ttfamily 的字体中单引号的 glyph 不同。简单说来就是西文字体不同导致的。或者说，你这个代码在 Linux 上使用当前的西文字体跑出这样的结果就是「正常的」。

如果你觉得有问题，比如「为什么两个引号都是『往左边拐』？」，或者「为什么引号的间距不对了？」，那我也只能告诉你：「在你当前的字体里，它就是这个样子，这是『正常的』。」

所以，如果你要解决你遇到的问题，你应该做的是：「更换一个在 ttfamily 下西文单引号形状符合你要求的西文字体」，而不是其他什么（穷折腾）。

总之不管怎么说，不要用 zhspacing，你遇到的问题也和本项目没有半分钱关系。

[XiangyunHuang]

@leo-liu 可能我对问题的表述有问题

1. 我一直强调自己处在代码块里，并且中英文混合情形下，英文单引号和后面的中文多出来一个空格，像下图那样
   
2. 至于找到 zhspacing 并不是瞎折腾，而是多翻尝试之后， zhspacing 在 Windows 下表现了我以为看起来的正常
3. 如果如 @Liam0205 所说是字体本身的问题的话，我无话可说，是我功力不足，了解不够。
4. 至于ctex 文档读了没有100遍也有50遍， 不然本校的论文模板也不能从无到有的排出来
5. 来项目发问是因为项目主页还存在 zhspacing
6. 由于源文档的复杂性（涉及R语言、Markdown、Pandoc、甚至Knitr和bookdown等R包）也可能是别的环节。

谢谢二位大神的回复

[yihui]

我来把这个问题简化一下。最简示例：

\documentclass[UTF8]{ctexart}

\begin{document}

"鸢尾花"

\begin{verbatim}
"鸢尾花"
\end{verbatim}

\end{document}

xelatex 编译结果：

我知道为什么两个引号左拐。楼主的问题是为什么第一个引号后面空格，以及如何才能去掉这个空格。

如果要追究为什么是 ""而不是 `` '' 或者“正确的”中文引号，答案是这个本来是用在代码高亮里，它是上游软件（Pandoc）自动生成的，不受我们控制，真实的 LaTeX 代码看起来是这样的：

\documentclass[UTF8]{ctexart}
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
\usepackage{framed}
\definecolor{shadecolor}{RGB}{248,248,248}
\newenvironment{Shaded}{\begin{snugshade}}{\end{snugshade}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.31,0.60,0.02}{#1}}

\begin{document}

\begin{Shaded}
\begin{Highlighting}[]
\StringTok{"鸢尾花"}
\end{Highlighting}
\end{Shaded}

\end{document}

谢谢！

[stone-zeng]

这个其实是 xeCJK 对抄录环境的补丁造成的。

xeCJK 默认只对 verbatim 环境进行了调整（Verb=env），但却并没有修改 fancyvrb 宏包提供的 Verbatim 环境（注意大小写）。你这里的 Highlighting 环境是用 Verbatim 封装的，自然也不会受影响。

解决的办法有：

1. 把 Highlighting 放到一个分组里面，前面加 \xeCJKVerbAddon：

\begingroup
\xeCJKVerbAddon
\begin{Shaded}
\begin{Highlighting}[]
With \textbackslash{}xeCJKVerbAddon:
"鸢尾花"
'鸢尾花'
\StringTok{"鸢尾花"}
\StringTok{'鸢尾花'}
\end{Highlighting}
\end{Shaded}
\endgroup

2. 定义 Highlighting 时就加上\xeCJKVerbAddon：

\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\},formatcom=\xeCJKVerbAddon}

效果如下（这里按照第一种方法处理）：

完整代码：

\documentclass[UTF8]{ctexart}
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
\usepackage{framed}
\definecolor{shadecolor}{RGB}{248,248,248}
\newenvironment{Shaded}{\begin{snugshade}}{\end{snugshade}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.31,0.60,0.02}{#1}}

\begin{document}

\begin{verbatim}
verbatim 环境:
'鸢尾花'
\end{verbatim}

\begin{Verbatim}
Verbatim 环境:
'鸢尾花'
\end{Verbatim}

\begin{Shaded}
\begin{Highlighting}[]
Without \textbackslash{}xeCJKVerbAddon:
"鸢尾花"
'鸢尾花'
\StringTok{"鸢尾花"}
\StringTok{'鸢尾花'}
\end{Highlighting}
\end{Shaded}

\begingroup
\xeCJKVerbAddon
\begin{Shaded}
\begin{Highlighting}[]
With \textbackslash{}xeCJKVerbAddon:
"鸢尾花"
'鸢尾花'
\StringTok{"鸢尾花"}
\StringTok{'鸢尾花'}
\end{Highlighting}
\end{Shaded}
\endgroup

\end{document}

当然，的确是和 zhspacing 没有一点关系的。

[yihui]

@stone-zeng 嗯，这正是我要的答案。多谢这位壮士！要是有微信收款二维码的话，可以留一个，请你喝酒。

最终我用了 fancyvrb 的 \RecustomVerbatimEnvironment 命令改写了 Highlighting 环境。

[leo-liu]

我针对的就是这个 issue 标题中说的“zhspacing.sty 是否可以不要写死字体”的问题来的。事实上 zhspacing 写不写死字体都无关紧要，改 zhspacing 字体的办法就是重定义 \zhfont。所以这个 issue 不成立。 至于你原来的问题是什么，我在前面几个回复中没看到，即使后面提到语法高亮，也没有贴代码，我当然就没有关注。 其实你直接说你原始的问题，从一开始就说明是 pandoc 生成的代码标点显示有问题，那就好解决多了。我们一眼就能看出问题。这样绕来绕去就很麻烦了…… 在 2017年12月22日 下午10:20，黄湘云 <notifications@github.com>写道：

…

@leo-liu <https://github.com/leo-liu> 可能我对问题的表述有问题 1. 我一直强调自己处在代码块里，并且中英文混合情形下，英文单引号和后面的中文多出来一个空格，像下图那样 [image: img] <https://user-images.githubusercontent.com/12031874/33982693-55d02a9e-e0ec-11e7-83f7-7dbe08f5eebd.png> 2. 至于找到 zhspacing 并不是瞎折腾，而是多翻尝试之后， zhspacing 在 Windows 下表现了我以为看起来的正常 3. 如果如 @Liam0205 <https://github.com/liam0205> 所说是字体本身的问题的话，我无话可说，是我功力不足，了解不够。 4. 至于ctex 文档读了没有100遍也有50遍， 不然本校的论文模板也不能从无到有的排出来 5. 来项目发问是因为项目主页还存在 zhspacing 6. 由于源文档的复杂性（涉及R语言、Markdown、Pandoc、甚至Knitr和bookdown等R包）也可能是别的环节。 谢谢二位大神的回复 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#331 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAi087ukrDCkf8vqrV17B8ZkIpL7H2DSks5tC7qWgaJpZM4RKyzB> .

[yihui]

嗯，你说的这些对我这个码农来说自然是深有体会，我一个人这些年处理的 Github 事项数量应该在两千以上（不包括其它渠道上的报告），所以我非常清楚应该怎样向开发者报告问题，这也是我最后插一脚进来简化问题的原因。原楼主不是码农，像大多数报告者一样，遇事要么说不清楚，要么强行穷折腾到歧途上，放着烟幕弹牵着开发者走一圈，最终彼此都被弄糊涂了。一般用户都没有简化问题的能力，我认为这会是开发者永远摆脱不了的魔咒，反正我自己已经认命了……

[pzhaonet]

请问各位大侠，类似的情况在 \texttt{"鸢尾花"} 这种环境下的第一个引号与中文之间的空格该如何消除？

示例：

\documentclass[UTF8]{ctexart}
\begin{document}
\texttt{"鸢尾花"}
\end{document}

[stone-zeng]

用 \verb|"鸢尾花"|。

\texttt 仍然会自动调整标点与汉字之间的间距，这很可能不是你需要的。

[pzhaonet]

很管用，谢谢！

我用 \texttt 的原因跟上面 @yihui 讲的情况相同，是上游的 pandoc 自动生成的。不过这属于另外一个问题了。

[chuxinyuan]

@Liam0205 如果正如 @stone-zeng 所说：

这个其实是 xeCJK 对抄录环境的补丁造成的。

那么，我请求这个问题重新打开，以期彻底把这个问题解决。

[Sophanatprime]

这个其实是 xeCJK 对抄录环境的补丁造成的。

“这个...补丁”应该指的是 xeCJK 自动对 verbatim 中的中西文进行特殊的处理。而默认没有对 Verbatim 的中西文进行同样的处理，但可以自行添加 formatcom=\xeCJKVerbAddon。

zhspacing 本质上是 XeLaTeX 刚出来那会儿 Yin Dian 制作的实验性质的宏包。目前来看，其功能是 xeCJK 的真子集。所以，建议用 xeCJK 而不是 zhspacing。

我针对的就是这个 issue 标题中说的“zhspacing.sty 是否可以不要写死字体”的问题来的。事实上 zhspacing
写不写死字体都无关紧要，改 zhspacing 字体的办法就是重定义 \zhfont。所以这个 issue 不成立。

所以这个问题还有哪里没解决的？

[chuxinyuan]

“这个...补丁”指的是 xeCJK 自动对 verbatim 中的中西文进行特殊的处理。而默认没有对 Verbatim 的中西文进行同样的处理，但可以自行添加 formatcom=\xeCJKVerbAddon。

能否考虑默认对 Verbatim 的中西文进行同样的处理，这样就不需要下游不停的打补丁了。

[Liam0205]

这真是个陈年老 Issue。

我们首先来归集一下已有的知识。

1. zhspacing 是一个不应当被继续使用的宏包。它的替代品是 xeCJK/ctex。
2. 因为 1)，新增的文档应当不存在当前 Issue 中讨论的问题。
3. 对于陈旧文档，假设我们更新了 zhspacing/xeCJK 来「解决」这个问题（虽然我不认为这应当放在 xeCJK 里解决），势必要求陈旧文档在新的 TeX Live 环境里编译。而对于能使用 zhspacing 这类宏包的陈旧文档，我（纯凭感觉）可以说在新 TeX Live 里编译这类文档，会遇到更多新的问题。即是说，即便我们有更新，陈旧文档也不会「自动变好」。

因此，在我看来应当由第三方工具更新生成 LaTeX 代码的模板，以期同时解决陈旧文档和新增文档的问题。于是也无必要 reopen 了。

[yihui]

我也来归纳一下。原帖提出来的问题可能确实是不成立的，后面的问题应该已经漂走、与 zhspacing 无关了。我想问题的关键在于为啥上面我的最简示例里的第一个引号后面会多出来个空格：#331 (comment) 这个问题的一个特例（Verbatim 环境下的引号问题）已经得到了解决方案，也就是自定义 Verbatim 环境：

\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\},formatcom=\xeCJKVerbAddon}

现在的问题是：

1. 有没有什么选项能让 xeCJK 干脆就不要在引号后面加空格（无论什么环境下）。
2. 如果问题 1 的答案是没有，那么对于问题的特例（Verbatim）环境，是否可以自动应用 \xeCJKVerbAddon。

如果问题 2 的答案也是“否”，那么这个 Github 事项就不用再继续了：用户们前赴后继来抄上面那行代码就完事了。我不清楚这问题的技术背景以及是否有解决的可能性甚至必要性，不管开发者如何决策我个人都可以接受，只是单纯从用户角度来说，这真的是个千年老坑。

[muzimuzhi]

关于 patch fancyvrb 包的讨论可以发到这里：

• xeCJK: Verbatim里不应该自动加空格 #580