最近要用到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>
本人没有试过, 不知好不好用....