{"id":3797,"date":"2010-01-29T13:09:10","date_gmt":"2010-01-29T11:09:10","guid":{"rendered":"http:\/\/ospublish.constantvzw.org\/?p=3797"},"modified":"2010-02-08T00:08:37","modified_gmt":"2010-02-07T22:08:37","slug":"valentine-scripting","status":"publish","type":"post","link":"http:\/\/ospublish.constantvzw.org\/blog\/works\/valentine-scripting","title":{"rendered":"Valentine scripting"},"content":{"rendered":"
<\/a> This week and next, colleague and friend An Mertens<\/a> (a.k.a. Ana Foor) works out of the Elsene local library Sans Souci<\/a>. She’ll be listening to your account of meeting a loved one for the first time, those habits that keep your relationship alive or which imaginary place you would like to visit with your best friend. Just like an oldfashioned Ecrivain Public<\/em>, Ana Foor will transform these conversations into unique Valentine letters and -stories published on the fly. In the waiting room, a selection of (Dutch language) romantic literature is available, plus a choice of styles and formats presented in a catalog developed\/designed by OSP’s Femke, Ludivine, Ivan, Nicolas and Pierre M. Templates<\/strong><\/p>\n We designed a set of 6 basic lay-outs mixed with 9 different decorative ‘spices’ and this for three different types of content (story, poem or letter). On top of that, there are three types of media to choose from (web, A4 sheet and booklet). To help identify each of the styles, we came up with a flexible system of re-combinatorial template names that also somehow explains how the project works:<\/p>\n odfpy<\/strong> Nicolas had pointed us to the odfpy<\/a> library a while ago, and this lovely catalog seemed the ultimate opportunity to experiment with it. odfpy<\/a> adds a Python-scripting interface to OpenOffice; with the help of this library you can dynamically generate files in the Open Document Format (.odt, .ods). odfpy<\/a> uses OpenOffice in the background, but without its graphical user interface.<\/p>\n Fragment of content.xml<\/em><\/small><\/p>\n The Open Document format is written in a rather clean kind of xhtml,<\/a> which means it is legible compared to most other Word Processing or Desktop Publishing files we looked at. Still that did not mean it was evident how odfpy generates a frame, or calculates the size of a font. The odfpy documentation is rudimentary; it provides extensive information on the hierarchy of frames, elements and styles but for example not a list of what style-options are available. While it is nice to know at what point a frame needs to be generated, without the syntax for a single or triple border, whether it is red or shaded you can only guess. We designed sample files and than browsed their ‘source’, reverse engineering document settings and -styles with the help of the Open Document file specifications. It obviously took us a ridiculous amount of time to generate 162 different templates in this way.<\/p>\n Even when the odfpy-scripts Ivan was writing and rewriting, started to read more and more like love letters themselves … even with our general distrust of efficient methods … would we have been better off doing all this by hand? With the printer deadline approaching rapidly, we had to settle for a very basic set of styles but managed to use nearly every OSP font currently available. This publication will be both a stalenboek<\/em> and fontcatalog.<\/p>\n herbal_scripts.zip<\/a> OSP_fonts_ok.zip<\/a> Output to different media<\/strong> transform.sh<\/a> As we were working on generating the files until the last minute, we failed to notice that we somehow introduced full color into a pdf that would need to be printed in black-and-white. Also, the printer needed PDF1.3 and we were generating default PDF1.4. In a quick fix, we added ghostscript<\/a> to the already long list of pdf-tools used in the bash-script; probably making many other steps redundant (ps2pdf has ghostscript integrated for example) but no time for clean-up or rewrite.<\/p>\n transform_gray.sh<\/a><\/p>\n Still not all trouble was over. Our printer reported that he was unable to deal with part of the embedded fonts (Unable to read .ttf? Using an old-style rip?) but probably inspired by our friendly persistance, he figured out a way to transform our files into postscript once more, regenerate the font-images from there and finally … the file passed.<\/p>\n Textflow and style names<\/strong><\/p>\n <\/a> The custom publications An will produce on the fly are based on the same .odt templates that we printed in the catalog. In a first dry-run, we realised that they needed to be corrected since the documents we had generated for the printed catalog, basically consisted of single frames. Also, it took a bit of work to generate documents that made the applied styles correctly available in the OpenOffice style menu. We managed by making each of the documents 16 pages (maximum length of the booklet) but gave up on making character styles behave correctly.<\/p>\n podofoimpose<\/strong> After Ludivine converted three of our favourite templates into css stylesheets for web-output<\/a> (we love @fontface!), our last challenge was to deal with was imposition. Since early OSP-days<\/a> we’ve been experimenting with several ways to generate A5 booklets, but we never managed 2 x 8 pages on an A4 (A7 booklet). Pierre Marchand pointed us once again to PoDoFO, a pdf-processing tool to which he once added podofoimpose<\/em>, adding the useful function to run custom imposition ‘plans’. With only a bit of trouble and help, we installed PoDoFo on our machines (We’re using Ubuntu 8.10 and 9.10):<\/p>\n Start with downloading (‘check out’) the latest files with svn (install svn with Download and install the libraries PoDofo depends on:<\/p>\n Than, copy the files into a folder into your home directory (you need to create the folder first):<\/p>\n From inside the build folder, you now need to compile PoDoFo from source with the help of the cmake-compiler (install cmake with podofoimpose can read imposition instructions from files written in lua, a scripting language that is used with ConTeXt for example. With the help of a proper paper dummy, Ludivine managed to write the correct ‘plan’ to output A7 booklets \ud83d\ude00<\/p>\n
\nPoster and flyer designed and produced in OpenOffice<\/small><\/p>\n
\n
\nFor practical and conceptual reasons, we wanted to produce the customised stories and letters with the help of the well-known word processing tool OpenOffice, and were curious to see what could happen if we’d use that same tool for designing and printing the catalog, poster and invitation too. Most of all we couldn’t resist to play with odfpy<\/a>, a Python library that can generate .odt documents from scratch. It got us into various strange and exotic problems, just the way we like it \ud83d\ude42<\/p>\n
\nThis form<\/a> lists all possible styles presented in the catalog<\/small><\/p>\n\n
\n“Unlike other more convenient APIs, this one is essentially an abstraction layer just above the XML format. The main focus has been to prevent the programmer from creating invalid documents.<\/em>”<\/p>\n
\nTo see what elements an .odt-file consists of, ‘extract’ it like a .zip or .tar file<\/small><\/p>\n<office:body><office:text><text:sequence-decls><text:sequence-decl text:display-outline-level=\"0\" text:name=\"Illustration\"\/><text:sequence-decl text:display-outline-level=\"0\" text:name=\"Table\"\/><text:sequence-decl text:display-outline-level=\"0\" text:name=\"Text\"\/><text:sequence-decl text:display-outline-level=\"0\" text:name=\"Drawing\"\/><\/text:sequence-decls><text:p text:style-name=\"Standard\">Hello World<\/span><\/text:p><\/office:text><\/office:body><\/code><\/p>\n
# -*- coding: utf-8 -*-
\n# drawing hearts in the snow!
\nfrom odf.opendocument import OpenDocumentText
\nfrom odf.text import P, Span
\nfrom odf.style import Style, TextProperties, ParagraphProperties, BackgroundImage, GraphicProperties
\nfrom odf.draw import Frame, TextBox
\nfrom texts import *
\nfrom liblove import *<\/code>
\nFrom the header of character_spices.py: A heartwarming address<\/small><\/p>\n
\nAfter having installed odfpy, run $ python name_of_script.py<\/code> in your commandline and generate many .odt files at once<\/small><\/p>\n
\nSneak preview: Drop the contents of this folder into [yourhomefolder]\/.fonts and restart OpenOffice<\/small><\/p>\n
\nOur next concern was to generate a pdf that could be handled by the in-house city council printer of Elsene. We had 162 A4 .odt files and three A5 .pdf files (produced in Scribus) that needed to be combined into one pdf. We wrote a bash-script that takes all .odt files inside a folder, transforms them into pdf, resizes them from A4 to A5 and than gathers all files into a multi-page pdf.<\/p>\n
\nUsing some of our favorite tools: unoconv, ps2pdf, psresize and pdftk transform a series of A4 .odt files into a multi-page A5 pdf.<\/small><\/p>\n
\nOpenOffice: Where did the characterstyles go?<\/small><\/p>\n
\n\u201cPoDoFo is a library to work with the PDF file format and includes also a few tools. The name comes from the first two letters of PDF (Portable Document Format)<\/em>\u201d<\/p>\n$ sudo apt-get install subversion<\/code>)<\/p>\n
$ svn co https:\/\/podofo.svn.sourceforge.net\/svnroot\/podofo\/podofo\/trunk podofo<\/code><\/p>\n
$ sudo apt-get install build-essential g++ cmake libz-dev libtiff-dev libjpeg-dev libfreetype6-dev libfontconfig-dev<\/code>
\n$ sudo apt-get install liblua5.1-0-dev<\/code><\/p>\n
$ mkdir \/home\/[your_user_name]\/src\/podofo<\/code>
\n$ cp \/home\/[podofo_download] \/home\/[your_user_name]\/src\/podofo<\/code><\/p>\n
$ sudo apt-get install cmake<\/code>)<\/p>\n
$ cd <\/code>
\/home\/[your_user_name]\/src\/podofo\/build<\/code>
\n$ mkdir
\n$ cd
\n$ cmake ..\/podofo
\n$ make
\n$ sudo su
\n$ make install<\/code><\/p>\n