Bruno Lowagie

+ Follow
since Oct 23, 2006
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bruno Lowagie

I didn't get any replies on this post, so I went ahead and searched for other reviewers.
The book was released in May and already received several reviews:
1 year ago

A long time ago, I was featured on JavaRanch with my books "iText in Action" (2006) and "iText in Action — Second Edition" (2010). Now, more than ten years later, I have written a new book that will be released in April 2021:  Entreprenerd: Building a Multi-Million-Dollar Business with Open Source Software. With this post, I am reaching out to the people at Big Moose Saloon with a simple question: are you interested in receiving a copy as soon as typesetting is done (and before proofreading starts) so that you can review it before the book is officially released.

Let me know what's the best way to make this happen.
Feel free to remove this post if it's inappropriate to present your own book as an author.
best regards,
Bruno Lowagie
1 year ago

Zhang Ye wrote:As far as I understand, the "user password" is quite secure, as long as you have a strong password...

That's a misconception. Any PDF encrypted with a "user password" and/or "owner password" can easily be decrypted (not by using brute force, just because password security in PDF is... flawed).
It's a mystery why there are still people who think it makes sense to password protect a PDF.

jiten kothari wrote:there you go

While that will work, it's not the best way to do it.
Please read Chapter 6 of "iText in Action".
I suggest you use PdfCopy or PdfSmartCopy depending on how "different" the documents are.

Thanuja Vishwanath wrote:Please help and provide any link for reference and good tutorial.

As you can see in the previous threads, you can find all that information in the second edition of "iText in Action":

Henry Wong wrote:The winners are:

mohamed sanaullah (155396)
Lester Burnham (183755)
Shounak Kundu (230731)
Muyiwa Babayomi (205137)

I hope you'll enjoy the book!
You want to create the form using Open Office. This means you are creating a form using AcroForm technology. AcroForm technology means: you are creating static forms.
However, based on your description, you say you want dynamic forms. That's in contradiction with the choice you made above, because real dynamic forms can only be created using XFA technology.

Your question isn't one that can be answered in the text box of a forum. You need somebody to analyze your specific requirements and create an architecture/design for you.

I know of projects where PDF snippets were used to create a PDF (with pop-quiz questions for University Students who want to do a self-evaluation). I know of projects where XFA is used to create a dynamic form (but when using iText you can only fill such forms, not flatten them). I know of projects where somebody used AcroForms in a creative way to solve a similar problem.

You (or your developers) will have to study the different options (AcroForm or XFA? PDF template or XML temlate?) and choose the solution that offers the best match for your needs. Personally, I think creating a tabular form in Open Office and then try to add rows (with iText or with any other tool) isn't an elegant solution.

ahmed dohar wrote:Hi,
I didn't find how much the license at you site I just found the categories of the license

That's correct.
There are many different categories and prices vary depending on your use of iText.
You need to contact and they will guide you through the price list.

ahmed dohar wrote:Hi,
Can I read already pdf file and edit it using Itext

You can't edit a PDF, not with iText, not with any other tool.
Editing a PDF is not done.

You can however manipulate a PDF:
- you can stamp extra information on a page (even a watermark under the existing content)
- you can fill out a form
- you can add a digital signature
- you can encrypt it.
- you can assemble PDFs
- you can split PDFs
- ...
All of this can be done with iText.

Please read the TOC of the book and of the free sample chapter.

Hauke Ingmar Schmidt wrote:Thank you.

I am not the implementing this, so I will have to talk to the developer to get hard facts.

The document consists of different pages with different templates. The pages are merged into one document after processing. If I regenerate the PDFs as pure pages, i.e. if I print them with a PDF writer or let the media designer do some Adobe magic, the file size is much smaller than the files generated by iText. This lead me to the assumption that there is a form overhead that could be removed by a (simple?) conversion.

If fonts are the culprit, then the Adobe magic will beat iText. (You need better font management to solve this.)
If redundant templates and/or images are causing the problem, then the developer should use PdfSmartCopy instead of PdfCopy.

Hauke Ingmar Schmidt wrote:I am not sure about the consequences.

When programming an in-house application, the obligation to give the users access to the source code is trivial. But has this any consequences when the generated documents are distributed?

The AGPL was written because the GPL had a loophole when used in a SaaS context: the GPL only talks about "the distribution of the software". In a SaaS context, the software remains on a server somewhere. The AGPL makes sure that documents created as part of a service without distributing the software are covered by the F/OSS license too.

Hauke Ingmar Schmidt wrote:Hej,

we are evaluating to use iText for invoice generation. Right now we have PDF forms that work as layout templates. Filling in and generating the PDFs works. But as soon as fields are filled in the generated PDFs get quite large, from a few kilobytes to megabytes. What is the best way to avoid this? The generated invoices do not need to have any form-related functionality; is it a bad idea to use forms as templates?


Let me give you an example:

I have a datasheet that is 56.54 KB.
I want to use this template to create a document with 120 pages: one page per movie in my moviedatabase.
If I don't read the documentation, I end up with this document with file size 4.84 MB.
If I read the documentation, I end up with a document containing the same information and file size 304.36 KB.

In the first case, the document size consists of 120 times the size of the template + the size of the content of the fields + some necessary overhead. In the second case, the document size consists of 1 times the size of the template + the size of the content of the fields + some necessary overhead. Not using a template will result in a file with about the same size.

Is this more or less the problem you're experiencing?

If not, there are some other reasons why the filesize of a template that is filled in can get huge: are you adding high resolution images? Are you embedding complete fonts? (See the thread about optimization, more specifically about font subsets.)

Kuba Zygmunt wrote:edit: I use PDFSmartCopy to merge multiple PDFs, however I wonder if there is something which can compress the output file.

Optimization and compression are two different things.

With iText you can change the compression level, and for instance use setFullCompression() to compress objects that weren't compressed in PDFs prior to version PDF 1.5. You could also use iText to reduce the resolution of images as described in chapter 16.

Optimization is partly done with PdfSmartCopy in the sense that PdfSmartCopy will detect when a certain image (such as a logo) is added to the PDF file multiple times: PdfSmartCopy will make sure the bits and bytes of that image are present only once.

What iText can't do (yet) and what would be a huge optimization: merge different subsets of a same font into one subset. This is very difficult to achieve and can in some cases mean that the complete content stream needs to be rewritten...

Optimization for fast web access (not for file size) aka Linearization isn't supported in iText.

ahmed dohar wrote:Is Itext support for different encoding can write utf8 as arabic language, and what about images and graphs?

iText supports Arabic in PdfPTable and ColumnText (right to left writing system, ligatures,...).
There are examples on how to achieve this in the book, see for instance the Say Peace! example.
Of course: you need a font that contains Arabic Glyphs such as the Arial Unicode font progral arialuni.ttf
You can use iText to inspect a font program and find out which encodings are supported.

Read chapter 11 to find out that all font types described in ISO-32000-1 are supported in iText, except for MMType1, a type that has been discontinued by Adobe).

Read (the TOC of) chapter 10 to find out which image types are supported.

Two approaches are available to draw graphics. Both are explained in chapter 14.
You have methods that reflect every graphical and text operator and operand available in ISO-32000-1.
But you can also use PdfGraphics2D, which is an implementation of the abstract java.awt.Graphics2D class.

ahmed dohar wrote:Is itext free and open source?

iText is released under the AGPL, a Free/Open Source license written by the Free Software Foundation and OSI approved. The very first versions of iText used to be released as MPL/LGPL, but the use of the LGPL has been discouraged by the Free Software Foundation for several years now, because the LGPL meant that people could use the software in a commercial context without ever having to contribute something back to the community. The migration to AGPL in December 2009 solved this problem.

Executive summary of what this means:
iText can be used as free software if the project/product/application using iText is released under the same terms. In other words: the software using iText has to be AGPL too: The contribution to the community consists of code.
iText can be used in a commercial context if a commercial license is bought: The contribution to the community consists of money that is used to improve the product.

Please consult your legal department if you want to understand the full implications of the AGPL.
Note that iText is a Belgian product, and that the interpretation of "free" according to Belgian law can be different from the laws in your country. See for instance Belgian court Creative-Commons jurisprudence.