Mad Computer Scientist

I’ve been trying to get my nook to provide a more pleasant experience reading PDFs. In all honesty, I saw PDF capabilities as one of the nook’s biggest selling points. I had hoped to take all of the academic papers I was interested in and throw them on the nook, saving on time and paper. I was disappointed to find that the reflowing, which is fine for single column, non-technical material, was a huge pain for a large quantity of the papers I wanted to read.

Recently, I discovered that the nook will not reflow a PDF if the text size is set to small. While this is not at all obvious, it is easy enough once you are aware of it. One problem remains: there is no ability to zoom or pan on the nook. So, for a multicolumn paper with generous margins (fairly typical in academic literature), the text becomes either truly unreadable or straining to the eye. As of firmware update 1.5, this has not been addressed.

The ironic thing is that these missing features are simply huge. I am sure from reading the nook forums that there are a great many others who are or were excited about the nook because of its ability to read PDFs (something that the Kindle DX 3 is supposed to have, alongside panning and zooming). Moreover, since they are using Adobe Editions on an Android platform, the feature would not have been hard to add. Finally, from a UI perspective, I think all that we really want is for panning to work on the PDFs the way it works on the web browser and for there to be an extra zooming feature.

Fortunately, there are some tools to get around these shortcomings, at least in the short term. These all revolve around chopping the PDF a little bit, and most also work by rasterizing the PDF so that the nook’s retouching has no effect.

1. briss is an application to crop PDFs. While one could also do this with ImageMagick, briss first analyzes the PDF, clustering the pages into a couple/few layouts, then allowing the user to set the cropping boundaries manually. It is important to note that, of the three listed here, briss is the only one that does not actually rasterize the PDF.
2. papercrop is an application that analyzes a PDF, dividing each page into one or more “crops”, which it then puts in order and outputs. Because of the analysis it does on the documents, it is particularly well suited to multicolumn PDFs. It was originally built with academic use in mind, so it works especially well for PDFs that fit that mold: computer generated documents of low to medium complexity. Unfortunately, it does not do so well with scanned documents, such as those that come from the Internet Archive, because it treats the speckling from the scans or from dirt on the page as being legitimate parts of the document, reflowing its crops around them.
3. pdfread was one of the first applications developed for the purpose of making PDFs readable on dedicated ebook readers. It rasterizes the content, then breaks it down into image chunks that fit well onto the ereaders screen. It does not support the nook as such, but the Sony Reader PRS-500 profile works perfectly on the nook, since the two devices have the same screen resolution.

In my experience, for whatever that is worth, briss is the best option with single column materials with wide margins. Simply cut the whole PDF down and the nook display is just fine. I use papercrop for anything in which layout design is important. I do not use pdfread that often, to be honest with you, but it is still handy to have around for the odd ball document.

In the final analysis, this toolkit has made a large number of documents readable on my nook, including such fine titles as the Unix Haters Handbook and Paul  Graham’s tome, On Lisp, but in a perfect world (one with panning and zooming on the nook) it would seldom, if ever be necessary.

The other day, I encountered a strange error while trying to unshelve some work in TFS. For those of you who may not be familiar with it, TFS is one of the more server-oriented source control systems around. To keep work that you want, but that is not ready for checkin, you shelve it–which amounts to a semi-private checkin that is not on the main branch. Viewers can see and share one anothers’ shelves.

In this case, I had started some major changes that would not be working for a demo, but some other changes were needed for the demo. The new changes included adding a variety of files, besides many modifications. So, I shelved it.

A few weeks later, I tried to unshelve it. I assumed that I would just have to merge the changes together (not a big deal, in this case). Instead, TFS complained that all of the new files still existed in the folder. The first TFS frustration. By default, when files are deleted from the project and from the source repository, TFS leaves them on disk. This would be sensible enough, if they at least handled it correctly in situations like this.

So, I decided to move all of the files to another location (instead of deleting them–time has made me paranoid about things like this). I reran the command. TFS still insisted that the files existed. Frustration #2. The files simply did not exist, yet TFS insisted that they did.

The long and short of it is that I had to take the files that TFS left on disk and manually readd and merge them into the project, as TFS simply would not allow the work to be unshelved.

It turns out that there is a known bug in TFS shelves, that occurs when files are added, then shelved, and then unshelved again. As a bug, this is so severe I don’t know how TFS ever got released in this state, especially since using shelving in this manner is precisely the sort of thing that Microsoft recommends.

Microblogging, especially through Twitter, but also through its cousin, Facebook statuses, has become the thing of late. I have little doubt that, like most things that are “the thing”, its popularity will fade into the landfill of fads.

In one sense, I have never truly “gotten” microblogging. To be sure, I understand the idea of short (140 characters, if you are a Twitterer) messages–and I have always found them to be a sign of a declining societal intellect. Once, our forefathers, in the 18th century, conducted flamewars in large, thick volumes (if any one doubts me, read up on Alexander Pope and the rivalries that spawned the delightful Dunciad). Now, we discuss grave matters in only 140 characters.

But lately, I have been wondering if a development team might not be the ideal place to put microblogging to good use. Most teams have neither the time nor the inclination to write and maintain copious notes on design and implementation, but they do have running dialog. Shared knowledge makes the discussions short, for the most part, and the decisions and information passed on are so short as to almost be not worth the effort. Wikis are a step in the right direction, but these are far too much like the longer documents that no one wishes to maintain.

The Twitter model of lots of short little notes might actually be a good fit to the stream of consciousness that pervades every development team. Architecture discussions could be left on a private microblogging platform of sorts. A private set up also allows all of the notes to be made semipublic by default, so we avoid the problem of emails where things can (in larger organizations than the one I am in) get caught up into a he-said she-said that could only be cleared up by a sysadmin. The use of Twitter-style @ and # notation would make it easier to cross-reference development notes.

This is actually the same advantage it has over IRC, the traditional hacker standby. Since ever thing is public or semipublic by default, no one has to remember to log the conversation or post the log–or rile up feathers because a log was kept at all.

The largest irony of these musings, is that I know full well that, in one sense, the only purpose I have found for microblogging is in flagrant violation of the model put forth by the site that made it popular, Twitter. On Twitter, everything is public. If, hypothetically, my wife and I were to twitter notes back and forth about family matters (e.g. can you pick up some milk on the way home?), it is public. There is nothing wrong with that, but it is superfluous fluff to just about everyone on the world wide web.

Incidentally, this is why, if you really want to do something like that, set up a private instance of microblogging software. The only valid use your present whereabouts can be to the general public, is as an invitation to be stalked.

But, back on topic, I think that is what is wrong with the microblogging model in the first place. The vast majority of what I have to say in < 140 characters, is something that is not really worthwhile for more than a select few to hear.

There are exceptions, of course.

Some musicians I like use it extensively for tour announcements and to push each others’ stuff. It makes perfect sense. There will be a lot of tour announcements that I, as a fan, am interested in that are less than 140 characters. Where are you appearing? When? (For smaller groups, this information changes a lot, and quickly). Oh, that new album is out?

Most of us are not those exceptions, but I think that when you put some constraints on topic matter and audience, there is definite potential. What I would be the most curious to see, would be an open source project that relies primarily on Twitter or Identi.ca for dev discussions, instead of IRC or email. That would, I think, be the ultimate test of the merit of the idea.

Finally, a little googling made me painfully aware that I am not the only one to have such thoughts. I even saw a few academic papers on the subject, though I have not yet had time to read through them. I think a little survey of the literature on this blog might very well be forthcoming…