clone your own copy | download snapshot

Snapshots | iceberg

Inside this repository


Download raw (3.4 KB)

Title: 500 (continued)
Date: 2008-06-30 14:00
Author: OSP
Tags: News, Works, In the pipeline, Printing + Publishing, Python
Slug: 500-continued
Status: published

For a while already, we wanted to experiment with the Scribus Scripter
API in a printed job and a catalogue for the [Piet Zwart Institute's
Media design graduation show](http://www.wormweb.nl/agenda.php?id=1385)
formed the perfect excuse.

[Mute](http://www.metamute.org/)'s Simon Worthington connected us with
[Identic](http://website.identic.be/), a digital printer based in
Brussels. They can print as many different files as you want without
additional costs, so we asked [Michael](http://www.automatist.org) to
help us with a Python script (modifications by Nicolas, Ivan and Femke)
which runs from inside Scribus, iterating through folders and files
generating a different book cover each time.


Each of the participants in the exhibition has provided us with 500
elements ranging from a series of unique IP addresses, a few lines of
Python that alternate letter sizes, a game icon split into 500 giant
three pixel images, 500 lines of a Wikipedia entry on Berthold Brecht,
stills from a performance video and titles generated in a different font
each time. According to the design rules contained in the script,
Scribus places, colors and sizes each element before automatically
exporting the resulting cover as a PDF.

OK, we did not manage to auto-place svg documents, which we really
really really regret... and our first tests produced 500 super heavy
pdf's that managed to crash the Adobe preflight checker at the printer.

After a bit of testing and trying with the nice people at Identic, we
found that we were embedding a corrupt font in the autogenerated pdf and
this caused the crazy file size. When exporting the PDF manually from
Scribus, Scribus detected the problem and outlined the font
automatically but the scripter-API obviously does not offer such
sophisticated features. So, we simply deleted the troublemaker and the
files Scribus produced after that, are much lighter and most of all:
they print!


With the help of [Pierre Marchand](http://oep-h.com/) and other helpful
people on the Scribus IRC channel, we surpressed our panic about the
initial slowdown of the process, and after 24 hours of continuous
tireless work (1440 minutes / 500 pdf's = 2.88 minutes per pdf. Not so
bad, as Craig Bradney pointed out on the mailinglist), Scribus produced
500 different pdf's, ready to print.

We can't wait to see the final result!

Scripts and material for testing:

Read the discussion on the Scribus mailing list: