E-book conversion on a Mac

I’ve been eyeing the Amazon Kindle for some time. Unfortunately, I’m too poor to buy one right now, but that can’t keep me from preparing for one, right?

The other week, I got my hands on the Kindle app for iPhone (I’ve been using Stanza to read LIT-formatted eBooks); it’s a very polished eBook reader app. It may not have all the extra features that Stanza does (color/typeface modification, namely), but it does make for a solid, crash-free (as far as I’ve used it) reader. Better yet, it can further my fantasy of one day actually getting a Kindle, so I can buy and read eBooks to my heart’s delight and still have them on a device I plan to get one day.

So I set out on a nerdy quest to get all the LIT eBooks I’d been reading and convert them into a format for the Kindle. One site I found was particularly useful, and it led me to Mobiperl: a collection of Perl apps that parsed and converted various non-DRM’d eBook formats into the MOBI format (MobiPocket; the Kindle uses it, along with the Amazon-proprietary AZW format). I also found PDFRead, which should allow me to parse PDF files and convert them into eBook formats as well. PDFRead took a lot of setting up to do; namely there were a ton of prerequisites to install (really, there were prerequisites for the 4 or 5 prerequisites for PDFRead to install). Fortunately I’ve got MacPorts, so getting those was a snap. It just took forever to build and install them (it even installed a newer build of the GNU C compiler than what I had). Mobiperl took some getting used to Perl (and I’m still not used to it), or at least to figure out how to use CPAN to install a set of prerequisite packages (like Palm::PDB). But after that was said and done, and a pre-compiled-for-Mac ConvertLIT binary was downloaded and installed on my path, the lit2mobi command line tool worked like a charm. In fact, it even worked better than a Python app that’s supposed to be an all-in-one tool for cataloguing and converting eBooks, Calibre.

Now, I had grown to like Calibre; I started my whole eBook rampage yesterday with this app, and I still like it… but only for cataloguing and downloading missing information for my books. It’s like my iTunes for eBooks, but I do all my converting outside of the app. I tried converting a LIT book to MOBI format using the built-in conversion feature of the app, and it turned out like garbage (spacing was all off, characters were missing or replaced with weird symbols, etc.). Mobiperl, however, works like a charm.

As it turns out, PDFRead was a bust. It takes the PDF file, turns it sideways (WTF?), makes it look like it’s run through a photocopier, and then saves it as an HTML file somewhere within my /var/ directory. That’s not acceptable to me, especially with all the time I spent yesterday downloading the prerequisites. I’ve been looking into Mobipocket Creator which should work, but unfortunately it’s Windows-only, which puts my Mac-centric eBook process a little off. At least it runs in CrossOver!

Snow Leopard’s Python 2.6 site-packages (and a psycopg2 issue)

THE ULTIMATE EDIT: I’ve got new instructions on how to conquer Symbol not found: \_PQbackendPID! Check them out here.

Maybe I’m a newb, maybe I’m not a newb. But I had a hard time installing Django (from scratch) on my new install of Mac OS X 10.6 Snow Leopard. It appears my issue was with the site-packages location. It’s got python26 installed by default, installed in

 /System/Library/Frameworks/Python.framework

So I ran my handy site-packages finding command:

 python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

It gave me this path.

 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages

So I linked Django to that directory. But when I tested my setup to see if it would load the Django modules, it wouldn’t. So I printed my pythonpath (going into the python shell and running import sys; print sys.path) and I found the only default site-packages directory in pythonpath.

 /Library/Python/2.6/site-packages

Once I linked Django there, it worked like a charm. Hope this saves you a 5-minute headache or something.

Update: I also ran into a bit of a tiff installing psycopg2 from source. I ran the following commands, which installed psycopg2 into the previously-listed System site-packages path:

 python setup.py build
 sudo python setup.py install

Rather, once I ran the easy install command (the setuptools for this seem to be included), my python setup found all the modules it needed for PostgreSQL integration.

 easy_install .

Again, hope this helps another 5-minute headache!

Another edit: there’s been some discussion in the comments about a problem with PostgreSQL/Python integration throwing errors in Snow Leopard. Namely, it’s the following error message:

 Symbol not found: _PQbackendPID

The general, scientific Internet consensus is that it’s due to a weird mixture of 32-bit plugins with a 64-bit process. Until more and more things become available as 64-bit, you’ll probably want to run Apple’s build of Python 2.6 as 32-bit for the time being. Here’s the terminal command to do just that.

 defaults write com.apple.versioner.python Prefer-32-Bit -bool yes

Not sure if that needs to be run with sudo, but there you have it. Thanks to @Mark and @John Simons for laying this out and explaining it.

Yet another style: #3, b-γ

Here’s my third style for Growl, and it’s called b-γ. I’m now hosting my code at Github for these styles and you can download pre-made builds of these styles on my Github repo’s downloads page.

My TextMate setup

Taking a few cues from Alex Payne’s blog post on using TextMate, I’ve got a nice little setup for how I like to use the handy Mac text editor. I’m not sure how much I’ll continue to use this, however, as I may be making the transition to MacVim if TextMate doesn’t show any signs of development activity soon, but for now, my TextMate setup seems to work well for me.

Plugins I can’t live without

ProjectPlus

First off would have to be ProjectPlus. This takes the tired old TextMate project drawer (the one you get when you open a whole folder with TextMate) and gives it a much-needed kick in the pants. It adds support for version control status on files (you can see which files are committed to git/svn/hg, etc), updates the UI, supports Finder-like color labeling on files, and more. TextMate without this is bleak.

MissingDrawer

I partner this with MissingDrawer, which more or less integrates the drawer with TextMate and makes it look its purdiest.

Bundles that I work with

GetBundles

First and foremost, GetBundles, GetBundles, GetBundles. Make sure you’ve got Subversion (you’re on a Mac? You probably already have it then) installed, then whip up your Terminal.app, and run the commands here. Next time you open up TextMate, you’ve got a special bundle installed that fetches other bundles that are retrievable via official TextMate trunk, or via the ever-closer-to-official GitHub listing of TextMate bundles. All in an easy-to-use GUI for searching, installing, and updating them. This bundle is the king of all bundles, and I’m surprised it’s not included with the install of TextMate.

Python-Django.tmbundle

Syntax highlighting for both Python and Django, available at GitHub. Installable through GetBundles. Seriously, though, get GetBundles.

Other UI enhancements

Green Moleskine

Jason Evers’ Green Moleskine UI refresh for TextMate is the last bit of goodness that I use to round everything out. It enhances colors in the sidebar, changes the folding indicators to look nicer, and also includes the MissingDrawer plugin (as well as a few I don’t use, like WebMate and SVNMate). Check it out; it even comes with a nicer icon than the purple one TextMate comes with.

Recap

All in all, I have a working environment that works for me. It certainly tides me over until TextMate 2, if that piece of vaporware ever gets here.

Conquering Symbol not found: _PQbackendPID

Author’s note: this is in reference to a previous post, which didn’t quite involve this error, but evolved to a discussion on it anyway. It’s become a problem for me as well, and I didn’t want to run Python as 32-bit, so I’ve figured something out. Here it is.

I’ve found what may be the best solution for this, and it avoids MacPorts’ mumbo-jumbo (of which I’ve been trying to avoid as much as I can). It actually involves Homebrew, a new Mac package manager that bests MacPorts in a number of ways. It involves rolling up your sleeves and doing a little more work, but it adheres much more strictly to the Mac-like idea of not having to sudo for stuff as much as possible.

Anyway, install Homebrew, which I’ve done, to /usr/local, and use it to install python and postgresql (the directions for all this are at the github page for Homebrew). Then, download the source for psycopg2 — either recent build will work, I’ve used .11 and .13 — and unzip it somewhere, and then use the easy_install . command like before; this should use the new Python inside Homebrew’s setup (inside /usr/local/bin) instead. This worked for me like a charm, all without MacPorts (thank goodness)! Note that to get your shell to recognize the new Python over the old one, you’ll have to prioritize /usr/local/bin on your $PATH. You should probably already know how to do that.

Why does this work? From poking around the Intarwebs, as far as I can tell, it lays in how PostgreSQL is installed under Snow Leopard. I’ve tried so many things, and the only ones that seem to work are MacPorts’ build, and Homebrew’s build. I’ve tried building from source, using the installer from EnterpriseDB, etc. — and since Homebrew and MacPorts have specialized build strings (for architecture and what-not) for Leopard and (more specifically) Snow Leopard, this builds it in the right way for psycopg2 to access it — without the nasty _PQbackendPID error. Hope this helps!

I’m not sure how well this works in virtualenv — I haven’t gotten into using them yet, although I hear daily that I should. Anybody have a good learning resource on how to use virtualenv? If somebody lets me know, that’ll help me greatly.

Now I’m off to fix this, which I’ve done too many times to count: