Thanks to organizers, sponsors, volunteers, and attendees for another great PyOhio!
Here’s the slides from my talk on Python 2 to 3 migration.
This post is a supplement to a talk I’m giving at PyOhio about using Python to create PDFs “the lazy way”. It’s the first of a series on this subject which is a bit too big for just one blog post.
In the talk and in this series, I advocate a technique for creating PDFs that uses LibreOffice (or OpenOffice) to do most of the hard work, and I contrast that to the common solution of using ReportLab (or a library like it).
This technique offers some unique benefits, and in some common use cases—most importantly, perhaps in your case—it can be much more efficient than the alternative. I’ll compare and contrast the two in another blog post. In this post I just want to describe the technique I’m advocating.
Creating PDFs programmatically is a task most Python programmers encounter at least once.
When I talk about creating PDFs programmtically, I’m thinking of the situation where one wants to create a lot of PDFs that follow a template. For instance, you might work for a bank that wants to produce end-of-month account statements for each of its 100,000 customers. The cover page will always contain the bank’s logo, some legal boilerplate, the month and year, and a bland stock photo of happy customers doing something unrelated to banking, like this one.
The first page after that will be a summary of the customer’s accounts, and then subsequent pages contain information about the account—a list of transactions, changes in values of stocks, etc.
Each PDF will be different, but similar because they follow a template. Computers are great for this sort of thing, and this technique is particularly good at it. As I said above, I’ll tell you why I think it’s good in another blog post. For now, I want to stop talking mysteriously about “the technique” and actually describe it.
Here’s a concise outline. Don’t worry if you don’t understand all the steps; they’re fleshed out below.
Let’s go through these step by step. I encourage you to follow along. We’re not going to write a single line of Python code, just explore a process. Writing Python would come later when you automate steps 2 – 5.
This step will probably require the most work.
We usually know in advance at least some of the content we want. For instance, in the bank example above, we know what the cover page will look like, where each section should appear in the document, and how a section (e.g. a list of account transactions) should be formatted, even if we don’t know in advance the exact values of each transaction.
Your job during this step is to create a LibreOffice document that will serve as a skeleton (or template, or form) for your final documents. For content that you don’t know (words in paragraphs, images, bullet points in a list, table contents, etc.), leave placeholders.
If you want to play along with this blog post, here’s the LibreOffice document that I’ll use in the examples below.
This is a trick you might not know—LibreOffice documents are ZIP files. (This is true of all documents that follow the Open Document Format for Office Applications). You can unzip them with command line tools, or with the
zipfile module in Python’s standard library.
On my Mac, the following command unzips the document into the directory
unzip practice.odt -d unzipped
After unzipping, you’ll see a bunch of files like this:
drwxr-xr-x 11 philip staff 374 Jul 27 16:43 Configurations2/ drwxr-xr-x 3 philip staff 102 Jul 27 16:43 META-INF/ drwxr-xr-x 3 philip staff 102 Jul 27 16:43 Thumbnails/ -rw-r--r-- 1 philip staff 8988 Jul 27 16:44 content.xml -rw-r--r-- 1 philip staff 899 Jul 27 2016 manifest.rdf -rw-r--r-- 1 philip staff 1005 Jul 27 2016 meta.xml -rw-r--r-- 1 philip staff 39 Jul 27 2016 mimetype -rw-r--r-- 1 philip staff 10319 Jul 27 2016 settings.xml -rw-r--r-- 1 philip staff 14903 Jul 27 2016 styles.xml
Of the files above, you’re only likely to be interested in
content.xml. (You might also want to explore
styles.xml, but I consider that an advanced topic, and I’m trying to maintain a rigorous standard of laziness.)
The XML in
content.xml is governed by the 846-page Open Document Format for Office Applications. You might think I’m going to suggest you read it, or at least familiarize yourself with it.
Heck no! That’s not the lazy way. I’m very pleased that it’s an ISO standard, but I don’t want to learn it if I can save time and effort by not doing so, and you shouldn’t have to either.
Instead I suggest you use what I use: common sense and intution, which can get you surprisingly far. For instance, if you see this in the XML—
<text:p text:style-name="P4"> The fox jumped over the dog. </text:p>
You don’t have to read 846 pages of documentation to guess that you can change it to this—
<text:p text:style-name="P4"> The quick brown fox jumped over the lazy dog. </text:p>
Or even this—
<text:p text:style-name="P4"> No one expects the Spanish Inquisition! </text:p>
Are you starting to see some possibilities?
If you’re doing this programmatically, you can use LibreOffice bookmarks to demarcate the text you want to replace. Bookmarks are visible in the XML and trivial to locate using XPath. You can see this in my example document where I’ve surrounded two blank space characters with bookmarks where adjectives might go to describe the fox and dog.
<text:p text:style-name="P1"> The <text:bookmark-start text:name="fox_type_placeholder"/> <text:s/> <text:bookmark-end text:name="fox_type_placeholder"/> <text:s/> fox jumped over the <text:bookmark-start text:name="dog_type_placeholder"/> <text:s/> <text:bookmark-end text:name="dog_type_placeholder"/> <text:s/> dog. </text:p>
What do you think will happen if you replace the first occurrence of
Text isn’t the only thing you can change.
If you have a list item with bullets and you want another bullet or three, you can just duplicate existing bullets. For instance, if you start with this—
<text:list xml:id="list3413943092755896283" text:style-name="L1"> <text:list-item> <text:p text:style-name="P2">First</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Second</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Third</text:p> </text:list-item> </text:list>
You can turn it into this—
<text:list xml:id="list3413943092755896283" text:style-name="L1"> <text:list-item> <text:p text:style-name="P2">First</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Second</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Third</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Fourth</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Fifth</text:p> </text:list-item> <text:list-item> <text:p text:style-name="P2">Sixth</text:p> </text:list-item> </text:list>
Note that the
text:list element itself has what looks like a unique id associated with it. This is a yellow flag that indicates to me that if you want to copy the entire list, you’ll need to give it a new unique id, and hope that LibreOffice doesn’t reference that id in some other file.
I’m sure the details are somewhere in that 846-page document. You can read that document, or you can also just try your change and see what happens. The worst case scenario is that LibreOffice will tell you that your document is corrupted and you’ll have to go back and explore some more.
Once you’ve made the changes you want, it’s time to reverse step 2, using your modified
Here’s the command that works on my Mac—
cd unzipped && zip -r ../my_new_file.odt * && cd ..
Note that this command doesn’t respect the OpenDocument specification which has rules regarding how the mime type file should be represented in the zip file (as the first file in the archive, and uncompressed, per OpenDocument v1.2 part3, § 3.3 MIME Media Type). It works for me, maybe because LibreOffice is forgiving. It’s not something you should rely on, however. In another post, I’ll present some Python code that constructs the ZIP file according to standard.
If you’re just experimenting, you can just open the document in LibreOffice manually and then use the “File/Export as PDF…” menu item. (Opening manually is also a good test that you didn’t do anything objectionable to the XML.)
Programmatically, I recommend using unoconv for converting your finished document to PDF.
So there you have it! If you feel underwhelmed, keep in mind that this was only a proof of concept. In some future posts, I’ll explain why I think this method is often an excellent choice (and also when it isn’t).
Thanks to the National Cancer Institute for making many photos available for free, including the one used in this blog post which was taken by Rhoda Baer.