Reasons for the redesign:
- The codebase is completely bloated and impossible to follow. Changes are very hard to make, especially as a part-time effort. There are several bugs that have been there for years.
- The code doesn't scale - after about 20 pages, the PDF starts spinning its wheels horribly.
- The template language sucks - XML was chosen by the original author because he wanted to play with XML, not because it was the best idea.
- There is no testsuite and retrofitting one will take at least as long as a redesign, if not longer. And, there's no guarantee of success.
- autrijus's initial development of PDF::Writer makes this possible.
- I can't add tables to the current codebase.
I want to find out, from the community, how they want to use a templating system for PDF generation. Here's the thing - templating PDFs is not the same as templating HTML or xSV. Instead of just merging variables with a layout, you are also creating the layout. With HTML::Template or Template Toolkit, you're using HTML as the layout language and you're just plugging stuff in. With PDFs (and Excel), you also have to specify the fonts, colors, and layout.
Some ideas I've had:
- Keep the XML file structure, but do it smarter. I have no idea what smarter would be, but this is the only backwards-compatible solution.
- Somehow, do a TT plugin that provides a bunch of helper functions. Doing this, your template would consist solely of TT directives, some of which would be provide by TT and the rest provided by this plugin. I like this idea, but don't have much of a plan to accomplish it.
- Do something else. I have no idea what "else" would be.
Whatever route is taken, I will probably rewrite Excel::Template to the same codebase, to keep them in sync. (E::T's codebase is slightly better, because I could write tests more easily, but not by much.)
Please don't vote on this node without responding. The last meditation I wrote about PDF::Template is at a reputation of 41 (and climbing) with no responses. While I appreciate the upvotes, I need the responses more. I'd prefer this node to be at a reputation of 0 with 20 responses than at 20 with no responses.
Update: A number of responses have said "Why can't you just PDFify the HTML?" I should have included this in the initial post, but here goes:
The problem with this is that while the datasource remains the same, the Excel, PDF, and HTML portions have very different look-and-feel requirements. For example, a set of images might be required in the PDF that's different from the HTML and that cannot be displayed in the Excel. The difference might be something as simple as a reversed image (instead of white on black, it's black on white). Not to mention header pages, links, bookmarks, table of contents . . . the list goes on and on.
The second issue is headers and footers. HTML and Excel don't have them, but PDF does.
And, that brings up the general issue of pagination. HTML doesn't paginate the same way PDF does, and Excel is different yet again. (I won't even start with RTF.) You'll end up with a really icky-looking PDF if you attempt to merely PDF-ize an HTML document. And that doesn't even start with the problems Excel has with that.
Bottom line - there needs to be separate PDF and XLS templates. What I'm trying to do is figure out how to make it easier to transfer the knowlege a programmer has when creating an HTML layout into a PDF (and possibly an XLS).
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?