昨天在把一个合同从 Word 版本导出为 PDF 的时候，发现导出的 PDF 版总是会在页脚处多出一串代码（形如 XY&Z\12345.67），但在 Word 中并不能看到任何对应的文字。
虽然暂时不知道这串代码的意思，但看外观像是某种格式的文件编号。于是首先尝试搜索其中的字母部分 XY&Z，发现是某个律所的简称（全称类似 Xenos, Yanko & Zais, LLP）。
看来，这串字符确实是文件编号。剩下的问题就是它是如何出现的，以及怎么去掉。
考虑到文件编号只在导出成 PDF 时才出现，而导出 PDF 的操作基本相当于打印，便联想到 Word 中域功能的特性——打印时自动更新页眉和页脚中的域。于是再次进入脚注编辑界面并按 Option-F9 显示域代码，果然看到这串隐形文件编号的对应位置有一个域，代码为 { DOCPROPERTY"SWDocID" }。
查阅 …
在使用 Word 编辑文档的过程中，我们经常会遇到需要在一段话内列举带编号项目的情况，例如：
鼓励网络信息内容服务平台坚持主流价值导向，优化信息推荐机制，加强版面页面生态管理，在下列重点环节（包括服务类型、位置版块等）积极呈现本规定第五条规定的信息：（一）互联网新闻信息服务首页首屏、弹窗和重要新闻信息内容页面等；（二）互联网用户公众账号信息服务精选、热搜等；（三）博客、微博客信息服务热门推荐、榜单类、弹窗及基于地理位置的信息服务版块等；[…]
在这些场合，编号的输入和修改是比较繁琐的。如果编号项目的总数只有两三个，工作量还能忍受；但如果数量达到两位数，逐个手敲就很低效了。特别是对于中文文档，在段落中输入 (1)、(a)、(i) 这样的字母、数字编号，还意味着需要在中英文状态下来回切换。如果后续修改中不幸要删除列表中的某一项，也就意味着要手动修改它之后的每一个编号，更加耽误时间。
在多段落列表中，这些麻烦是不存在的——只要用现成的自动编号功能就行了。然而，自动编号并不能在同一个段落中使用。
不过，这并不意味着在段落内部就无法实现自动编号。解决方法就是使用 Word 的域（field）功能。
关于「域」在 Word 中的含义和使用方法，我在之前的文章中已经有所介绍，这里不再重复。简言之，所谓的「域」就是一个占位符，它的作用是告诉 Word「显示的时候把我换成别的东西」。
这里，我们要使用的是 SEQ 域。如名称（SEQuence）所表明，它的作用就是产生一个数字「序列」。但与自动编号不同的是，SEQ 域可以在同一段落中多次出现，且位置不限于段落开头。因此，通过在段落中插入多个 SEQ 域，就可以实现段内自动编号的效果。
我们首先通过一个简单场景——插入形如「（一）、（二）、（三）」的段内序号——来熟悉 SEQ…
Safari 阅读列表是 macOS 和 iOS 上一个比较容易被忽视的功能。该功能最初出现在 2011 年的 OS X Lion 和 iOS 5 系统中，但除了在次年加入了离线缓存，它基本就在这八年间一成不变，与 Pocket、Instapaper 等专职的稍后读服务相比显得十分简陋。
我自己之前也很少使用阅读列表功能，而是用 Pinboard 结合 Instapaper 解决稍后读的需求。这套组合虽然总体让我满意，但也不是尽善尽美，最明显的不足就在于添加链接时的繁琐。特别是在那些没有分享按钮的界面，每添加一个链接都要经历长按链接—选择「分享」—点击应用图标三个步骤。在需要连续保存很多链接时（例如阅读 newsletter 或播客的 show notes），重复这套繁琐的步骤接近一种折磨。另外，Instapaper 的同步也受到 iOS 对后台进程的限制，在信号不好时添加的链接，往往需要事后手动刷新一次才能反映在其他设备上。
相比之下，作为系统自带功能，Safari 阅读列表具有第三方应用难以企及的特权。「添加到阅读列表」的选项几乎无处不在，并且总是处于第一级菜单的显著位置，新增链接在任何时候不会需要超过两次点击。不仅如此，阅读列表作为一个系统服务，可以始终保持后台运行，并且通过 iCloud 近乎即时地在各设备间同步。
发现了这些优点后，我在近几个月试着更多地利用 Safari 阅读列表。为了扬长避短，我主要在两种场景下使用这一功能：其一，将阅读列表作为暂存空间，用来处理一些不需要长久保存的页面；其二，将阅读列表作为第三方工具的「前端」，利用它保存链接时的便捷，然后通过脚本将其内容自动同步到其他稍后读服务。…
前段时间偶尔逛到键盘保护套 Canopy 的官网，发现它的厂商是一家挺有意思的设计工作室。除了苹果设备配件，这家名叫 Studio Neat 的工作室还设计了一些文具，包括一款叫做 Panobook 的笔记本。
从介绍看，Panobook 最主要的卖点在于其特殊的尺寸。不同于一般以纵向为默认方向的笔记本，Panobook 是一个狭长的横向矩形（288 mm x 160 mm 或 11.34 in x 6.30 in），它的名字大概也是因此而来。之所以要设计成横过来，应该主要是考虑到在电脑桌上使用的场景：摆着键盘的桌面很难再有空间容纳下一个竖向的本子，水平摆放是让两者和平共处的合理选择。
Panobook 在纸张设计上也有一些巧思。除了在背景里印上了非常实用的点阵，Panobook 还在水平方向等分出了三个矩形，并在这些矩形的顶点位置用细微的直角标记加以提示。根据 Studio Neat 的说法，这是为了方便徒手画出线框图、故事板等设计从业者常用的布局。
尽管 Panobook 的定价非常情怀（20 美元一本；我猜主要是产量小，价格谈不下来），而且我也很少用实体纸笔，这个产品倒是给了我改进 iPad 记笔记的方式一些启发。之前在用 GoodNotes …
我们每天都要浏览大量的网页，但不是每个网页的设计都能做到为读者着想。实际上，相当比例的网页设计十分糟糕，读起来非常费劲。对此，Safari 的阅读模式是一个不错的解决方案，但并不是在所有网页上都能成功启用、或是取得理想的效果。使用 Stylish、Tampermonkey 等浏览器插件也是一种途径，但不适用于 iOS，而桌面版 Safari 也对第三方插件越发不友好了。
上述问题可以通过使用小书签（bookmarklet）来解决。小书签的本质是一段 JavaScript 脚本，典型用途之一就是修改当前浏览器页面的外观，包括但不限于字体、字号、颜色等。相比于完整的浏览器插件，小书签尽管功能比较简陋，但优势在于通用性极强，可以用在包括 iOS 版 Safari 在内的任何浏览器上。
要将小书签添加到 Safari 中，最简单的方法是在桌面端操作，将下文给出的链接拖拽到书签栏即可；它们会随着 iCloud 同步到 iOS 端。如果要在 iOS 上操作，则可以先长按复制这些小书签的链接，然后任意将一个网页（例如本页）保存到收藏夹，再通过编辑功能将其链接改为前面复制的内容。
注：小书签是一个历史相当久远的功能，网上的资料也很丰富（少数派几年前有过一篇很详尽的文章），故本文不多赘述其原理和制作方法。
字体是网页设计中的重要环节。选用一个美观的字体组合，不仅能让用户阅读信息更加顺畅，也有利于增强网站的视觉辨识度。遗憾的是，很多网页设计者都忽略或者滥用了字体设计。有的不加考虑，放任系统调用 Arial、Times New Roman 等让人直翻白眼的回退字体；有的则矫枉过正，选择了一些乍看很有风格、实则根本不适合阅读的「个性」字体。遇到这类网页时，运行下面这个小书签，可以将页面字体统一为系统默认字体（San Francisco），获得更好的可读性。…
文件操作是 iOS 长久以来让人感到「别扭」的功能弱项。究其原因，很大程度上是 iOS 的文件操作逻辑与桌面系统截然不同：同样是打开一个文档，在桌面端，第一步通常是在文件管理器中找到文档本身，然后再考虑用什么程序打开它；而到了 iOS 上，操作顺序则完全相反——先是打开应用，然后才是找到需要的文档。
这种操作逻辑是 iOS「沙盒」机制的产物。在早期版本的 iOS 中，应用的读写权限被严格限制在其特定的文档目录内，因此打开应用就成了任何文件操作的必经步骤。较新版本的 iOS 略微放松了限制，允许应用读写 iCloud Drive、并通过 Document Provider 扩展相互访问文档，但仍然没有从根本上改变 iOS 的文件操作逻辑。观察 iOS 的「文件」应用的呈现方式，会发现每个应用仍然被赋予了一个独立的文件夹，并且和用户创建的其他文件夹是平级的。这体现的还是一种以应用为中心的思路。
问题在于，我们的工作很多时候不是以应用为起点，而是以项目为起点的。试想你正在撰写一篇文章或者复习一门课程——执行一个「项目」。在电脑上，我们会很自然地为这个项目建立一个文件夹，把相关文件都放入其中。工作时打开这个文件夹，就能很方便地随手调取各个文件。然而，这种顺理成章的操作在 iOS 上并没有对应的实现方式。即使相关文件都存放在同一个文件夹内，你仍然需要分头在各个应用中打开它们。且不论低下的效率，这也是对思路和注意力不必要的干扰。
能不能在 iOS 现有的框架内提高访问文件的效率呢？不妨考虑把主屏幕的空间利用起来。尽管 iOS 设备越做越大，它们的主屏幕却仍然只是个应用启动器，未免显得过于浪费。如果能把经常访问的文件放在主屏幕上，点击即可打开，就能省下很多打开应用—寻找文件的繁琐步骤；不仅如此，还可以像整理图标一样，将同属一个项目的文件放进一个文件夹里，从而在很大程度上模拟我们在电脑上的操作习惯。
在上图所示的效果中，我们将一个 iCloud Drive 中的 Numbers …
一般情况下，应用程序的界面语言会和系统语言保持一致。但有些时候，我们也会希望临时换用一种不同的界面语言。例如，一些程序的中文翻译词不达意，有必要参考英文界面来确定功能的准确含义；又如，一些网页会强制按照浏览器语言显示不同版本，因此必须通过切换浏览器语言来控制网页语言。
问题是，并不是所有的应用程序都提供了切换界面语言的选项。事实上，大多数 macOS 的内建应用都没有这样的设置。如果每次遇到这种需求都去临时改变系统语言，未免过于耗时和麻烦。
这个问题可以通过终端命令来解决。macOS 允许在运行应用程序时向其传递特定参数，其中，-AppleLanguages 参数就是用来控制应用程序的语言的。例如：
# 以简体中文界面启动 Safari 浏览器
$ open -a /Applications/Safari.app --args -AppleLanguages '(zh-CN)'
# 以英文界面启动 Pages
$ open -a /Applications/Pages.app --args -AppleLanguages '(en)'
如果想以其他语言启动某个应用程序，只需要修改上述命令最后的地区代码。其他一些常用的代码包括繁体中文（zh-TW）、日文（ja）、法文（fr）、德文（de）等。
要知道一个应用都支持哪些界面语言，可以在 …
排版问题一直是 Kindle 的顽疾，而其在字体选用方面的不作为又特为尤甚。因此，更换字体一直是 Kindle 用户折腾的主要动力之一。早先，这一需求经常通过越狱并替换系统字体来实现。但随着 Kindle 越狱难度的加大，加上替换文件容易导致的诸多故障，尝试这种方法的成本已经越来越高了。
另外一种更为方便和安全的方式，则是利用 Calibre 这一强大的管理、编辑工具对电子书进行处理，在其中嵌入自定义字体。但直接应用这种方法得到的排版效果其实也并不完善，因为 Calibre 一次只能嵌入一个字体文件，在显示粗体和西文部分时，就会出现字体缺失或效果不佳的问题（很多中文字体附带的西文质量是十分平庸的）。
实际上，对于常见的中西文混排电子书，实现较为完善的排版效果至少需要两款字体、共计六个字体文件（中文常规体和粗体，西文常规体和粗体、及各自对应的斜体）。这在 Calibre 的图形界面上并不容易实现。但利用 Calibre 完善的命令行支持，则不仅能最大限度地实现字体嵌入的自定义，还能与其他效率工具结合，达到自动化、可复用的效果。
下图是原电子书的显示效果、使用 Calibre 直接嵌入字体的效果、以及嵌入多种字体效果的对比。请特别注意西文和粗体、斜体的显示效果。
本文的目的，即在于说明如何利用 Calibre 的命令行支持，通过在电子书中嵌入自定义的 CSS 和字体文件，以实现更完善的排版效果。
要使用本文方法修改电子书文件，需要提前准备的条件有：
.ttf 或 .otf「拖动」是 macOS 图形界面操作的精华。但是，在很多情况下，拖动并不像我们希望的那样随心所欲。例如，在当前 app 处于全屏模式的情况下，如何将其他桌面上的文件拖动到该 app 中？在桌面堆满了窗口的时候，如何在桌面和众多 app 间互相拖动文件？在屏幕空间局促的 MacBook 上，这种问题显得尤为突出。
针对这种需求，市场上出现了大量充当拖动操作「中转站」作用的 app，如 Unclutter、Yoink、Dropzone 等。这些 app 的共同点在于，当检测到用户拖动文件时，会在屏幕边缘弹出一个容器；用户可以将文件先拖动到该容器中暂存起来，然后切换到目标 app 中，再将文件从这个「中转站」里拖到对应位置。
这种方法固然能达到目的，却未免有些隔靴搔痒；何况，购买这些 app 也是一笔额外的成本。其实，macOS 已经提供了解决问题的全部工具，只要进行很少量的配置，就能一步到位地实现高效拖动文件的需求。
如果打开的桌面全屏 app 数量不多，或目标位置与当前桌面相邻，那么只靠触摸板或鼠标就能实现目的。以将桌面上的文件拖动到处于全屏状态的 Pages 中为例：
有时，我们需要将他人传过来的多份 Word 文档进行整合。这种情况下，他人文档中预设的样式可能会给排版造成不便。但是，如果一刀切地将其粘贴为纯文本，又会导致文本层级难以辨识。本文介绍一种利用 Office 中的 VBA 脚本，在移除样式的同时保留文本格式的方法。
Sub DirectFormat()
Dim para As Paragraph
Dim fnt As Font
Dim pfmt As ParagraphFormat
For Each