Hello, computer.

Or : I've posted version 0.2 of pmPDF.php which adds support for images.

The Pocketnet

Around the same time I wrote about the papernet Aaron Hillegass released PagePacker, a drag and drop OS X application to generate PocketMod booklets.

PocketMod books are insanely cool since all they are is a piece of letter-sized paper, with a single tear that you can do by hand, and folded in to a book. DIY books are nothing new but the thing that makes the PocketMod stand out is how simple it is : All of the folds are no more complicated that folding the page in half a few times. The actual tear happens to be along one of the creases so there's no need to worry about ruler anxiety. You don't even need a printer if all you cared about was having a quick and dirty notebook with pages. Profit!

Their weakness — and this may be by design — is that while their form doesn't limit them to a single sheet of paper a booklet with more than 8 pages requires that the sheets be nested inside one another. Which means you have to keep track of pagination and whether or not page 8 is actually on sheet 1 or sheet 3. The other issue, if you want to generate one of these things using a computer programming device, is that none of the pages on a given sheet flow left to right; one half flow top to bottom and the other half bottom to top.

Which means that if, like me, you are lazy and have built your tools on the backs of people smarter than you you suddenly find yourself up to your arms in someone else's code trying to figure where and when to rotate $x and remembering that page breaks and automagic new lines are a relative thing depending not only on the actual dimension of your piece of paper but also how many sheets you are using and what page you are on.

Which I guess is a really long way of saying thanks to Aaron for goading me into actually doing it :

$args = array('folds' => 1);
$pdf = new pmPDF($args);

$pdf->SetFont('Helvetica');
$pdf->SetFontSize(18);

foreach (range(1, 16) as $i){
	$pdf->add_text("page {$i}", $i);
}

$pdf->Output();
                    

Which, let's face it, is not very exciting. But plumbing never is until you realize that this suddently doesn't sound quite so crazy, anymore:

By the end of the trip I was full of ideas for community driven websites where you could build and print your day's (or your week's) journey and fold it all in to a handy little booklet that would fit in your back pocket. Like most of these things, it quickly got crushed by too many ambitions and too many moving parts. And then there's the folding thing which is compounded by lack of consumer grade printers to print on anything but letter-sized paper.

It's not quite there yet. A few more boring details remain : Image support and placement (which is actually in the code, half-baked, if you care to look); positioning text in general; more specifically floating text around images. And formatted text which is probably more important to a lot of people than it is to me. But these are details and shouldn't require anything more than the patience to keep track of who is on first. The exciting part is that this could be the guts (the plumbing) of a system to take the magic of online publishing tools and turn it in to something personal, and maybe even beautiful, that people can hold in their hands unburdened by the weight of technology.

And then Stikkit went and published their API.

Maybe I am a bad person for not liking online note taking services. I like Stikkit and continue to be impressed by it, purely as a web application. Despite the fact that I am often tethered to the computer (either by choice or a lack of imagination about what to do with the day) I really don't want to be reliant on the fuckers when I actually need to do or to remember to do something. If I scribble something down while I am work, do I really need to whip out my laptop while I am standing in line at the bank machine to see what it was? Besides, if there's no wireless connection nearby and there really is a way to get online WITH MY MIND no one has let me in on the secret yet.

So last night, while I waited for dinner to cook, I cranked out a simple library to query Stikkit for my stuff and squirt it in to a booklet. You can use the API itself to filter stikkits by tag and date and all the other crunchy goodness they allow and the PDF library to add page breaks after each note. Or not. Suddenly, the Interweb seemed useful again!

But wait — there's more! Imagine that for every note or todo item, there was a QR (bar) code next to it. The code would encode nothing more than a URL containing a link back to Stikkit which would delete the item, or mark it as done. You can do this today (using a cameraphone with a barcode reader) for stikkits proper but not for todo items since the former action can be done using a plain vanilla HTTP GET request while the latter requires a PUT.

(This is probably the next thing I will do but it means digging out the barcode library I used for aaPDF, which I promise I will release soon, and writing a bare-bones Atom parser to get the various bits for properly addressing items in the Stikkit database.)

Kellan always scowls at me when I say things like The whole REST model, purer than the driven snow, is just dumb because of stuff like this but I am right and he is wrong. There are real security concerns about using GET to modify things on the Interwebs but there are various workarounds (all of dubious quality) and short of encrypted connections and proper crumbs and validation just sending something using the More Better™ HTTP verb strikes me as pedantry. I say this because the street has found its own use for GET; namely, pointers to do something. I can encode a proper POST request in a barcode but until I can invoke a web browser passing that request (instead of a simple URL) we are going to be stuck with problems like this.

In a world where small pieces are loosely joined and programming anything that fits in your pocket continues to be a chore, the built-in web browser will be the only realistic way to talk HTTP. This is further compounded by the lack of addressability in scrumax-y applications. I can't find the post where Stikkit announced that individual notes were made linkable using a GET, but if there's a way to link to an interstitial page to delete an item (for example : http://stikkit.com/stikkits/nnnnnn/delete) then I haven't found it.

Assuming I could log in to a mobile-ified version of site proper, passing my API key as a authentication parameter in the absence of a cookie, and do all the necessary POST-y / PUT-y bits in the browser then I would happy enough to do that. So maybe I don't really have any beef with the RESTonauts other than to ask them to remember that, rightly or wrong, it's still a messy world down here.

Details, details.

In the meantime, I have released versions 0.1 of pmPDF.php and pmStikkit.php.

The former accepts one of more chunks of unformatted text (excepting newlines; these things are mostly pointless without the newline love) and generates a PDF file with the text formatted as minty PocketMod pages. The latter uses the former and queries the Stikkit API to generate the text for the final document. Both require the FPDF library as a dependency.

The possibilities are endless if by endless you mean four or five letter-sized sheets of paper because any more and the whole nesting pages thing starts to get ugly...

“Wait, aren't machine tags just RDF?”

Meanwhile, in the town called Patience :

No, machine tags are not RDF; they could play RDF on television, though.

Ladies and gentlemen, machine tags!

Some day it would be fun to publish the internal theory and practice document we had going while we planned and built this, but that can probably never happen. As sloppy seconds, I have started keeping a list of machine tag related pointers on del.icio.us.