IanG on Tap

From time to time, I come across PostScript (.ps) files that I want to read. I also have a printer that understands PostScript. And I often like to read stuff in print rather than on screen. This scenario sounds like it should have a really simple solution: just send the file to the printer.

But there's a problem.

My printer has a duplex unit. That's not the problem. That's a thing of wonder. I love double-sided printing.

The problem is that if you just send a PostScript file to the printer, it comes out single-sided.

This is disappointing. My printer vendor provides a configuration user interface, and I've told it I want everything to come out double-sided. And everything I print from Windows does indeed come out double sided. However, anything I send directly the printer, bypassing the Windows print system, comes out single-sided. So evidently the configuration tool does something to Windows, and not to the printer.

There's probably something you can do to change the printer's defaults. (As opposed to the Windows printing defaults for that printer.) The way of doing this is probably different for every printer... Fortunately, there's a solution that's more broadly useful. It works on any PostScript printer, including ones over which you don't have the administrative privileges to change the defaults even if you do know how to change them.

All you have to do is edit the PostScript file that you want to print. After all, PostScript is just a programming language. (It's always struck me as slightly odd that Adobe decided the ideal way of representing images for print was as the source code for a program that would run on the printer to produce the output, but there it is.) PostScript files are always in source code form, which means you can edit them.

To enable duplex, you need to know two things. The first is the relevant code to enable duplex mode. Fortunately this seems to be standard across all printers, and it looks like this:

<< /Duplex true >> setpagedevice

The second thing you need to is where exactly to put this code in the file. To be honest, I've not figured out a definitive answer to this, because I don't really know PostScript very well. However, I've got an empirically tested solution. It works for my printer, and HP isn't exactly an obscure brand, so it might work for you too. I tried putting it inside this section:

%%BeginPageSetup
<< /Duplex true >> setpagedevice
%%EndPageSetup

I inserted this just before the first %%Page: line in the PostScript file. It seems to have worked just fine.

Sending Raw PostScript to the Printer

If you're on Windows, the next challenge is working out what on earth the device name is for your printer. If it's plugged in locally, it'll probably be LPT1:. You might also find that PRN: is an alias for it. If you're using a network-attached printer using either RAW or LPR to talk to it (Windows describes these as "Standard TCP/IP" print ports) then I've yet to work out what the device name is. I tried to track it down using WINOBJ.EXE and couldn't actually find a named device corresponding to my printer.

The hack to work around this is pretty straightforward though if you've shared the printer out through Windows print sharing. (Yes, you can take a network attached printer, and then make it accessible as a Windows network shared device, so people end sending print jobs to a computer over the network which then sends the data to the printer, also over the network...) If you've got the printer shared out through Windows networking you can just do this:

copy MyPostScriptFile.ps \\MachineName\PrintShareName

This effectively copies the bytes in the file directly to the printer. It might sit in the print queue for a bit if there are other print jobs ahead of it, but Windows won't attempt to process the file in any way - it'll just send it straight to the printer.

Why I Like To Print Stuff Out

I print an awful lot of stuff, which is one of the reasons I'm particularly keen on duplex. If you read my blog frequently, you'll probably be aware that I have a screen with a 150 pixels per inch resolution. Moreover, ClearType effectively raises that to 450 dpi horizontally. Given how enamoured I am with my relatively high resolution screen, why do I print stuff?

The PostScript files are a special case. The only software I have that can display PostScript files on screen is GhostScript, and frankly, on screen it produces results that I consider to be low quality. But that's not the only reason. If it were, I'd probably just buy Adobe's PostScript decoding software - I've used that in the past and the results are usually perfectly acceptable. But there are other issues.

A lot of the PostScript files I end up wanting to read are academic papers formatted into two columns. Columns are fantastic if they happen to be the same height as the medium on which you are using them. They are an utter nightmare if the medium you're using (e.g. the screen) is shorter than the columns. Most of these papers are formatted to be read on portrait mode A4 or US Letter. Since my screen is only about 2/3 of that height, you either have to shrink the page, making the text too small, or scroll up and down for each column, which makes reading much more work than it should be.

But columns notwithstanding, I just prefer reading stuff on paper. It's easier. And if I'm proof reading my own work, I always spot errors on paper that I miss on screen. I can cope with reading a whole lot more on screens now than I could a few years ago, thanks to the higher resolution and clarity offered by flat panels, and the stupendously excellent technology that is ClearType. But it still doesn't beat paper for readability yet.

Also, with paper, I can fold down a corner of an interesting page, add post-it notes, write notes in the margin, leave several bits of paper in there as bookmarks, read it while travelling on the London underground, and have a surprisingly large number of documents available and open by using my '3D Desktop', so long as I'm careful not to spill any '3D Coffee' on it from my '3D Mug'. Where digital equivalents of this are available, they tend to work less well in my experience.

Print on paper rocks. It's as though we have been honing the technology, culture, and use of print for centuries.