英文居然有“合字”这种冷知识，用 typora 输出 pdf 时碰到坑了

[tankb52]

给新人写说明文档，当中有 wifi 一词，输出 pdf 后，新人直接复制文档中的内容，执行的时候出问题了。
我查看日志发现是 wifi 处出现了乱码，好生奇怪。
去网上一搜，才知道英文中有“合字”这一概念， 见 WIKI: 合字 ，常见的 æ 和 & 就是合字。 我碰到的坑，就是wifi 中的 fi，输出文档时，被当成了合字，虽然显示是正常的，但复制后搜索，两个字母合在一起，变成了另外一个字符 fi
我不确认这是 Typora 的 bug 还是 Win10 的 bug，看了维基也不是很理解合字的用途。但 wifi是一个很常见的单字，不知道大家在写文档的时候，有碰到过类似的问题吗？又是如何解决的呢？

[est]

不冷。还有更好玩的用法。Ligature 用来打码！

[halou12]

https://i.loli.net/2019/04/26/5cc2d7b628e77.png 编辑模式也会合在一起

[yzwduck]

“合字”的准确叫法是 ligature，已经存在几百年了，也是字体的基础特性之一。如果 PDF 里 ligature 的复制粘贴出问题的话，锅需要甩给生成 PDF 的软件，而不是 PDF 阅读器 @arfaWong
要么换个生成 PDF 的软件，要么试试换个字体。
题外话: 命令一般是要用等宽字体的吧。

[tankb52]

@yzwduck #23
也不是专门写的代码，有高亮就不错了。
只是把一行命令写在文档里，读者再把命令拷到工具里直接执行。
我是用 typora 直接导出 pdf 的，一般不直接导出那用什么生成 pdf 呢？

[kmahyyg]

@tankb52 #24 你没有用 markdown 的 code block 吧. 正确操作不是 monospace 么

[jadec0der]

实际上，类似的需求在使用拉丁字符的语言中同样存在。最典型的是西文排版中所谓 「合字」（ ligature ）的概念，即针对 ff、fi 这样笔画容易「打架」的字符组合，将其当作一个整体来专门设计造型。因此，这些字符组合在 Unicode 中需要有独立的码位，如 ff (U+FB00)、fi (U+FB01) 等（请试着动手复制一下这些字符）。可是，合字在显示时是一个整体，而在复制和搜索时却要看作两个独立的字符。而在 PDF 中，合字的这种双重身份也正是通过 CMap 的「一对多」映射实现的。

因此，复制文字重复的故障，其责任并不在于 PDF 的编码。「一对多」的映射并不是一种冗余或者混淆，而是为了适应机器和用户的不同需要而必须加入的特殊处理。说到底，还是预览 App 的优化功夫没下到家，没有意识到 PDF 文本在显示、复制、搜索时应该受到不同的对待。这也再次应证了我之前文章中的一个观点：PDF 阅读器很多时候拼的不是功能有多丰富（反正都拼不过亲儿子 Acrobat ），而是能不能做好复制、搜索这些基础功能的细节。

-《 PDF 复制中的文字重复问题》
https://sspai.com/post/52073

[tankb52]

@kmahyyg #25
啊，对了，有一段是因为要对比几行近似的命令，我写在了表格里面。

[xiangyuecn]

歪个楼 emoji 0x200d 控制字符，人物疯狂叠加

[xiangyuecn]

忘记一个好玩的了：泰文

[tankb52]

@kmahyyg #25
刚刚试了一下，还真是。
在代码块里面的复制就没有问题。
在表格里面的复制就出现合字了。

[tankb52]

@cway #5
找到原因了。你有兴趣可以再试一下，把 wifi 放在代码里面和放在表格里面。

在代码块里面的复制就没有问题。
在表格里面的复制就出现合字了。

[whileFalse]

PDF 是一种打印格式，其设计目的是可以完全确保显示不乱。
不建议将需要复制的文本放在 PDF 里面。我所使用过的阅读器在复制文本时都会有这样那样的错误。也许 Adobe 的亲儿子做的很好，我反正是用不起。

还是建议用 markdown （不要导出！）。

[tankb52]

@whileFalse #32
我没法控制别人不偷懒复制——其实我有时也会偷这个懒。
我只能优先保证排版不乱。
直接输出 MD 文件，还得考虑对方手上有没有 markdown。

[iowt]

https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Long_S-I_Garamond_sort_001.png/440px-Long_S-I_Garamond_sort_001.png

把 fi 和 ffi 等替换成单字是铅字时代就有的做法，例如上面的图片就是 Garamond 字体中的 fi 铅字。Unicode 在制定码位的时候，考虑到历史原因，把很多常用的铅字和电报控制字符都加入了，于是 fi 等连字（ ligature ）也有了自己的编码码位。

但在那时，带有高级排版功能的 OpenType 还没有出现，所以那时的排版软件都会手动把 fi 这类字符替换成对应的合字，以达到排版需求，但坏处是复制时也会复制成合字，而不是原本的字符序列。

直到后来 OpenType 增加了 GSUB、GPOS 和 GDEF 这三个表掌管各种合字的替换，这时候才能做到使得在原文字不变的情况下，在软件的渲染中仍然显示合字。Iosevka 和 Fira Code 这样能在代码编辑器中加入丰富的图形符号的字体（见下图）就是利用了这一点。

https://github.com/tonsky/FiraCode/raw/master/showcases/swift.png

https://raw.githubusercontent.com/be5invis/Iosevka/master/images/ligations.png

[iowt]

另外，有些 PDF 阅读器应该做到拆分复制合字以及删除跨行单词被插入的连字符。

[nu11001]

用反引号``不会被合

[mcfog]

font ligature 和 unicode grapheme 是两个不一样的机制吧，前者是发生在渲染过程的，二进制数据和分开写并没有区别，后者是二进制数据也发生了变化的，分开写和组合在一起的 unicode 表示都是不一样的

[ho121]

兛

[laqow]

所以为什么作为 markdown 这种求快求方便的应用要将文字排版的功能搞这么复杂呢

[cyspy]

应该说是开源软件对 pdf 的处理各有不同