zoukankan      html  css  js  c++  java
  • 我与PDF——PdfToy发布周年纪念

    这是很久以前发布在readfree论坛的一篇文章,用于纪念PdfToy发布一周年。最近翻硬盘翻了出来,觉得还没有过时,所以重新发一次。

    ===================================================================

    我对PDF接触算是比较早,上个世纪就开始了。最初是看一些英文的标准、规范、开发文档,中文最早接触的应该是当年曾经广为流行的《家庭藏书》系列。

    最早用的PDF阅读器自然是Adobe PDF Reader(当年叫“阿肚皮”)。后来为了对PDF页面进行调整,经人推荐开始使用Acrobat,偶尔也用Foxit PDF Editor。

    但是改变我的PDF之路的事情,是某年某月的某一天,某人站在我的面前,指着我的电脑屏幕对我说了一句话:“只有外行才用Acrobat看PDF,内行都用UltraEdit32!”

    这句铿锵有力、言简意赅的话就像扎在后脖梗上的一根钢针,一直刺激了我很长时间。在这种刺激下,我不仅学会用UltraEdit32(后来改用更简单的PdfView)看PDF,还坚持看完了《PDF Reference》的前几章——虽然中间看着、看着就睡着了无数次,但每次醒过来后,想起那句话,下次又会接着看的。

    不过真正让这句话发挥实际作用,还是在我开始接触PDG转PDF以后。当时我在某个以PDF文件为特色的BBS上混,那里的PDF基本上都是从PDG转换来的,最流行的转换方法就是所谓“打印大法”,即直接从SSREADER打印成PDF,中间发展出“修改打印机名称”、“修改文件只读属性”等技巧。另外还有一个少数派是先把PDG转换成BMP,然后再转换成PDF。其他的可以参考我当年写的《PDG转图像、PDF的若干方法》一文。

    当时我已经学会用UltrEdit32看PDF,所以第一眼就知道“打印大法”纯属扯淡,自然也不会去用它。而把PDG转换成BMP再转PDF,碰到插图页也就傻眼了,麻烦更多。

    另外当时在那个BBS上,对从PDG转换出来的PDF也开始进行一些美化尝试,包括加挂书签、分段页码、页面透明、统一页宽(“打印大法”可以统一页面尺寸,但会出现白边;其他方法在图像尺寸不统一时,转换后难以保证页宽统一)、将bookinfo加入PDF等。不过这些功能都通过不同的软件或插件完成,对技术要求较高,一本PDF书如果能同时具有上述两项以上的技术,制作者就足以被人尊为“大侠”了。

    由于当时PDG阅读软件太不给力,大多数人都选择把PDG转换成PDF再阅读,我自然也不例外。但面对这样的乱象,我感觉很难接受。所以开始结合自己对PDF的理解,开发了最初的Pdg2Pdf、FreePic2Pdf。这两个软件的最初版本功能尽管很弱,但还是引起了一些人的兴趣,我也靠它们在readfree结识了酷酷、拽拽、车车、菜菜、仝仝、鱼鱼等人。

    在朋友们(参见Pdg2Pic致谢名单)的帮助下,这两个软件不断发展,将当时流行的PDF功能集为一体,最后基本上一统江湖。用前面说的某BBS上某人的评价:这两个软件最大的功劳,就是将某些人引以为傲的PDG转PDF技术,搞得一文不值。

    当时我将PDG转PDF这个过程拆分成两个软件,有好几个原因。其中一个重要原因,就是我感觉当时某BBS上PDF制作有点浮躁,与我理想中的PDF有很大差异,所以希望能够提供一个中间过程,让大家能暂停一下,修正一些错误,包括修正书签(当时还没有PdgCntEditor,只能对中间生成的FreePic2Pdf_bkmk.txt进行编辑)、加入扩展资料等。总之就是不希望用我的软件,批量生产垃圾PDF。

    后来随着技术与软件的发展,PDG转PDF的人越来越少,转换完了也多半不是给自己看,所以我才把这两个软件的功能合并到一起,用一个Pdg2Pic即可实现——垃圾不垃圾的也不管了,反正不是给自己用。当然批量功能是万万不会加的,以免被用于D版事业——还真有人找我谈过,不止一次,连人见人爱、花见花开的RMB都被请出来做说客了。

    在研究PDG转PDF的同时,我也在被另外一个相反的问题困扰——无损提取PDF中的图像,尤其是某些PDF电子杂志中的养眼图像。当时其他人最常用的是Acrobat的“导出所有图像”,但对于经常用UltrEdit32看PDF的人来说,用过一次就不会相信这个功能是无损的。其它工具软件也或多或少存在一些问题。最后我是从xpdf提供的pdfp_w_picpaths得到启发,开发了一个自用的小软件,专门提取PDF中的图像,并自动选择存储格式。当时这个小软件也被我用来反编译用PDG转换成的PDF,以解决我当时清晰版PDG下载能力不足的问题。

    同时在readfree混得越久,我接触到的各种PDF也就越多,其它种种烦恼也接踵而至,包括PDF文件保护、水印、超链接、批量错误检查,等等。最初解决这些烦恼的时候,我还是习惯性地使用UltraEdit32,并且为了促进这个软件的使用,我还在readfree自掏腰包举办过一次竞赛。

    不过手工处理PDF多了,我也会烦的,所以萌生了开发批量处理软件的念头。最终就以最初那个导出图像的小软件为基础,慢慢发展出了后来的PdfToy。

    其实我自己做软件一直有一个基本原则:只做别人没有的,或别人没做好的。发展到现在,我总结了一下PdfToy的主要创新点:

    1、流过滤

    时至今日,这个功能仍然是全世界独此一家、别无分号。我也不太相信将来有哪家商业软件公司会去开发这个功能,因为实在太危险了。免费软件可以厚着脸皮规避用户索赔,商业软件则很难。不过要想用好这个功能,不去看《PDF Reference》是万万不行的。

    2、图像无损导出,并自动选择合适的图像文件格式

    开发的时候这个功能没人做,现在已经有其他人也在做了。不过能转回PDG,尤其是分层PDG的应该还不多。

    3、批量检查

    经常下载、手上有大把PDF的人都知道这个功能的重要性,但是能做到的软件目前我就知道这么一个。虽然还有漏检、误报,不过已经是一种进步。要想对检查出来的损坏PDF进行修复,除了“流过滤”外,UltrEdit32也是经常要用到的。

    总之,从我自己的经历来看,如果只是想“阅读”PDF,Adobe PDF Reader等软件够用了;如果想进行简单制作、编辑,Acrobat及其各种插件、Foxit差不多了;如果真想和PDF较劲,《PDF Reference》总要读一读的,至于平时是用UltrEdit32还是PdfToy的“文件结构”看PDF,就看规模和喜好了。我在很久以前针对网页类电子书写的《对E书制作的建议》一文中,曾经说过:“一个人如果只会用所见即所得的编辑器编辑网页,那么他这辈子大概都只能在电子书制作的大门口打转,很难登堂入室。原因无它:很多隐藏在代码里的东西,在页面上是看不出来的。”这话其实对PDF也适用,虽然听起来感觉没有前面别人对我说的那句话那么简洁、有力。

    (完)

  • 相关阅读:
    hdu 2019 数列有序!
    hdu 2023 求平均成绩
    HDU 5805 NanoApe Loves Sequence (思维题) BestCoder Round #86 1002
    51nod 1264 线段相交
    Gym 100801A Alex Origami Squares (求正方形边长)
    HDU 5512 Pagodas (gcd)
    HDU 5510 Bazinga (字符串匹配)
    UVALive 7269 Snake Carpet (构造)
    UVALive 7270 Osu! Master (阅读理解题)
    UVALive 7267 Mysterious Antiques in Sackler Museum (判断长方形)
  • 原文地址:https://www.cnblogs.com/stronghorse/p/15789961.html
Copyright © 2011-2022 走看看