I just found what looks to be a rather decent EPUB reader add-on for Firefox, EPUBReader. I’ve installed it on my desktop already and tested some EPUBs and at first blush it looks like a decent reading experience. I don’t mind checking my EPUBs in Calibre with the default E-Book Viewer, but this looks better IMO for casual reading.

I’m also in the middle of adding Firefox mobile to my N900 (again) and EPUBReader as well. Which incidentally is how I found it – searching for possible alternatives to FBReader for Maemo.

Ever since I started my writing sabbatical a few months ago I’ve been having fun estimating the total word counts for the first drafts of what I’ve been working on. I’ve been using a pretty simple formula – it goes back to grade school and plain old division really.

currentWordCount / ( currentLineInOutline / totalLinesInOutline ) = estimatedTotalWordCount

Basically it’s just this:

I find how far I’ve gone in my outline and look for the specific line number and divide that by the total number of lines in the outline to get the percentage completed so far. (My outlines are all point form, indented code style semi-sentences, so line-length doesn’t really matter much.) Then I take the current word count of my story and divide it by the above.

So really I’m just dividing my current word count by the percentage of the outline done. No rocket science there.

But what amazes me is that it’s been surprisingly consistent since I started using it. It was ultimately off by about 500 words for the first story I wrote, which capped out at just under 12,000. And so far it’s consistently estimated my current story to cap out at between 19,000 to 21,000 words. I’m currently at 16,000 words.

Yay, maths!

I’ve been quite happily using Git in my writing workflow for a few months now. But I wanted to be able to add a little more information into my commit messages.

Inspired a little by Cory Doctorow’s post, ‘Flashbake: Free version-control for writers using git’, about his use of scripts to add extra info to his Git commits, I decided to hack together my own brief post commit hook.

The first part of this basic bash script is a simple word count total on all changed files in that commit. I use a daily word quota when I write. So being able to track how much I have written since the previous commit(s) is been very useful for me.

The second part of the script outputs the song title and artist name (from the id3 tags) if there is a song playing at the time of the commit. This one is more for my own amusement, since I listen to music frequently while working. I restricted the programs to check to clementine and audacious since I typically only listen to music in those apps. (This bit was almost wholesale lifted from a script in this Ubuntuforums thread.)

All of this is added onto the end of the message in the git commit call.

#!/bin/sh
 
for i in $(git diff --cached --name-only)
	do
		count=$(wc -w $i)
		echo "$count" >> "$1"
	done
 
apps="clementine audacious"
 
for app in $apps
	do
	  pat="([^\w-]$app)"
	  if ps ux | grep -P $pat | grep -vq grep; then
		 file=`lsof -F n -c "$app" | grep -i "^.*\.mp3$" | sed 's/^n//g'`
		 if [ ! -z "$file" ]; then
		   title=`id3info "$file" | grep "Title" | sed 's/^===.*[:].//g'`
		   perf=`id3info "$file" | grep "performer" | sed 's/^===.*[:].//g'`
		   if [ -z "$title" ] && [ -z "$perf" ]; then
		     echo "Now playing: No MP3 info" >> "$1"
		   else
		     echo "Now playing:" \'"$title"\' "by" "$perf" >> "$1"
		   fi
		 fi
	  fi
	done

At the start of my writing sabbatical a few months ago, I realised that I needed to preemptively address the issue of file versioning and change control before I had written too much. That lead me to examine how I was going to work and what programs I was going to use to make my life easier and more secure.

The resultant toolset and workflow I’ve cobbled together is not that unique really. It’s not that different from any normal developer who codes primarily on a typical Linux box. The main reason I’m outlining it here in a blog post is in case anyone other writers out there perhaps find this information useful.

This isn’t exactly a ‘Git for Writers’ post, but it is inspired by that basic idea.

I’m going to outline the programs and processes I use during the different phases of my writing workflow, with comments and descriptions where necessary.

Writing Software (Word Processing)

gedit — My primary computer runs Xubuntu and my main editing app is gedit with a few useful plugins:

• Document Statistics (installed by default) — useful for word count
• Spell Checker (installed by default) — don’t leave home without one
• Regex Search and Replace — when Search and Replace is not powerful enough
• TabSwitch — because I hate not being able to Ctrl+Tab to other tabs

notepad++ — When I have to work on a Windows box I pretty much just use notepad++.

LibreOffice — I really only use LibreOffice for creating DOC and PDF files.

This may be reversed for many authors but I write in basic text editors and then copy/paste my documents into LibreOffice when I need a .doc file.

The first reason I use a vanilla text editor is plain, old comfort. gedit has all the features and shortcuts I require, and I can work in it quite quickly.

I also don’t require any of the typical text formatting that a word processing program like LibreOffice can offer during my writing phase. Most of the text formatting I do comes during the output phase of my workflow, since I have to format documents not only for DOC and PDF but also EPUB and MOBI.

Authoring in plain text also makes file versioning and change control a no-brainer.

File Versioning (Archives and Backups)

Git

Versioning offers an easy solution to managing progressive versions of any file, as well as robust archives and backups. And since I’m used to versioning from my development background, opting to go this route was an obvious choice for me.

After considering my options, I went with Git. I hadn’t used Git before but its features and ease of use ended up being a natural fit for my workflow. If I had to work primarily on a Windows box and absolutely needed a GUI (instead of the command line) I probably would have went with SVN and TortoiseSVN which I have used before numerous times.

Git Instances

Besides running a local install of Git on my Xubuntu box, I also have a private Git repository hosted in a subdomain on my production server (on Dreamhost) which I can access easily using SSH. Both instances are running the same version of Git as well.

The beauty of this setup, to my mind, is that I immediately have two separate repos of all my work. My main working repo is on my laptop, and the server repo doubles as a backup as well as the master repo access point for when I sometimes have to work on a different computer.

For those times when I find myself working on a Windows box I use the portable version of Git from mysysgit.

Git Commands

I basically only use five commands when I am writing.

git status — to check if any files have been modified
wc -c filename — not a git command, of course, but lets me know the wordcount of any file (this is useful to me since I set myself a quota of words to write per day)
git commit -a -m "your message here" — commits all modified files to the Git repo
git push origin master — pushes the local repo changes to the server repo
git pull origin master — pulls the remote repo changes to your local repo

The sixth I use sometimes is:

git log -n 1 — displays the last log entry in the command line, for when I haven’t pushed my most recent commits to my server or I’m too lazy to bring up Gitweb

Gitweb

The subdomain on my live server is also running an instance of Gitweb. I had to setup gitweb myself since it’s not installed by default on Dreamhost, but it was relatively trivial to do so. I followed the basic outline in “Step 4. Setup GitWeb (optional)” of this excellent blog post to get it up and running.

I actually end up using Gitweb quite frequently to get an easy to read display of my Git log. It also gives me easy access to my files in a browser if I need to show someone a snippet of what I’m working on.

Because the raw file view in Gitweb does not line wrap by default, I also use the Toggle Word Wrap add-on in Firefox when I want to read a file. It basically puts <pre> tags around plain text, which is great.

Git Commit Messages

One of the many useful things about versioning is the ability to include a message when committing any files. In addition to whatever message I include with a commit, I have a simple commit hook which outputs the word count of any file that’s been changed, and also includes the title and artist name if I’m playing any music at the time. I’m no bash jockey but I was able to cobble together a basic script that satisfied my needs. Check out this blog post to see the entire script.

Ebooks and Ebook Formatting

I am specifically writing with ebooks as a default file format in mind. Once my current stories are ready to go I plan to self-publish them online (on Amazon, Smashwords, and other sites) and perhaps even through POD (print on demand) services. So, anything I can do to make converting my text files into well-formatted ebooks helps reduce my time and effort. I love monkeying around with code, but ultimately I want to spend most of my time writing.

Using a combination of ‘Find and Replace’ and regular expressions, and a few other tricks, I can relatively easily convert my plain text files into ebooks (HTML and CSS) or a DOC file.

For me this mostly involves converting italics, dashes, ellipses and quotes, adding indents or altering whitespace, etc. to suit the desired file format. (I plan to make a more detailed post on my formatting process soon.)

I also wouldn’t be able to create and convert ebook formats anywhere near as easily or quickly if it wasn’t for Calibre. It is a superb program and I am immensely grateful that it exists.

Ebooks and Self-Publishing

And for anyone interested in self-publishing online, Joe Konrath’s blog, ‘A Newbie’s Guide to Publishing‘ is highly recommended.