CTS's Free Downloadable Computer Software: PDF::Builder

A Thought…

I desire to go to Hell and not to Heaven. In the former I shall enjoy the company of popes, kings and princes, while in the latter are only beggars, monks and apostles.

— Niccolo Machiavelli, on his deathbed

I’d rather laugh with the sinners than cry with the saints/
The sinners are much more fun.

— Billy Joel

Perl library for creating and updating PDF documents

Links to files and information for PDF::Builder…

What is it?

PDF::Builder is a fork of the popular PDF::API2 Perl library. See History for further information on its development history. It provides a library of modules and functions so that a PDF file (document) may be built and maintained from Perl programs. It is not a WYSIWYG editor; nor is it a canned utility or converter. Rather, it is a set of building blocks with which you can perform a wide variety of operations, ranging from basic operations such as selecting a font face, to defining the document using a large subset of either Markdown or HTML markup languages. You can call it from arbitrary Perl programs, which may even create content on-the-fly (or read it in from another source). Quite a few code examples are provided, to help you to get started with the process of creating a PDF document. Many enhancements are in the pipeline to make PDF::Builder even more powerful and versatile.

History

The PDF::API library, and its current version, PDF::API2 (version 2) has been available on the CPAN library for many years. Unfortunately, its maintenance record has been less than consistent. It was originally written by Alfred Reibenschuh, et al., and is currently maintained by Steve Simms. I started participating in the maintenance of the package, but butted heads with Steve too many times for my liking. He only wants to fix bugs (at least, for now) and refuses to consider any enhancements, or cleanup of code or POD documentation. If I submit a bug report that is too large for his liking, he simply ignores it. Steve is doing good and necessary work in fixing bugs, but I feel that his scope is too narrow for the good of the product. Thus, I have reluctantly decided that I need to fork the project in order to get necessary improvements into the code. My plan is to include bug fixes he provides for PDF::API2, as well as my own bug fixes and enhancements.

Why not PDF::API3?

It took some consideration as to what this forked version should be called. There was already an official PDF::API3 project on CPAN, but it appears to be stillborn (created in early 2009 by Otto Hirr, and never updated). I also didn't want to call it PDF::API4, as most people are familiar with PDF::API2 as the name of the library, not as PDF::API version 2. So, I settled on calling it version 3 (starting with 3.001) of PDF::API2, for the initial release (distributed from my site). When it came time to make an official fork and release, Steve asked me to not call it API2, so I renamed it PDF::Builder instead, keeping the 3.xxx numbering sequence.

I plan to keep changes as upwardly compatible as humanly possible, but it is possible that some fixes and enhancements might break existing code. If known, I will attempt to note that in the documentation, and provide a workaround or alternate library. Worst case, new calls or methods will be provided, and the old ones left in for now (and deprecated).