When I started Prac­ti­cal Ty­pog­ra­phy, my key ques­tion was this: how could I adapt the ma­te­r­ial from my pa­per­back Ty­pog­ra­phy for Lawyers into a dig­i­tal ver­sion, while keep­ing it a peace­ful, book-like read­ing experience?

At the time, my most re­cent ad­ven­ture in e-books had been un­sat­is­fy­ing. When I re­leased the first edi­tion of Ty­pog­ra­phy for Lawyers, read­ers begged for a Kin­dle ver­sion. So I made one. It was aw­ful. Be­cause the Kin­dle is aw­ful. From Ama­zon’s per­spec­tive, this is prob­a­bly a fea­ture. From mine, it was a bug. Why do we need a ty­po­graph­i­cally ru­inous ver­sion of a book mak­ing the case for good ty­pog­ra­phy? When the time came to make a sec­ond edi­tion, I pulled the plug.

It seemed to me then—and even more so to­day, now that mak­ers of e-book read­ers have had years to make im­prove­ments—that these de­vices pri­or­i­tized con­ve­nience over all else. I pre­dict they’ll never have the ty­po­graphic ca­pa­bil­i­ties or stan­dards of print publishing.

I don’t mean that as a put-down. In pub­lish­ing, con­ve­nience some­times should win, and does win. In The Bil­lion­aire’s Type­writer, I re­flect on how the orig­i­nal man­ual type­writer of­fered writ­ers con­ve­nience at the cost of ty­po­graphic free­dom. Com­pared to the pro­duc­tiv­ity of pen­cil and pa­per, it was a wor­thy trade-off.

Still, at the time, I was dispir­ited. Wealthy tech com­pa­nies were tak­ing over the book mar­ket in a man­ner that made con­ve­nience the #1 con­sid­er­a­tion. Tied for last place: every­thing else.

For in­stance, had it been worth Ap­ple’s time to pro­vide nice e-book de­vel­oper tools for the iPad, those tools would’ve ex­isted. In­stead, Ap­ple pro­vided de­vel­oper tools for mak­ing flashy games, be­cause these were more likely to sell iPads. In turn, it’s no sur­prise that these games have taken over the iPad economy.

Ei­ther I had to give up on the idea of a well de­signed e-book. Or find a way around the roadblock.

True, PDF sup­ports a lot of ty­po­graphic & de­sign flex­i­bil­ity. But PDF is a pa­per sim­u­la­tor. It’s great for mak­ing dig­i­tal ver­sions of works orig­i­nally de­signed for print. For na­tively dig­i­tal works, it im­poses un­nec­es­sary com­plex­ity and limitations.

For a longer an­swer, see why there’s no e-book or PDF.

Hav­ing elim­i­nated the other op­tions, I started think­ing about pub­lish­ing Prac­ti­cal Ty­pog­ra­phy on the web.

In prin­ci­ple, I wasn’t op­posed. Af­ter all, Ty­pog­ra­phy for Lawyers it­self had started in 2008 as a web-based book, which is what led to the pa­per­back deal. I had made that ver­sion in Word­Press. Word­Press made ba­sic pub­lish­ing tasks easy, but am­bi­tious lay­outs re­mained difficult.

By the time I was think­ing about Prac­ti­cal Ty­pog­ra­phy, there had been valu­able de­vel­op­ments in web de­sign—most no­tably browser sup­port for web­fonts. It oc­curred to me that what I wanted was not a sim­ple but reg­i­mented sys­tem like Word­Press—it just wouldn’t let me work with the so­phis­ti­ca­tion and de­tail I needed. In­stead, I wanted a flex­i­ble tool for de­scrib­ing com­plex HTML & CSS lay­outs with sim­pler, high-level notation.

In short: I wanted my own pro­gram­ming language.

In­vent­ing a lan­guage to solve a prob­lem is an es­tab­lished tech­nique called lan­guage-ori­ented pro­gram­ming. The lan­guage that re­sults is some­times known as a do­main-spe­cific lan­guage (or DSL).

I didn’t know this at the time, how­ever. So, in typ­i­cal fash­ion, I just blun­dered into the project with op­ti­mism. Let’s see what hap­pens! I de­signed my no­ta­tion—which in­volved pro­gram­ming com­mands em­bed­ded in plain text—and pro­to­typed an in­ter­preter in Python. The lan­guage worked—barely. It was rem­i­nis­cent of the first act of Iron Man, where Tony Stark, trapped in a cave, builds his first fly­ing suit out of toaster parts and car bat­ter­ies. Not beau­ti­ful. But bet­ter than the alternative.

My Python skills, how­ever, were not suf­fi­cient to get me where I needed to go. That’s when some in­ter­net spelunk­ing led me to Racket, a pro­gram­ming lan­guage that had a text-based di­alect called Scrib­ble. Orig­i­nally, I’d only in­tended to use Scrib­ble to add a few fea­tures to my lan­guage. But as I stud­ied it, I re­al­ized that the Racket guys had gone down the path I was trav­el­ing, and al­ready sorted out the thorni­est problems.

More­over, I learned that Scrib­ble it­self was made pos­si­ble by Racket’s ori­en­ta­tion to­ward lan­guage-ori­ented pro­gram­ming. Then the light bulb went on: I shouldn’t be us­ing Python at all. I should rewrite the whole project in Racket.

So I did. I named the re­sult­ing lan­guage Pollen. I used Pollen to make the first ver­sion of Prac­ti­cal Ty­pog­ra­phy. I’ve used it nearly every day since, on every­thing I pub­lish on the web.

The dif­fer­ence be­tween Word­Press and Pollen?

• Word­Press re­lies on a cloud-based in­ter­face—you log into a re­mote web­site and make your ed­its through a web in­ter­face. Af­ter you click a but­ton, the site is updated.

• Pollen, by con­trast, adopts the id­ioms of pro­gram­ming. There is no cloud in­ter­face. A web­site is a col­lec­tion of source files in a lo­cal di­rec­tory (writ­ten in the Pollen lan­guage). To re­fresh the site, you re­com­pile these source files to pro­duce out­put files. Then you copy these out­put files to your web server.

If this sounds more com­pli­cated, it is, a lit­tle. But the ben­e­fit of adopt­ing a pro­gram­ming model is that within a Pollen project, I can use pro­gram­ming tools. For in­stance, I can con­sol­i­date com­pli­cated for­mat­ting tasks into func­tions that au­to­mat­i­cally han­dle them. Whereas in Word­Press, I’d have to do these by hand, which in many cases would be im­prac­ti­cal. So though the floor is higher, so is the ceil­ing. With Pollen, I can ac­com­plish things that would oth­er­wise be too expensive.

I’m sat­is­fied with web pub­lish­ing. The web of­fers plenty of ty­po­graphic and lay­out ca­pa­bil­ity. Cer­tainly more than any e-book for­mat, and on par with PDF.

But to fully har­ness this ca­pa­bil­ity, I had to cre­ate bet­ter tools. Writ­ing Pollen wasn’t cheap. But over its first five years, it’s al­ready re­paid my investment.

Read­ers have oc­ca­sion­ally asked if I’ll ever pub­lish Prac­ti­cal Ty­pog­ra­phy as a pa­per­back. Early on, I said yes. These days, no. As a reader, I pre­fer printed books. As a ty­pog­ra­pher, I miss work­ing on print lay­outs. Even­tu­ally I’ll find other some pre­text for mak­ing printed things.

But as a self-pub­lished writer, I’ve come to pre­fer the plas­tic­ity, im­me­di­acy, and reach of the web. At this point, a printed ver­sion of Prac­ti­cal Ty­pog­ra­phy strikes me as a di­lu­tion of the con­cept. That is not a re­sult I would’ve pre­dicted when I started this project.