rodrigo_borges wrote:

>the system: Electronic Document Magement System that will generate documents 
>by the information gave in the submitting of a HTML form (informations like 
>type of document, subject, from, to, content - the fields depends on 
>document type). 
>  
>
OK.
In this article, there is a form where you can enter numbers,
and depending on the numbers entered, a PDF document is generated:
http://itext.ugent.be/articles/ects-ict/index.php?page=6

There's also the HelloWorld servlet that explains how to switch
between HTML, PDF and RTF, using a parameter:
http://itext.ugent.be:8080/itext-in-action/HelloWorld?presentationtype=html
http://itext.ugent.be:8080/itext-in-action/HelloWorld?presentationtype=pdf
http://itext.ugent.be:8080/itext-in-action/HelloWorld?presentationtype=rtf

Yesterday I demonstrated an app that reads the bookmarks from a PDF
and creates this form on the fly:
http://itext.ugent.be:8080/itext-in-action/FoobarCourses
Select some pages and a custom PDF will be generated based on the 
original PDF.

>the actions: store some documents that can pass by some sectors in the 
>company and control where they are. In each sector they can alter some 
>field, append other documents, ... 
>  
>
OK, you have to analyze the workflow, define the processes,
and design your app accordingly. That's your job, not ours.

>the objectives: use digital document valid for the law and control the 
>document inside the company. 
>  
>
OK. Then you probably also want to read about encryption and digital 
signatures.

>how does it work: the user enter some data in a web page fields and submit 
>it. My idea was to feed one PDF model (a PDF, probably with AcroFields, that 
>will have all the style already done) with the data received by HTML form 
>and save in the database. Later one could change the subject of a document, 
>for example. Then, I need to know whose information on the PDF stored is the 
>subject. 
>  
>
It still escapes my why you would want to store the PDF in a database
(why not on the file system?), but I believe you need the solution I 
described
at GovCamp yesterday.
A professor at my University has built a similar system using iText.
I have described it earlier on this mailinglist.
He has a workflow where different people have to fill in different fields.
When person X in role A fills in the PDF document only fields 1-3
are editable. Then fields 1-3 are set read-only and fields 4-6 are
made editable. The document passes different people before it is
flattened. You can also work with revisions. Afterwards you can
extract revision X of Y to see the document at one particular point
in the process.

>Why I want to use PDF? is out of question let the user, that only have 
>rights to see the document, download it in a format like word compatible and 
>have the chance to change it. And storing fields in database and generate 
>PDF only to visualize will make the cryptography and digital signature worse 
>to do. 
>
>Why to use AcroFields? because all documents must follow some rules like 
>alignment, font, margin, ... and I need to pick each field later then I 
>thought it, or FDF, could help me. 
>
>the question: There is some way to feed some fields and save the PDF 
>document whith some data. Later, open this PDF to get the fields value? 
>
This must be a rhetorical question.
All this is demonstrated in the article I refered too.
br,
Bruno

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions

Reply via email to