1

I have PDF generation feature in my app. I am using iTextPDF for generating reports, so it works well. The problem is not exactly in pdf generation but in approach. Currently PDF generation code looks horrible, hard-coded and not flexible, so there is a lot of duplication and everything is highly coupled.

Are there any best or common practices for such a task? Maybe some architectural approach or pattern? I would be very grateful for any advice and code example that was proven as reliable and flexible.

Null
  • 125
  • 1
  • 9
CROSP
  • 1,548
  • 3
  • 11
  • 17
  • Be aware of iTextPDF license the 5.x are not free if it's for commercial usage. – Walfrat Apr 21 '16 at 11:45
  • @Walfrat: AFAIK, iTextPDF is dual licensed, and APGL will forbid commercial **distribution** (not *usage*) without opening the source code of the derived works. – Doc Brown Apr 21 '16 at 13:56

2 Answers2

8

As long as you want only a PDF version of your report, it's enough to simply apply good factoring practices. Write utility functions, extract common code into subroutines, choose good method names, and after a while you'll have a pretty decent maintainable report generator.

However, the second it looks as if you'll have to support any other output format than PDF for the same report (e.g. text, HTML email, whatever), immediately refactor your code into a generator (decides what information to print and in what order) and a renderer (knows how to produce bold, centered, or double-spaced output).

Then, whenever the report content changes, you only have to update the generator, and whenever the style requirements change, you only have to update a small part of your renderers. And when yet another output format is required, you only have to add another renderer subclass rather then walk through your entire codebase yet again.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • You advice about supporting and abstracting from output document is great.I know about this, but haven't thought in this case about such possible way to bring some abstraction into my code. I totally agree with you all your ideas. Thanks again – CROSP Apr 21 '16 at 17:58
  • Pick a "single source" and then export from that to your desired targets. Back in the day, that would've been a simple XML format. Nowadays docx is often a good choice for that single source (especially if it is one of the ultimate targets of course), since there are many libraries for creating it, and for converting to text, HTML, PDF etc. – JasonPlutext Jun 19 '18 at 00:58
1

Looks like an old thread, but I will comment anyway: hopefully, it will help people coming across this post in search of PDF best practices.

I'll second what Killian said ^^^, and would also link to our own (shameless plug, I am the Product Owner for the library) PDF generator library, similar to iText, where we have over a dozen real-world examples of not only how to work with our library, but how to properly organize your document generators, where we used best practices of OOP (separation of concern etc.)

Give it a look, and even if you don't get to use our library, the examples alone are worth it. The examples are open-sourced under Apache 2.0, while the library is free for non-commercial, education use, as well as you can use it for free without a paid license while you develop and test your application, right up until you get to production.

Library and examples.

lennon310
  • 3,132
  • 6
  • 16
  • 33
Arkadiy Birger
  • 11
  • 1