制作《英汉大词典(第二版)》的ocr格式PDF

目前已有的图片版PDF比较模糊,如果滚动放大就更加模糊了,而ocr格式pdf:

1.可以全文通读。
2.可以搜索、选择、复制PDF中的文本。
3.支持滚动缩放,即使放大也仍然是超清像素。

现在的问题是:

制作ocr格式pdf需要良好的工具和使用经验,以及付出的时间等成本,还有解决排版问题等, 这些都还是笔者目前较难突破的瓶颈。

所以,如果有读者对此项目感兴趣,可以尝试入手,与其他同好商议合作完成此任务,并将文件上传到本论坛。

不太懂。。。已经有非常完备的文字版了,为什么还要升级pdf版。。。

无法全文任意通读,

mdx在goldendict中搜索时,只能列出一系列词条,要具体查看需要多点很多次,也就是无法一幕到底。

mdx即使是全文搜索,也只能在条目中进行搜索结果的切换,PDF在阅读器中可以查任何字符,并且直接按住回车键,在全文中进行切换。

mdx在GD中可以通过释义反查单词,但是例句的翻译则需要鼠标悬停在例句上方,而无法进行反查,OCR 后的PDF 两者都可以反查,并且能选取并复制例句的翻译,自由度更高。

要通读,你直接把 mdx 导出成 pdf 就行了,已经有人实现了。

有一些词如果没有通读这本词典,就很难意识到,比如图中的“A3号纸” “亚细亚流感病毒”等,在GD中虽然可以查到,但很难遇到,就不会有去查的想法,而且在mdx中查相比在pdf中查消耗了更多的时间,当然,mdx的优势之一是把多个词典进行了整合,能够集中阅览。


正文第一页 英汉大词典第二版 陆谷孙.pdf (237.9 KB)

就全文通读、搜索,编辑等论,PDF是一种劣质的文件格式,直接用 txt 最方便。像在vs code里搜索几百万字的文本,毫秒可达,用pdf试试看。

《水浒传》大概是九十万字左右,这是在火狐浏览器中的检索速度,还不错。

当然,就编辑功能来论,火狐对 .pdf 格式的编辑支持与 .txt 在vscode这种专业编辑器相比的话,不是很完善。

adobe阅读器对大型pdf检索起来很慢,不知道是什么原因。

pdf 这个格式就不是为了文本搜索设计的。两段视觉上相邻文本,实际存储在 pdf 里的时候可能相隔了很多其他文本,ocr 后的 pdf 是其中问题最多的一种。你可以发现类似正则搜索,或者更精确一些搜索,大多数 pdf 软件都是不支持的,就是这个原因。文本在连续存储的时候搜索最快,pdf 文本搜索慢的原因也是这个。

vscode 用的 ripgrep 这个文本搜索工具,这个工具可以单独安装使用。在大多数文本搜索的基准测试中,ripgrep 通常排第一,对于很小的文本除外。

pdf相对不够方便,但它支持英汉大的三排式排版,这是一个优点,只是现有的版本放大就变得模糊,不能自定义字体、也无法全文搜索…

这是一个在类似排版的日英汉字词典中进行检索的例子,可以查字母、部首、单词、汉字、编码、数字…

ripgrep似乎可以作为浏览器插件使用,如果firefox不支持正则式搜索的话,那就代表扩展了其对于PDF搜索的可选项支持。

尚未知晓ripgrep对ocr后的pdf文件的搜索能力如何,这有待参考与测试,ocr后的pdf可能是非连续存储,会有一些问题,但这些问题应该都有相应的解法,只是还有对成本和收益的考量,不过只要在找到成本最低的方式,就有望在尽可能缩减时间的前提下解决此类问题。

成本最低的方式可能是使用python库、自动化工具等,

其中除了用python脚本提取mdx全文以外,还有对ocr进行pdf的问题,需要将全文在pdf中重新排版,如果ocr后产生与非连续存储相关的问题的话,可能需要人工的干预来重新编辑,这几项任务随着科技的进步,通过阐明具体步骤的方式,将其委派给ai工作流而取得的上限可能会更高,进而增加更大的编辑效率,但这需要进一步的了解与学习。

所以,可以暂且放缓只凭借完全的人力来完成整个排版与校对活动,进而开始探索ai工作流的能力边界,如果在探索时出现了成本问题,则需要退回传统的方式,或考虑是否放弃此项任务,或者当英汉大词典的第三版发行后,可能在网络上流出更加高清的版本,以作为进行ocr的对象。

ripgrep 不直接支持 pdf 的文本搜索,原因除了上面说的文本不连续存储的问题,还有文本编码的问题,但是有第三方工具,可以帮你提取文本后再搜索: