If there is nothing for dinner but beans, one may hunt for an onion, some pepper, salt, cilantro and sour cream to enliven the dish, but it is generally no help to pretend that the beans are really prawns or chanterelles. When the only font available is Cheltenham or Times Roman, the typographer must make the most of its virtues, limited though they may be.

-Robert Bringhurst

Is it possible for a book about typography–not a biography of its heroes or a politically connotated manifesto–to be a page-turner that the reader is loathe to set down? Apparently so. Robert Bringhurst’s The Elements of Tyopgraphic Style, Version 3.2, is so full of colorful analogies and eloquent phrasing that it’s easy to forget that the subject matter is one that is typically considered nit-picky and disproportionately impassioned.

Bringhurt’s book was recommended to me by a friend who is a copy editor. When I decided to become a technical writer, I asked his advice on copy editing. Since I already write for magazines, branching out into copy editing seemed a logical counterpart to learning technical writing for me. This book was among his recommendation, but it was nearly a year before I broke into its plastic wrapping. I was busy reading more pressing books for school, and this one was more “fun” (I know I have a different idea of “fun” than most people), so for a workaholic like me, it took back burner.

As evidenced in the quote above, this text is a specimen of creative writing, not in the sense that it is fiction, but that it is full of colorful description and poetic metaphor. After reading it, it is hardly a surprise to learn that Bringhurt is literally a poet, author of many books of poetry as well as prose. While the book is structured like a reference book–sort of a thorough style guide plus encyclopedic listings–it reads like an intricate and heartfelt story. Technical specs collide with unmitigated opinions collide with every ancient art, from mathematics to music to philosophy. Details are so dense (as they must be with this art), that the under-initiated has the feeling of drowning, but in a pleasantly temperatured river on a hot sunny day so that one hardly even minds; it just seems like the perfect day to drown.

It sounds like I’m about to give this book a rave review, but I must hold back some praise. It ended up being a little boring. Probably this is due to my overzealous determination to read it from cover to cover; it was probably not meant to be read so. As interesting as it is, it is 350 pages about typography, including names of designers and typefoundries which can be meaningful only to a few of us.

So as a reference book, then? Well, for all its pages, this book is not complete enough to be a pure reference. Fonts are examined in detail, but only the fonts which the author felt like talking about. The most remedial, such as Helvetica and Times New Roman, are passive-aggressively ignored. Fonts are organized by serif and sans serif, but a list of more detailed specs for each (aperture, axis, modulation) would have been helpful.

Alternately, the book contains too much information, not just too little. There are so many appendices it can be confusing to know which to open when. Few people will be interested in the short paragraph bios of 13 pages’ worth of designers, let alone typefoundries. And while the linguaphile in me enjoyed the “Working Alphabet” reference of every relevant character across many languages, I wonder how many people felt the same.

As with any book about design, this book is and should be a thing of beauty. It actually makes me a little sad to see how worn it is after a month or two in my messenger bag, though I know that’s supposed to be a sign of use and “love.” The inside is so crisp, however, that I still hold the pages up to my nose, expecting it to have that “new book” smell. I think this must be an effect of the paper, layout, and type combined, as all these topics are covered between its pages.

A common complaint among my classmates was that our books about design were all black and white. Bringhurst’s book breaks the cost taboo by adding a splash of red to the title and referential opening pages. The effect is striking. Kudos to the author for requesting (demanding?) this of his publisher.

Another highlight that is both design and content is the inclusion of interesting, beautifully set poetry sprinkled throughout the book to show examples of the fonts in use. It’s a delight to come across a gorgeous Yeats quote that shows the power of good typography.

Neither fully reference nor ornate prose, you get the feeling that Robert Bringhurst wrote the book he wanted to write. Through both explanation and example, he ties typography to all the classic arts. Even for someone like me who only knows the basics, it was a bright, contoured, enjoyable read. Maybe don’t go the cover-to-cover route. Just pick what looks interesting to you. There should be plenty.



I spent four–five, effectively–days last week at the Society for Technical Communicators 2012 Summit. I was a student volunteer, which meant that I got in for free in exchange for helping with registration and room monitoring. There was no way I could say no–the summit was actually happening in my own town, Chicago!

Saturday was a pre-conference event, the Madcap 2012 Roadshow. It was free admission for summit attendees, and I’d heard of Flare and knew it was something I was supposed to know about, so I decided to go. Anyways, some of my tweeps were going, so it was a good chance to meet up IRL!

I actually did understand some of it. Speaker Mike Hamilton was a rockstar of a presenter, and was fun and easy to follow.

I believe I knew the least about Flare out of everyone there, so I had to do a lot of “guessing” and fill-in-the-blanks to figure out what they were talking about at any given time. I like guessing games, though. Oh, and they gave us the most fabulous breakfast!!

The first day of the Summit, I was arriving in a flurry from my choir gig. I was also parking at the L, since that was $5 and parking at the hotel itself was $20, so I had a few blocks to scramble down. It’s funny how I wear a nice suit and leather bag but still end up running barefoot across the hotel lawn. I think I ended up making it exactly in time.

We divvied up volunteer duties. It was a little complicated for me since I was switching between both registration and room monitor jobs, so I just let them give me whatever was easiest for them. As a result, I got assigned to a lot of under-attended talks that were sometimes really good, but just didn’t have the mass appeal on paper that the more in-demand ones did.

The keynote speaker was Scott Berkun, who gave a good enough talk that I bought one of his books. Both, I felt, were enjoyable, but didn’t contain anything particularly revelatory for me personally. Maybe because I’m an artist (and yes, I am an artist as Berkun describes, much to the detriment of my lifestyle and livelihood, though I’m trying to kick the art habit), I just kind of felt like I already think the way he proposes.

It’s hard to say what else I did at the summit, because I just used my program to kill a roach.

I worked registration during one of the quieter periods, which was nice because I got to say hi to so many people, some of whom remembered me later.

I worked various sessions, which mostly meant I took a headcount and had to run out of the room if there were any problems and find someone to fix it. I actually did get called to action a few times, which was fun. It makes me feel like a hero! Not in a Superman kinda way, but firefighter or something.

If there’s one thing that I learned, it was to ALWAYS do a sound check before you start a talk. The majority of speakers had their mikes too far away from their mouths and had to be interrupted because we couldn’t hear them.

The other thing I learned is that “technical communicator” is too generous a term for most of us. Only a few of the speakers I saw had any actual public speaking skills. The ones that did were great, but they were the minority.

Maybe all the other people were “technical writers” or “documentation specialists.” But this is the Society for Technical Communicators, and if you consider yourself a “technical communicator,” you need to communicate orally. And communicating orally is only 20% words. (I’m making that statistic up by roughly averaging the estimates in the second paragraph of this.)

I was living off-campus for the Summit, as my house is a 45 minute drive from the hotel. So I missed out on all the social activities, even the ones I really wanted to go to, like the jam band and the tweet-up. But it would have meant little sleep, and I get cranky if I don’t get my beauty rest.

I’ll still be eligible to student volunteer next year in Atlanta. Hopefully I can find a place to stay so I can go! I have always wanted to go to Atlanta. I love the South (that’s where my mom is from) and my parents actually met in Atlanta, though I’ve never been. So, hope to see you all next year!

One of my greatest woes as an up-and-coming technical communicator is the hailstorm of tools and programs I’m expected to know how to use. I feel like every job application I look at, I’m pelted with a new one. Viso! Flare! Framemaker! Robohelp! I’m still getting used to Adobe Creative Suite, so it can feel overwhelming.

Those that have gone before me have suggested attending live product demo events, and one of my gurus sent me a link to the Perforce Road Trip 2012, which was coming through Chicago. I was going to be in the River North neighborhood that day anyways, so it worked out perfectly!

The slogan for Perforce is “Version Everything.” I had no idea what Perforce was. I did know what versions were. I had never heard it used as verb before, but I got the picture. I decided to be surprised, rather than figure out what the product was like beforehand.

The event was held at the Westin Chicago River North, which was a beautiful hotel. I don’t stay in fancy hotels–when I travel I usually couch surf or stay in youth hostels–so I sometimes feel pretty lost inside them. I didn’t know how to find the room, and the only people I could find to help were at the “Preferred Guests” counter, and I wasn’t a Preferred Guest–I wasn’t a guest, period! But of course, all the people who work in fancy hotels are crazy nice because that’s their job, so they helped me anyway.

I checked in and got a name tag and a swag bag containing a hardcover notebook and a set of those cardboard box speakers you can assemble. (That seemed like an odd choice, but how many pens and t-shirts that don’t fit can you really use?) I was one of the first people there so I could sit wherever I wanted, but I quickly realized that the seat I had grabbed was too far back, as I was already having trouble reading the projector screen. So I moved up to the front. Even then there were things I couldn’t read. Projectors are designed to be used in the dark. If you’re going to use them with the lights on, you need to adjust accordingly.

Ironically, the guys behind me and I struck up a conversation where they were telling me about all these interns they were interviewing. Turns out I had applied for an internship for their company, but no one had ever gotten back to me. It was a completely different department, though, so they were off the hook.

I was one of the only women there, so there was no line for the bathroom!

So there were basically four lectures and two snack times.

The first lecture, “Managing the Flood of Content,” was my favorite. As a writer who does a lot of remote collaborating, the problem of figuring out which version of a document is the latest, or the “correct” version, and of knowing who changed what when, is far too familiar. And it’s something you can manage, but everyone has to be on the same page. Even if you’re just working by yourself, it’s too easy to not rename a new or old version of a file and assume everything will be fine.

The presentation featured some robo-cartoons, like XtraNormal or something, that were actually pretty funny. The line “Didn’t you get my file, ‘Project Version Two April 2012 Final 06 Really Final’?” (paraphrasing) hit home. Mr. Seiwald also made an interesting point about the problems in sharing documents via email. You end up with too many copies of the same document–all with the same file name–and it’s hard to know which have been edited. I’ve been hassled lately by the separate copies of my colleagues’ and my documents that are auto-saved in my mail downloads folder. My only complaint about the first lecture is that I understood what the product was for, but didn’t have a clear picture of how it worked. Some screenshots or demo videos would have helped.

The second lecture I had more trouble following. It was clearly geared towards developers, so as a documentation specialist I didn’t really relate to it.

Then we had a break with snacks and demos. I was hoping “demos” would mean we would get to try the product, but it was really just two stations of people showing examples of how it worked. I got one of them to let me try it anyway! I made a new branch and made an edit and saw how to merge it with another branch. That helped me a lot more than just watching.

The third lecture was even worse for me than the second. It was all about development, so there was nothing in it that spoke to me. If I hadn’t been sitting in the front row I probably would have ended up playing on my phone.

The final lecture was both interesting and over my head at the same time. It was two people who work for the New York Stock Exchange/Euronext explaining how they used the product and how helpful it was. Now, this kind of company is obviously an extreme case, which is what made it so interesting. Just the thought of all that money/all those transactions/all those countries. What a logistical nightmare, but at the same time, imagine the whole world depending on your systems. So most of the details went over my head, but I understood the larger concepts of why a product like this is important. Adam Breashears, who had a fabulous bass voice, summed it up best when he said, “If you don’t use a system like this, at some point you’re going to lose your job.” I can see that.

So then there was a reception with an open bar, where I talked to the guys who’d sat behind me and some of their colleagues, which was fun. It seemed like almost everyone there was a developer, so it was more like being around nerds than around business people. (I was all dressed up like a business person, but that’s because I need a job and you never know when you might meet a potential boss!)

Anyways, Perforce seems like a really great tool, but I don’t feel that it applies to me in my current position as a freelancer and student. It’s meant for people working on teams. I might work on a “team” with a client or a classmate, but I can’t expect every person I work with to download Perforce so they can work with me. If I were working for a big company, I would definitely want to use a tool like this.

Now that I’ve covered all six output methods, let’s do a quick review.

Epub to Adobe Digital Editions had an issue with the cover appearing off-center and cut off. It did well on text formatting, with everything working correctly except the two more obscure fonts. It had an issue with unordered-within-ordered nested lists. As long as the window was sized large enough, all the image requests came out as planned. Links worked fine, except the link within the text caused the anchor ID to appear as a hyperlink.

Epub to Calibre

Calibre passed with flying colors. It even had three out of the four fonts (no output device had the fourth font). No complaints.

Epub to iBooks

iBooks did well with the text formatting, but only had two out of the four fonts. The text-image alignments only worked when they both fit on the screen, and since there was no way to resize the screen, that wasn’t often. The iPhone app had a pretty serious problem with floating images, which the iPad app did not.

Mobi to Kindle for computer

The “Intro” link on Table of Contents took you to the cover, not the intro heading. Text did well, and it had three out of the four fonts (none had all four). Everything else ran smoothly. Excellent work.

Mobi to Kindle app (iPad and iPhone)

Table of contents is absent. All lines are indented (not planned). No typeface changes worked at all, and font size changes were not to scale. Weird problem with the ordered-within-unordered list. None of the image alignment worked–as with iBooks, this is probably because of the inability to resize the screen. There was also no border on the bordered image. What a mess! At least the link did not highlight the anchor as in some of the other outputs.

Mobi to Kindle device

Again, the table of contents is absent. The text mostly mirrored that on the iPad/iPhone app: all indented, no typeface changes, font size changes but not to the sizes requested. The “colored” text appeared in greyscale, which is fair since this is not a colored screen. There was a problem with ordered-within-unordered lists, but not as drastic as the problem with the app. No formatting with the images worked. Background colors did not appear at all. Like the app, the link within the text did not cause the anchor to hyperlink, which was a plus. Otherwise, though, lots of problems here.

So to sum up, by my findings, in terms of best to worst handling of formatting:

1. Calibre

2. Kindle for computer

3. Adobe Digital Editions

4. iBooks

5. Kindle app

6. Kindle device

Of course, this wasn’t meant to be a contest, but rather a resource for ebook authors and publishers. I wanted you to be able to see what works where, and what doesn’t. If you’re only composing for Calibre, great, do what you want! But if you intend to sell your book to the public, you don’t know what kind of device it could end up on. Have a look though these pages to see what can go wrong, so you’ll know what formatting to avoid as you submit your epub or mobi.




I’ve been taking an ebooks class this semester, and for my final project I decided to do a little formatting experiment. We learned all kinds of formatting and CSS in class, but a lot of what we learned didn’t work on every form of output. The same epub file might come out differently in Adobe Digital Editions versus iBooks. So I created a mini-ebook in both epub and mobi, with all kinds of formatting “issues” I could think of–colors, lists, images–and took screenshots of how they came out in different programs and devices.

So far, I covered epub to Adobe Digital Editions, epub to Calibre, epub to iBooks, mobi to Kindle (computer), and mobi to Kindle app (iPad and iPhone). In this post, I’m covering mobi to the Kindle device itself.

For starters, you can download the mobi here. But it is possible to get the gist of the experiment without downloading it.

Let’s see how the mobi displayed on the Kindle device (Kindle Keyboard 3G).


The cover came out fine, but the table of contents was once again unavailable.


The colored text comes out greyscaled, which is really the best that can be hoped for with a black-and-white screen. The centering and right-aligning works. As with the Kindle app, the text is always indented but justified. None of the fonts worked, and as with the app, the altered font sizes were bigger and smaller in turn, but not to scale.


As you can see above, the regular lists come out fine.

Again we have a problem with the first item in the ordered-within-unordered nested list. But here we just have an extra bullet, where in the app we had a five-digit number inexplicably replacing the 1. So this is an improvement.


I’m just going to include one shot of the images, to spare you the repetition.

Each time the image appeared, it took up the whole screen. So alignment and floating were moot. I will point out that the image that was supposed to have the border did not.

Links and Backgrounds

Both links worked, and without causing the anchor to hyperlink. Neither background had any effect.

That’s the last output method I’ll be testing for this project, so all that’s left is to summarize.

I’ve been taking an ebooks class this semester, and for my final project I decided to do a little formatting experiment. We learned all kinds of formatting and CSS in class, but a lot of what we learned didn’t work on every form of output. The same epub file might come out differently in Adobe Digital Editions versus iBooks. So I created a mini-ebook in both epub and mobi, with all kinds of formatting “issues” I could think of–colors, lists, images–and took screenshots of how they came out in different programs and devices.

So far, I covered epub to Adobe Digital Editions, epub to Calibre, epub to iBooks, and mobi to Kindle (computer). In this post, I’m covering mobi to the Kindle app for iPad and iPhone.

For starters, you can download the mobi here. But it is possible to get the gist of the experiment without downloading it.

Let’s see how the mobi displayed in Kindle’s app for iPad.


No problem with cover display, on page or in thumbnail (not shown). BUT, for some reason, the table of contents doesn’t work on this app, even though it worked on the desktop app. When I select the Table of Contents icon, I get a greyed out “Table of Contents (Not available for this title).”


Lots of fail here. The color, centering, and right-aligning worked. As for justifying, it looks to me like all the text is justified. But Kindle puts a hefty indent at the beginning of each line, whether you want it or not. None of the typeface changes worked. The font sizes are bigger and smaller respectively, but not to the extreme that they should be.


Everything is fine ’til we get to the ordered-within-unordered list at the bottom. 65535 instead of 1? That’s an odd mistake, at a spot where none of the other apps have had a problem. On the plus side, we avoid the anchor-as-hyperlink that some of the other apps created.


So basically, besides the existence of an image, none of this worked. We have the same issue as in the other apps with the middle- and top-alignment not working if the window is too small, and as in iBooks, we can’t resize the window to fix it. I took a picture of what happens when you turn the screen on its side:

As with iBooks, you get two columns instead of one big one, and some really extreme justification. Though I should point out that, while you can’t resize the window, you can zoom in on the images themselves.

No border and no floating image. Tisk tisk, Kindle for iPad!

Links and Backgrounds

Both links work, though the link to the website actually opens in Kindle, and you have to press another button if you want to open it in Safari.

This is the first app we’ve seen where the background colors touch, instead of a blank line in between. Looks cool.

Generally though, a lot of problems here, which is weird since the Kindle for Mac had almost no problems. So be aware as you are creating your mobi: just because it displays properly on your desktop does not mean it will translate correctly onto another device!

Now, here’s the real surprise: When I checked the mobi against the Kindle app for iPhone, it behaved EXACTLY as it did on Kindle for iPad! Not even iBooks pulled off that kind of consistency. Just a little odd, considering how much of a gap there was between Kindle for computer and Kindle for iPad/iPhone.

Next, let’s check out mobi to the Kindle device itself.

I’ve been taking an ebooks class this semester, and for my final project I decided to do a little formatting experiment. We learned all kinds of formatting and CSS in class, but a lot of what we learned didn’t work on every form of output. The same epub file might come out differently in Adobe Digital Editions versus iBooks. So I created a mini-ebook in both epub and mobi, with all kinds of formatting “issues” I could think of–colors, lists, images–and took screenshots of how they came out in different programs and devices.

So far, I covered epub to Adobe Digital Editions, epub to Calibre, and epub to iBooks (iPad). In this post, I’m covering mobi to the desktop Kindle app (for Mac).

For starters, you can download the mobi here.But it is possible to get the gist of the experiment without downloading it.

Let’s see how the mobi displayed in Kindle’s app for Mac.


No problems on page or thumbnail (not shown). The only weird thing is that clicking “Intro” on the Table of Contents takes you to the cover, not the heading ‘Intro” like it’s supposed to.


Everything worked except the most obscure font, Thornburi.


As you can see above, we avoided that awkward problem of the ID anchor (which is on the line “Here is an ordered list”) appear as a hyperlink that doesn’t go anywhere.

All the lists check out just fine!


Everything worked fine. As with the other desktop apps, the top- and middle-aligned images only displayed as such when the window was sized widely enough; otherwise they appeared below the text.


Links both work.


Looks good!

Good job, Kindle for Mac! Let’s see what happens on Kindle for iPad and iPhone