最近要用到iText來處理PDF來提供User與服務器交互的途徑, 所以從Google和Baidu上翻了翻,學到了一點東西, 想Mark下來以后參考,同時也可以和大家交流一下.
Project最主要是要解決三個方面的問題:
1.用什么Software來生成可交互的Form?
2.用什么Open source tools來Pre-fill Form?
3.在User填完Data后,又以什么方式Submit 到Server處理?
對于第一個問題,自然是用Adobe 的Software啦,但是用Acrobat Pro還是用Lifecycle Designer, 卻讓我費了不少勁.為什么咧?因為Acrobat Pro和Lifecycle Designer 處理的Form的格式是不一樣的. Acrobat Pro里面用的是AcroForm,是Acrobat3.0開始用的格式,而Lifecycle Designer里面用的是Xfa Form,是基于XML的, 兩者的不同請參考以下的摘錄:
Acroforms and XFA forms are different technologies
The interactive forms that you create in LiveCycle Designer are different than the interactive forms that you create in Adobe Acrobat. If you create an interactive form in Acrobat, your form is based on Adobe’s Acroform technology. This technology dates back to Acrobat version 3, and Adobe provides the “Acrobat Forms API Reference” to provide the technical details for this technology. I would not recommend using Acroform technology because XFA is the better technology.
If you are moving from Acroforms to XFA forms, you need to know a couple of important facts about these two technologies:
1.LiveCycle Designer can edit a PDF form created in Acrobat, but Acrobat cannot edit a PDF form created in Designer.
2.JavaScript works differently in these two technologies. Some of the JavaScript routines that work in Acroforms will not work in XFA forms. Adobe has documented these differences in a 43 page online PDF called, “Converting Acrobat JavaScript for Use in LiveCycle Designer Forms.” Designer is a much more robust tool for using JavaScript in your forms, so I recommend that you learn how to script with the XFA object model. See Chapter 4, “Form Scripting,” for more information.
PS: you can find more in the below link: More info about XFA
Lifecycle designer 是后來才有的東西,自然是比Acrobat Pro更先進也更適合用于交互,但我的項目最終還是選了Acrobat Pro,因為我的第二個問題的答案是iText. iText可以用來Pre-fill XFA格式的Form,但是不知道為什么用iText Create的submit button不能submit XFA form(按了Button后沒有反應),后來上網查到原來iText不支持XFA Form, 所以也只能用Acrobat啦.
而且用Acrobat Pro創建的Form有兩個我自己覺得不錯的優點(以TextFeild類型為例子):
1. Acrobat Pro創建的AcroForm是沒有層次結構的,而LifeCycle Desinger創建的Form是有層次的.什么意思咧?舉個例子,同樣是Add一個TextFeild, 把它命名為CustomerName,在AcroForm里面的名字就是CustomerName啦,而在XFA Form里面就成了topmostSubForm[0].Page1[0].CustomerName[0],咋一看,還真是煩.而且你的PDF一改的話,那你的Feild name也相應改了,這樣Program也要改了....
2. Acrobat Pro創建的AcroForm的TextFeild可以自適應大小,一個TextFeild總是有一定的長度,但要填的Value就不知有多長啦,有可能有個CustomerName真的很長咧,這在XFA Form里面就會有些Value Show不出來,但Acrobat Pro創建的AcroForm的TextFeild就可以根據Value的大小而改變字體的大小來適應TextFeild的長度.
以上兩點是我自己的認識,也許Lifecycle Designer也可以做到以上的效果,但目前我是不會,因為接觸Lifecycle Designer比較少,如果有大蝦知道的話請多多指教.
今天碰到了個比較奇怪的問題,居然是因為JSP太大導致文件編譯不了,上網查了一下,把解決方法貼下來,以供以后參考:
The problem is that there is a limit on the size of a compiled method in a
Java class file, and that limit is what we're running up against. Recall
that a JSP page is compiled into a servlet, and into essentially only one
method in that servlet. Hence, if your page contains many, many tags, that
method becomes too big, and up comes the exception that you're seeing.
There are a couple of (partial) solutions.
1) Break your giant page up into multiple smaller pages and bring them
together at run time using <jsp:include>. Note that <%@include> won't work,
because that's a compile-time include, which will get you straight back to
the original problem.
2) Look for places to save on tags. For example, the <html:option> tag was
recently extended to allow the specification of the text to display, so
that you can replace this:
<html:option ... ><bean:message key="foo"/></html:option>
with this:
<html:option ... key="foo"/>
More info pls access this link: Solution
我就是用了第一種方法解決的,之前include JSP的時候用了%@include, 后來用了<jsp:include>就不會用問題了.順便貼一下兩者的區別:
后記:網上還有一種Solution:
try giving this in the deployment descriptor.
<jsp-param>
<param-name>noTryBlocks</param-name>
<param-value>true</param-value>
</jsp-param>
本人沒有試過, 不知好不好用....