師子源, 李 成, 王明飛

(1. 北京印刷學(xué)院,北京 102600; 2. 奧博杰天軟件(北京)有限公司,北京 100022)

個(gè)性化的文檔輸出在越來(lái)越多的行業(yè)中被應(yīng)用。 比如,以前去銀行或保險(xiǎn)公司去辦理業(yè)務(wù)時(shí),所填寫(xiě)的表格往往是預(yù)印制表單,用戶(hù)或工作人員在留空中填寫(xiě)相關(guān)的內(nèi)容。 而現(xiàn)在,得益于動(dòng)態(tài)文檔生成系統(tǒng)的發(fā)展,越來(lái)越多的傳統(tǒng)印制表單被動(dòng)態(tài)文檔所代替。 動(dòng)態(tài)文檔生成系統(tǒng)徹底改變了文檔產(chǎn)生方式,之前靜態(tài)文檔的制作過(guò)程就變成了利用文檔模板和用戶(hù)數(shù)據(jù)進(jìn)行動(dòng)態(tài)文檔生成的過(guò)程。

動(dòng)態(tài)文檔生成過(guò)程通?？梢苑譃橐韵滤牟?。

(1)制作動(dòng)態(tài)文檔模板。 動(dòng)態(tài)文檔生成系統(tǒng)會(huì)提供廣泛的文檔開(kāi)發(fā)工具的插件,用戶(hù)可以利用這些插件在文檔內(nèi)部插入相應(yīng)的變量或規(guī)則。

(2)內(nèi)容組裝。 根據(jù)特定的用戶(hù)數(shù)據(jù),替換文檔模板中的變量;計(jì)算文檔模板定義的規(guī)則,將生成的內(nèi)容添加進(jìn)文檔模板。

(3)文檔排版。 根據(jù)生成的內(nèi)容和文檔模板中的文檔樣式定義進(jìn)行排版,該部分功能稱(chēng)為排版引擎,而排版引擎確保輸出精確、緊湊的排版結(jié)果。

(4)文檔生成。 文檔排版完成后,系統(tǒng)就會(huì)根據(jù)定義好的輸出方式生成對(duì)應(yīng)格式的靜態(tài)文檔,目前,使用最多的格式是便攜式文檔格式(Portable Document Format,簡(jiǎn)稱(chēng)PDF)。

從上述動(dòng)態(tài)文檔的產(chǎn)生過(guò)程步驟描述可以知道,動(dòng)態(tài)文檔從制作到最終發(fā)布是一個(gè)非常復(fù)雜的過(guò)程。 動(dòng)態(tài)文檔生成系統(tǒng)本身作為一個(gè)復(fù)雜軟件系統(tǒng),會(huì)有軟件系統(tǒng)所固有的問(wèn)題(Software Bugs),并且會(huì)不斷進(jìn)行產(chǎn)品功能升級(jí)。 解決這些問(wèn)題或功能升級(jí)過(guò)程中的一個(gè)很小的改動(dòng),最終輸出文檔可能會(huì)發(fā)生很大變化。

而對(duì)于用戶(hù)來(lái)講,只要文檔模板和用戶(hù)數(shù)據(jù)不變,最終生成的靜態(tài)文檔就要始終保持一致。 輸入數(shù)據(jù)一致的情況下,系統(tǒng)迭代更新過(guò)程中新版本生成的文檔必須要和舊版本已經(jīng)生成的文檔保持一致。 只有這種一致性能夠得到保證,客戶(hù)才會(huì)放心地把他們現(xiàn)有系統(tǒng)中的數(shù)據(jù)遷移到新版本系統(tǒng)中。通常,使用動(dòng)態(tài)文檔生成系統(tǒng)的用戶(hù)都會(huì)有數(shù)量極其龐大的文檔數(shù)據(jù),靠人工去驗(yàn)證兩個(gè)版本系統(tǒng)生成文檔之間的差異已經(jīng)不現(xiàn)實(shí)。

為了解決上面提出的問(wèn)題,需要設(shè)計(jì)一個(gè)能夠自動(dòng)化批量比較文檔的系統(tǒng)。 該系統(tǒng)能夠自動(dòng)比較兩份文檔,自動(dòng)生成比較結(jié)果報(bào)表,并且自動(dòng)發(fā)送通知給相關(guān)人員。 同時(shí),該系統(tǒng)應(yīng)該是一個(gè)輕量級(jí)的系統(tǒng),提供多種運(yùn)行方式,既可以方便地集成到客戶(hù)現(xiàn)有的測(cè)試系統(tǒng)中,也可以單獨(dú)運(yùn)行,方便開(kāi)發(fā)人員在運(yùn)行、提交代碼時(shí)檢查會(huì)不會(huì)產(chǎn)生輸出文檔的變化。

綜上所述,確保在動(dòng)態(tài)文檔生成系統(tǒng)的不斷迭代過(guò)程中整個(gè)系統(tǒng)最終生成文檔的一致性是在系統(tǒng)開(kāi)發(fā)、升級(jí)迭代過(guò)程中的重要內(nèi)容。

高麗萍[1]等人對(duì)Word 中圖文混排的文檔一致性的控制做了研究,解決了圖文混排的一些沖突情況。 馬康[2]在結(jié)構(gòu)化文檔的自動(dòng)化提取方面做了研究。 牛永潔[3]等人做了基于PDFBox 的信息提取方面的研究與實(shí)現(xiàn)。 朱玲玉[4]在文檔解析與文本內(nèi)容提取及脫敏方面做了較深入研究。 徐俊剛[5]等人用本地文件模擬數(shù)據(jù)庫(kù)的方法繞過(guò)原系統(tǒng)對(duì)數(shù)據(jù)庫(kù)的依賴(lài),提出一個(gè)自動(dòng)化測(cè)試方案。

本文通過(guò)對(duì)PDF 文檔的解析,提取文檔中的文本、圖像、圖形及表單并分類(lèi),再分別與原文檔中的對(duì)應(yīng)內(nèi)容相比較,完成一致性測(cè)試。 系統(tǒng)基本框架還包括與外部集成模塊、結(jié)果報(bào)表生成模塊和結(jié)果發(fā)送模塊,系統(tǒng)結(jié)構(gòu)圖如圖1 所示。

圖1 文檔一致性測(cè)試系統(tǒng)結(jié)構(gòu)圖

1 PDF 文檔解析

PDF 格式是一種獨(dú)立于應(yīng)用程序、硬件、操作系統(tǒng)呈現(xiàn)文檔的文件格式,適用于郵件、歸檔等發(fā)布需求。 每個(gè)PDF 文件包含固定布局的平面文檔的完整描述,包括文本、字形、圖形、圖像及其他需要顯示的信息。 在對(duì)PDF 文檔比較之前,首先要分析PDF 文檔的基本結(jié)構(gòu)和文檔內(nèi)容的組織方式。

1.1 PDF 文檔結(jié)構(gòu)

一個(gè)PDF 文件從大的方面來(lái)說(shuō)可以分4 個(gè)部分:文件頭(Header)、文件體(Body)、交叉引用表(XRef Table)、文件尾(Trailer),參考文獻(xiàn)都有很詳細(xì)的論述[3][4][6],其邏輯結(jié)構(gòu)如圖2 所示,從Trailer 開(kāi)始進(jìn)行解析可以逐步定位到頁(yè)面組對(duì)象(Pages),進(jìn)而進(jìn)行頁(yè)面內(nèi)容提取。

圖2 PDF 文檔的邏輯結(jié)構(gòu)圖

PDF 的頁(yè)面基本內(nèi)容包括存儲(chǔ)為字符串的文本內(nèi)容、由圖形和線條組成的矢量圖形、由照片和其他類(lèi)型的圖片組成的位圖、鏈接(文檔內(nèi)部或網(wǎng)頁(yè))、表單、JavaScript 等。 頁(yè)面內(nèi)容結(jié)構(gòu)圖如圖3所示,Resources 指示了PDF 資源對(duì)象,包含字體、圖形、圖像、表格等;Fonts 指示字體信息,XObjects包含了圖片、表格等;Contents 指PDF 頁(yè)面內(nèi)容對(duì)象,包含PDF 頁(yè)面內(nèi)的路徑、文字、內(nèi)嵌圖像數(shù)據(jù)等頁(yè)面描述信息,PDF 規(guī)范里都有詳細(xì)描述。

圖3 PDF 頁(yè)面內(nèi)容結(jié)構(gòu)圖

系統(tǒng)選擇PDF 格式作為比較文檔格式來(lái)實(shí)現(xiàn)一致性測(cè)試系統(tǒng),其中基準(zhǔn)文件稱(chēng)為BaselinePDF,對(duì)比文件稱(chēng)為T(mén)estPDF。 PDF 文檔比較模塊需要對(duì)頁(yè)面的所有內(nèi)容作比較,并記錄所有變化。 PDF格式是非結(jié)構(gòu)化的文檔,并且PDF 文檔的頁(yè)內(nèi)容是按照定點(diǎn)描述的,任意內(nèi)容可以輸出在任意位置,這就導(dǎo)致程序不能以流的方式對(duì)文檔頁(yè)內(nèi)容進(jìn)行從上而下的比較。 將文檔內(nèi)容分為文本、圖像、圖形、表單之后進(jìn)行分類(lèi)比較是易于實(shí)現(xiàn)的,需要比較的分類(lèi)內(nèi)容如表1 所示。

表1 PDF 頁(yè)面比較內(nèi)容

系統(tǒng)以分類(lèi)比較的方式進(jìn)行一致性測(cè)試,其基本流程圖如圖4 所示。 首先對(duì)輸入的Baseline 和Test 文件進(jìn)行解析,提取內(nèi)容生成中間數(shù)據(jù);然后將數(shù)據(jù)分為文本、圖形、圖像、PDF 表單四類(lèi);依次對(duì)四類(lèi)內(nèi)容進(jìn)行比較,最后生成比較結(jié)果報(bào)表。

圖4 文檔一致性測(cè)試系統(tǒng)流程圖

1.2 PDF 頁(yè)內(nèi)容提取

系統(tǒng)采用了開(kāi)源PDF 庫(kù)Apache PDFBox 作為PDF 文件的基礎(chǔ)解析模塊。 但PDFBox 解析PDF的結(jié)果數(shù)據(jù)并不適用于PDF 的分類(lèi)比較,需要利用PDFBox 的API 生成本系統(tǒng)所需要的數(shù)據(jù)。

研究PDFBox 中關(guān)于PDF Rendering 部分的接口,可以發(fā)現(xiàn)所有解析PDF 頁(yè)的類(lèi)都繼承于抽象函數(shù)PDFGraphicsStreamEngine,本系統(tǒng)的實(shí)現(xiàn)也應(yīng)遵守PDFBox 的接口規(guī)范和實(shí)現(xiàn)規(guī)則,設(shè)計(jì)一個(gè)符合本系統(tǒng)需求的解析類(lèi),該類(lèi)應(yīng)繼承并實(shí)現(xiàn)PDFGraphicsStreamEngine。 該實(shí)現(xiàn)類(lèi)完成下列功能:

(1)解析PDF 頁(yè)中的所有內(nèi)容。

(2)對(duì)分析出來(lái)的內(nèi)容進(jìn)行歸類(lèi),分為文本,圖形圖像,表單等單元。

(3)記錄所有單元出現(xiàn)的位置及區(qū)域信息,方便比較結(jié)果的展示。

(4)記錄所有單元在繪制時(shí)的繪制參數(shù), 即當(dāng)前圖形狀態(tài)(Graphics State)。

1.2.1 解析頁(yè)面內(nèi)容

設(shè)計(jì)一個(gè)繼承PDFBox 定義的抽象類(lèi)PDFGraphicsStreamEngine 的實(shí)現(xiàn)類(lèi)PDFContentExtractor,實(shí)現(xiàn)該抽象類(lèi)中所定義的抽象方法(Abstract Method),完成內(nèi)容解析和分類(lèi)功能。

(1)解析PDF 頁(yè)中的所有內(nèi)容。

以解析一段文本內(nèi)容舉例說(shuō)明如何實(shí)現(xiàn)抽象類(lèi)PDFGraphicsStreamEngine。 經(jīng)過(guò)對(duì)源碼分析,文本中內(nèi)容的開(kāi)始結(jié)束都有對(duì)應(yīng)的抽象接口,在實(shí)現(xiàn)類(lèi)PageContentExtractor 中需要通過(guò)實(shí)現(xiàn)這些抽象方法,對(duì)于文本內(nèi)容,其對(duì)應(yīng)的抽象方法是abstract void beginText()和abstract void endText()。

beginText()標(biāo)志解析流程開(kāi)始處理文本內(nèi)容,得到一個(gè)新的TextContent,壓入堆棧pageContentStack。 endText()標(biāo)志解析流程結(jié)束一段文本內(nèi)容,將beginText()處生成的TextContent 對(duì)象從pageContentStack 中彈出,將TextContent 對(duì)象加入頁(yè)內(nèi)容列表PageContentList 中。

使用了一個(gè)堆棧pageContentStack 來(lái)檢查當(dāng)前解析內(nèi)容的開(kāi)始結(jié)束是否配對(duì)。 在beginText 處往堆棧中壓入一個(gè)TextContent 對(duì)象,那么在endText處從堆棧中彈出的對(duì)象類(lèi)型必須是TextContent,否則說(shuō)明解析過(guò)程的解析內(nèi)容產(chǎn)生了不一致。

同樣,對(duì)于圖像內(nèi)容實(shí)現(xiàn)beginImage( ) 和endImage()方法,對(duì)于表單對(duì)象應(yīng)實(shí)現(xiàn)beginAnnot()和endAnnot()方法。

頁(yè)內(nèi)容全部解析完成后,所有內(nèi)容對(duì)象(Page-Content)都存儲(chǔ)于隊(duì)列pageContentList 中,Page-Conent 的繼承類(lèi)對(duì)應(yīng)了其類(lèi)型,比如TextContent,ImageContent 等。

(2)記錄所有單元出現(xiàn)的位置及區(qū)域信息。

由于在比較模塊的需求中還需要比較對(duì)應(yīng)內(nèi)容的位置及大小,所以解析過(guò)程中還需要計(jì)算各個(gè)PageContent 的輪廓(Outline)信息。

這里仍然以文本內(nèi)容為例,在PageContentExtractor 中重載(Override) 了方法Protected void drawGlyph2D(),本方法負(fù)責(zé)得到一個(gè)字符的字形(Glyph)。

在drawGlyph2D 方法內(nèi),得到Glyph 的同時(shí),記錄Glyph 的BoundingBox 信息,添加到TextContent 對(duì)象。 一個(gè)TextContent 對(duì)象可能包含多個(gè)字符,只需連接所有字符的BoundingBox 信息,就可以得到最終這個(gè)TextConent 的輪廓大小。

(3)記錄每個(gè)內(nèi)容單元在繪制時(shí)的繪制參數(shù)。

在每個(gè)內(nèi)容單元的繪制過(guò)程中,都有對(duì)應(yīng)的當(dāng)前繪制狀態(tài),包括字體、顏色、變換矩陣等。 程序在記錄內(nèi)容的同時(shí),在每個(gè)PageContent 對(duì)象內(nèi)部記錄當(dāng)前的Graphics State。

完成解析工作之后,系統(tǒng)將會(huì)得到一個(gè)以PDF頁(yè)為單元的完整中間數(shù)據(jù)集合。

1.2.2 PDF 頁(yè)內(nèi)容分類(lèi)

中間數(shù)據(jù)集合包含了PDF 文件的所有內(nèi)容,對(duì)數(shù)據(jù)集進(jìn)行分類(lèi)并生成各類(lèi)數(shù)據(jù)集以便于比較。設(shè)計(jì)比較器的輸入數(shù)據(jù)類(lèi)PageThread,PageThead分析提取的內(nèi)容隊(duì)列pageContentList,生成用于比較的四個(gè)內(nèi)容集合:文本集合(TextThread)、圖像集合(ImageSet)、圖形集合(PathSet)、表單集合(AnnotSet)。

(1)文本

提取PDF 文檔中每一頁(yè)所包含的文本內(nèi)容,對(duì)頁(yè)內(nèi)的所有文本內(nèi)容按照文本位置從上到下,從左到右的方式進(jìn)行排序。 排序完成后,所有文本內(nèi)容形成一個(gè)文本串,根據(jù)文本樣式的變化將文本進(jìn)行分段。 針對(duì)每一段文本,記錄文本內(nèi)容,樣式表等相關(guān)信息,其中樣式信息包含字體、字號(hào)、顏色、顏色空間等,最終生成TextThread。

文本對(duì)比在本系統(tǒng)中是以單詞作為基本比較單元。 但PDF 文本內(nèi)容描述中不以單詞作為基本單元,是以單個(gè)字符出現(xiàn),只需要字符位置正確,PDF 打開(kāi)后就可以得到正確的頁(yè)面展示。 所以在建立一個(gè)TextThread 的時(shí)候,還要加入智能分詞的功能。 本系統(tǒng)的基本分詞算法是:按照位置相近的原則將文本分區(qū)域,將頁(yè)內(nèi)的所有文本分塊,假定臨近的文本是處于同一段落;然后對(duì)每一區(qū)域內(nèi)的文本以空格和標(biāo)點(diǎn)符號(hào)分割,形成以詞為基本單元的結(jié)構(gòu)。 這樣處理的好處是復(fù)雜度低,易于實(shí)現(xiàn);不足之處是無(wú)法形成更有效的結(jié)構(gòu),比如不能知道文本是否在同一段落,或者不能知道文本是否在表格中。

(2)圖形

提取PDF 文檔中每一頁(yè)所包含的圖形內(nèi)容,記錄包括圖形路徑數(shù)據(jù)、畫(huà)筆模式、填充模式等,生成PathSet。

(3)圖像

提取PDF 文檔中每一頁(yè)所包含的圖像內(nèi)容,記錄圖像的特征參數(shù),包括圖像大小、圖像格式、圖像位數(shù)、顏色空間等信息,生成ImageSet。

(4)PDF 表單

PDF 表單在PDF 文件結(jié)構(gòu)里面是獨(dú)立于頁(yè)面描述的,除了分析提取表單本身屬性信息,包括表單類(lèi)型、表單名稱(chēng)、表單提示等,還需要分析提取表單內(nèi)容(Appearence)部分。 根據(jù)PDF 格式對(duì)表單的定義,表單內(nèi)容可以包括任意文本、圖形圖像,因此表單內(nèi)容部分包含以上三個(gè)部分的集合。 同時(shí)提取表單屬性及表單內(nèi)容生成AnnotSet。

2 PDF 內(nèi)容比較

2.1 文本內(nèi)容比較

對(duì)TextThread 進(jìn)行字符串比較(TextDiff)采用的是經(jīng)典Diff 算法最長(zhǎng)公共子序列算法LCS(Longest Common Subsequence)。 LCS 最長(zhǎng)公共子序列算法的基本原理是:用一個(gè)矩陣來(lái)記錄兩個(gè)字符串中所有位置的兩個(gè)字符之間的匹配情況,若是匹配則為1,否則為0。 然后求出對(duì)角線最長(zhǎng)的1 的序列,其對(duì)應(yīng)的位置就是最長(zhǎng)匹配子串的位置。

LCS 算法的開(kāi)源實(shí)現(xiàn)有很多,系統(tǒng)選用了Google 的google-diff-match-patch 實(shí)現(xiàn),該算法用Java 實(shí)現(xiàn),性能優(yōu)秀,非常適合用于本系統(tǒng)需要的文本對(duì)比功能。

TextDiff 結(jié)束后,如果TextDiff 的結(jié)果為相同,則取當(dāng)前相同子字符串的位置,生成一個(gè)字符塊(TextLob)。 如果TextDiff 的結(jié)果為不相同,同樣生成一個(gè)TextLob,此處不相同的字符塊包含下列三種情況:

#INSERT:TestPDF 中的文本在BaselinePDF 中未找到。

#DELETE:BaselinePDF 中的文本在TestPDF中未找到。

#DIFFRENCE:TestPDF 中的文本在BaselinePDF 對(duì)應(yīng)位置的文本不相同。

經(jīng)過(guò)對(duì)TextDiff 的比較,頁(yè)內(nèi)的文本被劃分成為了一系列字符塊的集合。 對(duì)于內(nèi)容相同的TextLob,比較他們的樣式,發(fā)現(xiàn)不同則記錄為一條不同內(nèi)容(DiffContent);對(duì)于內(nèi)容不相同的TextLob,直接記錄一條DiffContent。

2.2 圖像比較

要實(shí)現(xiàn)對(duì)PDF 頁(yè)內(nèi)的圖像進(jìn)行比較,首先取圖像屬性信息進(jìn)行比較,對(duì)包括圖像大小、圖像字節(jié)數(shù)、圖像格式、像素位數(shù)、色彩空間等參數(shù)直接進(jìn)行比較,如果發(fā)現(xiàn)任何一項(xiàng)不同,則直接記錄一條

DiffContent。

如果以上所有比較都相同,則需要進(jìn)一步對(duì)比圖像的實(shí)際內(nèi)容。 首先,利用圖像數(shù)據(jù)生成對(duì)應(yīng)的Java2D BufferedImage 對(duì)象,然后對(duì)兩個(gè)BufferedImage 對(duì)象中的像素進(jìn)行逐一比對(duì),發(fā)現(xiàn)不相同的像素則記錄一條DiffContent。

2.3 圖形比較

將PDF Graphics Path 轉(zhuǎn)換成Java2D General Path,然后利用Java2D Graphcis API 進(jìn)行比較。 對(duì)于比較結(jié)果不相同的圖形,記錄一條DiffContent,同時(shí)記錄當(dāng)前的Graphics State。

圖形比較部分只實(shí)現(xiàn)了直線(Line)的精確比較。 對(duì)于曲線圖形,采用將曲線轉(zhuǎn)成圖像的方式進(jìn)行圖像像素對(duì)比,如果圖像對(duì)比結(jié)果不相同,則曲線不相同。 這種方法好處是容易實(shí)現(xiàn);不足之處是無(wú)法指出曲線到底哪部分不一致。

2.4 PDF 表單比較

PDF 表單可以分為自身屬性部分和表單展現(xiàn)內(nèi)容部分,要實(shí)現(xiàn)對(duì)PDF 表單的比較,同樣需要進(jìn)行這兩部分的比較。

對(duì)于表單自身屬性部分,可以直接比較每一個(gè)屬性值,發(fā)現(xiàn)不同,則直接記錄一條DiffContent。

對(duì)于表單內(nèi)容部分,可能包括任意文本、圖形、圖像,所以表單比較器內(nèi)部就需要包含上述的文本、圖形、圖像比較器,比較后得到所有不相同的記錄。 如果記錄條數(shù)不為零,則記錄一條DiffContent,該DiffContent 可能包含表單內(nèi)容比較結(jié)果中的多個(gè)DiffContent。

根據(jù)內(nèi)容單元比較功能需求,設(shè)計(jì)一個(gè)頁(yè)比較的功能類(lèi)PageContentComparator,該類(lèi)內(nèi)部需要包含上述的四個(gè)內(nèi)容比較器。 內(nèi)容比較器可以抽象一個(gè)父類(lèi)ContentCompartor,在該父類(lèi)中定義一個(gè)抽象方法compare 方法,上述四個(gè)比較器都應(yīng)該是ContentComparator 的子類(lèi)。 在每個(gè)子類(lèi)中實(shí)現(xiàn)compare 方法,在該方法中完成比較功能。

3 測(cè)試及結(jié)論

針對(duì)本系統(tǒng)的特性,尤其針對(duì)PDF 文檔比較部分的特點(diǎn),選取有代表性的PDF 文件作為輸入文件Baseline。 利用PDF 生成庫(kù)通過(guò)編程方式對(duì)該文件做改變,生成測(cè)試文件Test,包括損壞文件、相同文件、刪除一段文字、增加一段文字、改變字體、顏色、大小、插入頁(yè)、插入空白頁(yè)、增加圖像、刪除圖像、改變圖形等。 以此測(cè)試用例的設(shè)計(jì)思路,建立了完善的測(cè)試用例集合。 經(jīng)過(guò)測(cè)試,系統(tǒng)生成文件可以明確指出文檔的區(qū)別和位置。

通常一個(gè)標(biāo)準(zhǔn)的動(dòng)態(tài)內(nèi)容文檔生成系統(tǒng)每天都會(huì)生成大量的文檔,這就對(duì)本系統(tǒng)的性能提出了很高的要求。 因此,在進(jìn)行系統(tǒng)功能測(cè)試的同時(shí),還對(duì)本系統(tǒng)進(jìn)行了相關(guān)的性能測(cè)試。 分別以多頁(yè)P(yáng)DF 文件、多個(gè)多頁(yè)P(yáng)DF 文件、文字密集型多個(gè)多頁(yè)P(yáng)DF 文件作為測(cè)試文件,測(cè)試系統(tǒng)比較一份PDF 文件所需時(shí)間,得出了比較理想的測(cè)試結(jié)果,平均處理一個(gè)PDF 標(biāo)準(zhǔn)頁(yè)的時(shí)間大約在100ms 以?xún)?nèi);最極端的內(nèi)容密集型PDF 頁(yè)的平均處理時(shí)間大約在300ms 以?xún)?nèi)。 完全能夠達(dá)到一個(gè)標(biāo)準(zhǔn)動(dòng)態(tài)內(nèi)容文檔生成系統(tǒng)的測(cè)試要求。

雖然測(cè)試系統(tǒng)得到了有效的驗(yàn)證,但是在測(cè)試方法上還有很多需要改進(jìn)的地方。 如文本提取中分詞算法可以先采用OCR 預(yù)處理來(lái)判斷內(nèi)容結(jié)構(gòu);文本對(duì)比是基于英文字符實(shí)現(xiàn)的,如果是中文字符需要進(jìn)一步研究;圖形比較中對(duì)直線以外的圖形處理方式需要做進(jìn)一步研究。