I had thought my print interior for One Woke Up was ready to go, until I suddenly realized I was forgetting one very important thing: Ligatures. My problem is that I love typography, the elegant art of layout and typesetting that can make books beautiful on the inside. In spite of that love I know very little about it compared to the pros. I do, however, know just enough to be dangerous—to myself.
A ligature is a combination of letters like “fi” or “ffi” that gets grouped together as one font character because it looks better than the original individual characters. Some fonts have support for these, and some programs can detect them. OpenOffice Writer, which I have been using for my print layout, is not one of the programs that detects this properly. Or perhaps it is; Google is muddled on the subject, but the behavior appears to vary by system. I’ve seen Linux users talking about wanting to turn ligatures off, whereas I can’t tell how to turn them on. In any case, some combination of the font I’m using and the program I’m using isn’t handling this on its own.
I already wrote a macro to help do final conversion that solves some typographical issues. For instance I’ve mentioned that I wanted something to handle scene breaks elegantly, which I have now. Extending my macro seemed like the best solution across the board. That’s where I ran smack into the Java monster.
OpenOffice’s macro language is built on a Java core. It is capable of telling me if certain glyphs are in a font. This is kind of important if you’re about to convert “ff” to the right ligature and need to know if the font even has such a ligature. However, the font object is a special thing, and needs to be grabbed from something that’s device-sensitive (i.e., it wants to know if this is relevant to a monitor or a printer or what have you, and what its characteristics are). Meanwhile the place I’ve found the “ff” I want to replace is in a simple search, and I have some objects to work with like the document, the range of text I’ve found, etc. I can tell the name of the font and its styles, but that’s not the font object. My problem is conceptually simple: I need to know how to go from having a font name and some style info to having the font object itself.
The Java monster is one of the three horrible flaws in that language. Java is beautifully elegant but for those flaws, and this one comes down to humans: Java has a tradition of having a fairly convoluted library built on top of such a simple language. Design patterns, while useful, are taken a little too seriously by Javaphiles and as such you need a hundred different classes to perform a simple action. Displaying an image from a file means you’ll need factories, observers, producers, streams, and all kinds of other stuff. This is all fine if you’re given a clear reference for the classes you’ll be working with, but OpenOffice’s online help isn’t laid out that way. That means to get from point A (knowing the name and style of the font) to point B (having the system look at the font’s file and tell you if the characters you want are in it), you have to follow breadcrumbs in the documentation, striking out on trails across a minefield of cross-references and hoping—with no compass but your own experience—that you’ll find one place where the trails from both ends meet.
I have not found that place. So if I want to have ligatures in my book, not only do I have to create a macro, but I’ll have to hard-code it to tell it which fonts (and/or styles, since italics work differently) support which ligatures. Hard-coding is either a quick fix or a last resort; programmers hate having to do it unless it’s temporary. Java is built around a philosophy of always following best practices, even when that means living with its three horrible flaws. Yet that philosophy led me to the conclusion that the only way to do what I want is to abandon best practices, and hard-code it. So somewhere, my failure to slay this beast and the awful hack I’m left with as a workaround means that another programmer—who got overly invested in the idea behind Java’s crazy complex libraries—is crying.