Side project: booklet printing in Ubuntu made easy

Booklets consist of sheets of paper folded a couple times to form a book-like version of a document. For example, you could create an A5 booklet by printing a document on A4 paper, 2 sheets per page, with the sheets arranged in such a way that the resulting pages of A4 paper can be folded in half to form an A5 booklet.

I prefer booklet printing of documents over plain duplex printing because it wastes a lot less paper, and results in a more comfortable size to carry around said printed documents.

Unfortunately, Ubuntu doesn't have a booklet printing option unlike MacOSX (so I've been told). This means that printing documents as booklets involves saving the document and running it through a couple of commandline tools before sending it to the printer. Because these steps are too elaborate, I knew my natural laziness would kick in and I'd stop printing booklets if there was no automated solution.

I decided to create a CUPS backend to print booklets. Once installed, the booklet printer that uses this backend is available to any program that uses CUPS for printing. On Ubuntu, that means every program :) When the booklet backend receives the PDF document, it converts it into booklet form and forwards it to any printer you want.

The backend script requires a couple tools that need to be installed first:

apt-get install impose+ psutils

The code for the backend then, is very simple:

#!/bin/bash

if [ $# -eq 0 ]; then
    echo "direct booklet \"Unknown\" \"Print a document in booklet form\""
    exit 0
fi  

out=${DEVICE_URI#booklet:/}
user=$2
title=$3

cat $6 | fixtd -tumble | psbook | /usr/bin/pstops "2:[email protected](21cm,0)[email protected](21cm,14.85cm)" | lpr -T "$title" -U "$user" -P "$out"

exit 0

To use this backend on Ubuntu, download the code into /usr/lib/cups/backend/booklet and set it executable. Then, goto http://localhost:631 and login to your CUPS interface. Create a new printer of the booklet type. Next, type in the booklet printer URI: booklet:/MyPrinter (mind the single slash) will install a booklet printer that forwards the processed document to the "MyPrinter" printer. Make sure it's a duplex printer. Give the printer a name (e.g. "booklet") and indicate that it is a Generic Postscript Printer. Finally, set some default options. In my case, I want A4 paper and duplex along the long edge (standard).

The printer should now be installed and ready for use

Side project: generating clickmaps as meta-data for screenshots

A long time ago, my mom persuaded me into playing Farmville so she could have more Farmville neighbors and gain some reward from that. Since Farmville was pretty repetitive, I created an automated Farmville player in a VM that would play the game 24/7, much to the dissatisfaction of my mother and other people, because the autoplayer blasted away their puny highscores in less than a week.

For a paper I submitted not long ago, there was also the need for this kind of automation. After submission, I realized that my automation could be improved if I could somehow determine which locations on screen were hotspots for an application with regard to clicking. For example, a menu bar obviously has special meaning to any application, and so does a textfield. On the other hand, the title bar or plain blank space does not react to clicks at all.

The main idea behind this "clickmap" discovery, is to observe the shape of the mousepointer as it moves along the screen. The X11 protocol defines a set of standard shapes that should be implemented by any pointer "theme", collectively called the "X11 cursor font" (XCursorFont). Each mouse pointer (cursor) shape is then a glyph from that font. Each of those shapes is represented by a unique color in the output "clickmap" image.

There are some problems with this setup: the current shape of the mouse pointer is determined by the top-most application over which the mousepointer hovers. That means that the application is responsible for changing the mouse pointer shape and if the application is slow, there is a delay between the time the cursor is positioned and the time the cursor shape is updated. Another problem is that for each pixel on the screen, a X11 protocol message must be sent to position the cursor, and then another message to query the cursor shape, followed by receiving a message containing the cursor shape ID. All of this makes that imaging the clickmap is very slow...

A final problem is that the X11 protocol itself does not provide a way to query the current cursor shape. Luckily, there is an extension to the X11 protocol, called the Xfixes extension, which allows the retrieval of the current mouse pointer shape (for applications that take screenshots, or remote desktop software).

All in all, creating a "clickmap" of the current screen is not very practical because it is very slow. If the clickable hotspots on screen change (e.g. animated menus or whatever) while the clickmap is being imaged, the output image is trash.

Nevertheless, I present you with the code in case you want to play around with it, as well as a screenshot from a portion of my screen with its accompanying clickmap (both sized 1024x768). Successive pixels were queried with a delay of 50 microseconds. The entire imaging took 3m43s...

http://data.singularity.be/clickmaps/getimage.c

Best wishes for 2012!

VPS Comparison

• as close to 512MB of dedicated (as opposed to burstable) RAM as possible


• Xen VPS is preferred over OpenVZ over any other platform


• Unmanaged is preferred, we like to do thing ourselves


• PayPal payment is preferred


• Should allow setting reverse DNS


• Should have some out-of-band console

ValueGuard: Protection of native applications against data-only buffer overflows