如何在本地将 DjVu 转换为 PDF:一次初步尝试

DjVu 是一种常见于互联网的扫描版的电子书分发格式。由于把内容部分和背景部分分开保存,DjVu 格式的电子书能在较小体积的前提下仍然保证内容部分的锐利。线上一些网站将 DjVu 转换为 PDF 之后在锐度严重损失的前提下,体积通常会膨胀数十倍。这些线上工具也并未提供任何可以调整的参数。

在移动设备上进行 DjVu 材料阅读的现状

然而将 DjVu 转换为 PDF 的需求仍然存在,因为在不少系统上围绕 DjVu 搭建的基础设施极为有限。譬如在 iOS 上,许多应用间能够直接传输、导入、阅读、批注 PDF,可以说一整套工具都是围绕着 PDF 搭建的。而反观 DjVu,目前我只找到了一款叫做 BiLibre 的应用,能够一定程度上支持使用 Apple Pencil 批注,这款程序还只是一个 KyBook 的程序的试验田而已,功能比 PDF 阅读器而言可以说还是相当不完善的。

可能由于需求较少,目前也基本没有在本地找到一套完整可控的工具链能完成这一系列操作。

将 DjVu 转换为 PDF

目前探索来看,比较好的一对工具是 DjVuLibre 和 Ghostscript。

DjVuLibre 是个开源的 DjVu 处理包。它提供了一个简易的图形化界面,能够进行简单的 DjVu 阅读。它的一系列命令行工具,能够比较好地进行 DjVu 的制作、解包工作,能把 PDF 以及许多图像格式转换为 DjVu。它同时也提供了编程库,被 SumatraPDF 等阅读器作为 DjVu 底层支持库使用。

Ghostscript 则是老牌的 PostScript 处理程序,同样包括了用于阅读的图形化界面和一系列命令行脚本。这一系列程序被包含在 TeXLive 发行版中。

因此本文提出一种可行的操作,是使用 DjVuLibre 中的 djvups 命令将 DjVu 文件转换为 PostScript 格式,然后使用 Ghostscript 中的 ps2pdf 将 PostScript 格式的文件重新转换为 PDF。这样我们几乎得到了高质量的 PDF 原稿。

命令行操作的伪代码如下

djvups [djvu-file-name] [ps-file-name] [-verbose] [-page='1,3,7-10'] [-..]
ps2pdf [ps-file-name] [pdf-file-name]

要注意的是,如果没有提前将可执行文件的目录添加到 Path 中,两条命令均需要替换为实际的文件路径;Windows 下 ps2pdf 是个 bat 脚本因此要注意把拓展名包含在内,因为有个不含拓展名的文件实际上是个 Bash 脚本。另外在 djvups 中,-verbose 可以显示一个简易的进度条,-page='1,3,7-10' 选择转换的页码,还有后续更详细的设置能调整 PostScript 的分辨率、颜色和灰度等。

文章完成后,经过提醒,我注意到在 superuser 上对于这一过程有一定程度的介绍,可供参考。

压缩 PDF 的体积

可惜的是文件体积膨胀的问题仍没得到很好的解决,甚至可以说远远超出我的想象。原本 37 MB 的 DjVu 文件转换为 PostScript 文件后有 7.7 GB 之大,再次转换为 PDF 之后也有 1.44 GB,体积非常可观。下一步,我们只能看看能否在合理范围内缩减体积,无论是从最后压缩 PDF 还是基于损失 PostScript 文件的前提之下。Adobe Acrobat 将其转换为压缩体积的 PDF 能将体积减小到 242 MB,略小于线上转换出的 343 MB,两者的实际效果相差不大。

如果想要进一步地缩小文件大小,只能尝试一种被称为 ClearScan 的操作,这种优化与压缩的方案在 Adobe 的产品博客上有较为详尽的比较和介绍。这种优化方案简单说就是讲文本部分进行 OCR 处理,并构建一套共享的字体,通过这套共享的字体来优化体积。在 Adobe Acrobat DC Pro 中,这种操作的名字略有变化,选项位置藏在「工具 – 优化扫描的页面 – 文本识别选项 – 编辑 – 输出 – 可编辑的文本和图像」,这可以说是 DjVu 思路的 PDF 压缩方案,把前景的内容和背景分离,效果可以说见仁见智,但总体而言对于原本高分辨率的原稿,效果还是可以接受的。在我的实验之下,最终效果是把前文所述的 343 MB 的文件压缩到 172 MB。但这种操作由于涉及 OCR 的操作,因此耗时比较恐怖,可以考虑睡前进行。

本文提供的方案只是一种可行的本地操作方案而已,多了一种选择,但实际操作上,只能说还是要在体积和质量上做艰难的取舍。

Android N 升级与 CJK 字体

Android N 发布已经一月有余,今天终于升级换上。用了一天,一切顺利,此前预览版中的问题没有碰到,就我而言已经可以当作主力系统使用。截至发稿时,适用于 Android N 的 SuperSU 刷机包已经释出,TWRP Recovery 也已可用。

本次升级最令人开心的一点,就是在初次启动进行初次设定的过程中,允许不联网进行设置了。这就免除了此前由于大陆网络原因无法连接 Google 的服务器,不拔卡或连上 Wi-Fi 后会卡在 Google 账户登录步骤上的问题。虽然并不是常用的功能,但的确免除了太多的麻烦,是我最喜欢的细节了。

其他关于 Android N 中与前代 Android 的各项差异,已经有无数的文章加以赘述,在此不再赘述。本文主要讨论一下关于内置中日韩字体 Noto Sans 的最新状况与个人根据需求的改进。

内置中日韩字体 Noto Sans CJK 方式的改变

从 Android L 开始,随着思源黑体(Source Han Sans)的发布,Android 便开始使用 Noto CJK 作为随机中日韩字体。

为了适配不同的使用需求,Noto Sans 很早就在自己的 Github 仓库中释出了采用不同打包方式的多个版本,具体信息可参见 Noto Sans CJK 的版本的介绍和选择指导。在 Android N 以前的系统中,随机附带的字体均为「Region specific OTF subsets」,而 Android N 开始,采用了「CJK OTC fonts (Thin, Light, DemiLight, Regular, Medium, Bold, Black)」的模式。如果从字体文件名上来看,就是从

NotoSans{JP, KR, SC, TC}-[weight].otf

变成了

NotoSansCJK-[weight].ttc

而没变的是,随机附带的仅有 Regular 字重。不过日文、韩文、正体中文、简体中文被打包在一起。

当然,相应的配置文件(仍是位于 /system/etc/font.xml)也发生了变化,关于中日韩字体的描述部分由类似

<family lang="zh-Hans">
    <font weight="400" style="normal">NotoSansSC-Regular.otf</font>
</family>

变成了

<family lang="zh-Hans">
    <font weight="400" style="normal" index="2">NotoSansCJK-Regular.ttc</font>
</family>

这样的形式,可以看到为了支持 OTC(OpenType Collection,后缀为 .ttc)而而增加的 index 属性。

一如往常,若是需要增加相应的字体的话,只需将字体文件拷贝到 /system/fonts/ 目录下,并在配置文件相应的行即可。具体可参见附录部分。

另外,拷贝之后需要格外注意的一点,拷贝过去的字体的文件的的权限需要为 -rw-r--r--(644),否则系统可能不能正常读取这些字体。

比较难过的是系统等宽字体默认还在使用 Droid Sans Mono,我还是手动把他们替换成 Roboto Mono 了(Github)。

虽然能够手动操作,但默认中日韩字体只采用单一字重、仍然没有用上「CJK OTF fonts with different default language」还是挺令人难过的,但对于 OTC 方式的支持,而且介绍页面有了它们的下载链接,不再需要去仓库里一大堆文件总还是方便了一些的。

继续阅读“Android N 升级与 CJK 字体”

将 Windows Phone 短信迁移到 Android

Windows Phone 不是一个坏系统。本来就来的晚,还有很坏很坏的更新支持(大部分内建 Windows Phone 8 的手机无法升级到 Windows Phone 10)等一系列坏体验,还有微软慵懒的开发周期,实在是让人心寒。而无法安装购买便宜货的 APP 成为压倒骆驼的最后一根稻草,使得母上大人终于从 Lumia 630 出走,在我推荐换到了 Android 系统的 OnePlus X。

相比其他的消息软件而言,短信是最易于处理的,也是最难处理的。当然这是针对微信这些有大公司背景的软件而言的。微信这些软件虽然提供了软件内备份功能,但却由于外部不可定制,损失了诸如定期备份、以及自己定制内容的自由,以及在各个平台上都能阅读的可能性。这是个自由度或者说是可能性的问题,虽然一定程度上为我们提供了方便。

而短信,作为一种通用型功能的存在,只要保证可交换格式文件的存在,总是可以读的。而本文中的 VMSG 与 XML 就是这样的两种格式。而开发者也会围绕着这些开放的文件格式搭出各种各样的工具,实现各种各样奇奇怪怪的功能,即使没有人做,自己也可以做。这也算是使用这些开放格式的幸福感的源头。

本文尝试从 VMSG 与 XML 两种文件格式来一窥短信存储的形式,并在其中搭设桥梁,让文件的交换从可能变为现实。


继续阅读“将 Windows Phone 短信迁移到 Android”