sPageSlug = blog
sPageTitle = easily amused
header:139:aPageArgs:page_title = easily amused
header:140:aPageArgs:section_title =
functions-johndberry:262:aPageArgs:page_title = easily amused
functions-johndberry:298:sPageTitle = easily amused
functions-johndberry:359:sPageTitle = easilyamused

easilyamused |

Archive for the category ‘editorial design’

What is needed

Published

Books are digital. This is not, strictly speaking, true; but it’s about to be, with a few honorable exceptions. Already today, pretty much all commercial books are produced digitally, although the end product is a physical one: ink printed on paper, then bound and marketed and sold. Already, the selling may be done as often online as in a bookstore. Already, the same books are being issued more and more in electronic form – even if, as yet, the e-books are mostly very shoddy in conception and execution.

But that will change. In order for it to change in a worthwhile way, we have to spell out just what form these books ought to take.

So what’s needed? How do we make good e-books? What should a good tool for designing and creating e-books look like and do? What should the result – the e-book itself – be capable of? And what should the experience of reading an e-book be like?

Last question first. If it’s immersive reading – a story or narrative of some kind – then you, as the reader, should be able to lose yourself in the book without thinking about what it looks like or how it’s presented. This has always been true for printed books, and it’s equally true for e-books.

But e-books present a challenge that printed books do not: the page isn’t fixed and final. At the very least, the reader will be able to make the font bigger or smaller at will, which forces text to reflow and the relative size of the screen “page” to change. That’s the minimum, and it’s a fair bet already today. But the reader many read the same book on several different devices: a phone, a laptop, a tablet, a specialized e-reader, or even the screen of a desktop computer.

For a real system of flexible layout in e-books and e-periodicals that might be viewed on any number of different screens at different times, what’s needed is a rules-based system of adaptive layout. I like to think of this as “page H&J”: the same kind of rules-based decision-making on how to arrange the elements on a page as normal H&J uses to determine line endings.

The requirements for this are easy to describe – maybe not so easy to implement. We need both design & production tools and the reading software & hardware that the result will be displayed on.

A constraints-based system of adaptive layout

The interesting problems always come when you have two requirements that can’t both be met at the same time. (For example: this picture is supposed to stay next to that column of text, but the screen is so small that there isn’t room for both. What to do?) That’s when you need a well-thought-out hierarchy of rules to tell the system which requirement takes precedence. It can get quite complicated. And the rules might be quite different for, say, a novel, a textbook on statistics, or an illustrated travel guide.

OpenType layout support. This means support for the OpenType features that are built into fonts. There are quite a few possible features, and you might not think of them as “layout”; they affect the layout, of course, in small ways (what John Hudson has called “character-level layout”), but they’re basically typographic. Common OpenType layout features include different styles of numerals (lining or oldstyle, tabular or proportional), kerning, tracking, ligatures, small-caps, contextual alternates, and the infinitely malleable “stylistic sets.” In complex scripts like Arabic, Thai, or Devanagari, there are OpenType features that are essential to composing the characters correctly. None of these features are things that a reader has to think about, or ought to, but the book designer should be able to program them into the book so that they’re used automatically.

Grid-based layout. It seems very obvious that the layout grid, which was developed as a tool for designing printed books, is the logical way to think about a computer screen. But it hasn’t been used as much as you’d imagine. Now that we’re designing for screens of varying sizes and shapes, using a grid as the basis of positioning elements on the screen makes it possible to position them appropriately on different screens. The grid units need to be small enough and flexible enough to use with small text type, where slight adjustments of position make a world of difference in readability.

Media query. This is the name used for the question that a program sends to the device: What kind of device are you? What is the resolution of your screen? How big is that screen? What kind of rendering system does it use for text? With that information, the program can decide how to lay out the page for that screen. (Of course, the device has to give back an accurate answer.)

Keep & break controls. These are rules for determining what elements have to stay together and what elements can be broken apart, as the page is laid out. This means being able to insist that, say, a subhead must stay with the following paragraph on the page (keep); if there isn’t room, then they’ll both get moved to the next page. It also means that you could specify that it’s OK to break that paragraph at the bottom of the page (break), as long as at least two lines stay with the subhead.

Element query. I’ve made up this term, but it’s equivalent to media query on a page level. The various elements that interact on a page – paragraphs, columns, images, headings, notes, captions, whatever – need a way of knowing what other elements are on the page, and what constraints govern them.

H&J. That stands for “hyphenation and justification,” which is what a typesetting program does to determine where to put the break at the end of a line, and whether and how to hyphenate any incomplete words. Without hyphenation, you can’t have justified margins (well, you can, but the text will be hard to read, because it will be full of gaping holes between words – or, even more distracting, extra spaces between letters). Even unjustified text needs hyphenation some of the time, though it’s more forgiving. When a reader increases the size of the font, it effectively makes the lines shorter; if the text is justified, those gaps will get bigger and more frequent. But there are rules for deciding where and how to break the line, and a proper H&J system (such as the one built into InDesign) is quite sophisticated. That’s exactly what we need built into e-book readers.

In digital typesetting systems, the rules of H&J determine which words should be included on a line, which words should be run down to the next line, and whether it’s OK to break a word at the end of the line – and if so, where. A system like InDesign’s paragraph composer can do this in the context of the whole paragraph, not just that one line. A human typesetter makes these decisions while composing the page, but when the font or size might be changed at any moment by the reader, these decisions need to be built into the software. In “page H&J,” where the size and orientation of the page itself might change, the whole process of page layout needs to be intelligent and flexible.

Up until now, in the digital work flow, the software’s composition engine has been used in the creation of the published document; the human reader is reading a static page. But now, with flexible layout and multiple reading devices, the composition engine needs to be built into the reading device, because that’s where the final page composition is going to take place.

It’s easy to create a document with static pages that are designed specifically for a particular output device – a Kindle 3, for instance, with its 6-inch e-ink screen, or a 10-inch iPad. I’ve done it myself in InDesign and turned the result into a targeted PDF. But if that’s your model, and you want to target more than one device, you’ll have to produce a new set of static pages for each different screen size and each different device. Wouldn’t it be better to have a flexible system for intelligently and elegantly adapting to the size, resolution, and rendering methods of any device at all?

[Photo: a 17th-century Mexican handbook, about the size of a hand-held device, from the collection of the Biblioteca Palafoxiana, displayed during Typ09 in Mexico City. With ink show-through from the back of the page, which will probably not be a feature of e-books.]

Showing backbone

Published

The Print Regional Design Annual hove into sight the other day, joining the stack of recent graphic-design and typography magazines: Metropolis, Eye, Typo, and the new one, Codex. The Print annual was a particularly fat example, but then you’d expect it to be. What distinguishes all of these disparate magazines, however, besides interesting content, is their binding: every one of them has a flat spine.

What’s the point of this? To look at a set of issues on the shelf, after the fact? If a magazine contains enough pages, of course, you have no choice; it must be perfect-bound (the pages trimmed and glued into a spine), since saddle-stitching (folding the sheets and stapling in the middle) is only practical for a relatively thin publication. But it seems as though most magazines these days (not just graphic-design magazines) are bound so they have a flat spine, no matter how thin the issue itself may be. I even got an unsolicited men’s-clothing catalog last week, all of 68 pages, that was bound into a spine, for no apparent reason.

The problem with perfect-binding a magazine is that it won’t lie flat. Nor can you fold it open to read one page at a time, for convenience in a crowded space (or simply to keep the pages less floppy). The spine creates a gutter, which neither editorial designers nor designers of ads for those pages ever seem to take into consideration; on the inner edge, both images and text curve into the gutter and get lost. It’s possible to design with that in mind, but how often have you seen it done?

Print is a perfect example of the real advantage of a glued spine to the publisher of a graphic-design magazine: it makes it very easy to bind in inserts from paper companies who want to show off their wares to potential customers. This isn’t new; the very first issue of Print, in June 1940, included paper samples to accompany an article on the design of wallpaper, and subsequent issues had bound-in samples from printers and paper manufacturers. Today, Print and other popular design magazines like How are thick with this kind of insert. These stiff or thick or off-size pages may serve a function, as illustration or advertising, but they make it impossible for a reader to flip through the pages – one of the most common ways of reading or browsing any printed publication.

The roadblocks along the path through a magazine rarely come at logical stopping or starting points in the magazine’s content. Very few magazines these days maintain an “editorial well” that’s separate from the advertising, and converging trends in editorial and commercial design make it hard to tell the content from the ads. That’s hardly a new trend, but it’s reinforced by the random-seeming intrusions of stiff-papered inserts.

The current popularity of spines on magazines seems part of a dismissive approach that looks at the magazine (or a book, for that matter) as a physical object to be sold, without giving any thought to how that object will be used. There are exceptions – Eye, for instance, uses multiple paper stocks in each issue, but they have similar weight and flexibility; and the page design almost always takes the gutter into account, so despite being perfect-bound, Eye is pretty comfortable to open and read. So is Typo, although its binding is stiffer than Eye’s. But Typo is usually thin enough that it could dispense with the spine entirely, which would make it easier to hold and read.

Some magazines have content that demands immersive reading; others are almost entirely meant for casual browsing. Neither of these functions is well served by pages that are tightly bound into a hard spine.

[Images: two spreads from the Print Regional Design Annual 2011.]

Designing digital books

Published

At TypeCon in New Orleans last month, I spoke about “New problems in book design” – basically the question of how to apply good typography to the design of books that are meant to be read on a screen. Here’s a little of what I said:

“What does it mean to design a book, at a time when books take multiple forms?

“I have no answers; this is all about questions. As Nick [Sherman] said, we’re in a period that people will look back on and see as a seminal time. It is; we’re inventing this as we go along. And the reason I find it interesting is that I read books, and I’ve been designing books for twenty-five years. I’ve spent most of that time — starting out demonstrating that you could use digital typesetting and design tools to do typography every bit as good as what could be done in old metal systems. And now it’s about time to translate that onto the screen.

“One of the reasons it’s interesting now is that I think the tools are beginning to be there for us. And publishers are desperate for it.

[…]

“Basically, what we need is control over all the typographic aspects – but give up the idea of control to make a static page. We want that level of control – I want that level of control – over a dynamic page. So I can say, if somebody decides to change the type size: okay, the line length should stay the same. The number of columns would change – not just making the font larger and making the leading change, which is what happens today in a website when you do that (depending on whether the browser allows you to do that or just blows the whole page up). All those factors need to be controlled together. What we need is dynamic design, we need flexible design, we need intelligent design – intelligently flexible, intelligently dynamic – in order to create good design. And the reason for that, the purpose of that, is the readers: for us, the readers. You can’t design books well if you don’t read them, and that’s true for the screen as well as for paper.

“Every publisher I’ve talked to, every editor, even most of the writers I’ve talked to, is desperate for some kind of solution here. I know writers with backlists that they have the rights to but they don’t know what to do with; they just want to say, ‘Can I put it on a Kindle somehow?’ So the marketing and the sales of books are going to change too – dramatically. But I think that what we need to do is think globally about that, think about how to design, and sell, and market books, both in printed form – for those where that’s appropriate – and in digital form. And as much as possible, for practical reasons, design it so that you actually…so the book can grow out of one file, one set of files. It’s hard! But that’s what we need. Because otherwise, again, you’re back to doing several different versions of everything.

“So in the spirit of it all being questions, I’m concluding inconclusively, and I will throw it open to questions.”

Some of the best stuff, as you can imagine, came out in the questions.

Roger Black: “John, are you saying that we need to set, basically, an extension of HTML rules for typographical things like the relationship between line breaks and leading?”

Me: “Absolutely. How you go about it is a good question, and it’s something that I’m working on right now; but it’s important to have the capability, just as it’s important to have, in browsers and the systems that support them, support for OpenType features.

“But it’s the layout and spacing controls that are the most important part. It’s hard – but not impossible. CSS3 and HTML5 are beginning to add these capabilities. Obviously, in terms of browser constraints, not everybody is going to support that, but… It may be that you use HTML-based systems to still make applications; essentially the book could be an app, if you need control that you can’t have otherwise. I suspect that we’ll do it in both formats. It’s an open question.”

[Thanks for Jill Bell for sending me a copy of the video she shot from her phone, so I could find out what we actually said. The photos above are snapshots grabbed from that video.]

Type Works: Will Powers

Published

When Will Powers died suddenly two years ago, he left a gaping hole in the community of typographers, printers, and book-designers in this country. Now we have a small book to remind us of the work that he left behind: Type Works: the printing, design and writing of Will Powers.

It’s small in extent (50 pages) but not in format: its pages are a generous nine inches square, as befits a book that’s got to show a lot of examples of the design of other books. Oddly, there’s no one named as author or editor, which will perplex book dealers and annoy librarians; it’s simply credited to Interval Press, Birchwood, Minnesota. My copy was sent to me by Cheryl Miller, Will’s wife, and the copyright is in her name. (The information page on the distributor’s website confirms that Cheryl is the book’s editor.)

This collection of essays and reminiscences by Will’s many friends and collaborators gives a kaleidoscopic picture of the man. Although by the time I first met him, he was living and working in Minneapolis, as design and production manager for the Minnesota Historical Society Press, Will had spent many years in the San Francisco Bay Area as a letterpress printer. He and Wesley Tanner printed Fine Print for several years, and Will also wrote articles and designed covers for that remarkable publication. Reading about those times now, with names of people I came to know many years later, makes me imagine an alternate history in which, when I was living in San Francisco after I got out of college in 1971, I had somehow made contact with the local printing community. But at that young age I had no idea that typography was going to be central to my life, and I didn’t meet any of those people, or stay in the Bay Area.

Type Works is a short-run book, printed by BookMobile in Minneapolis, who specialize in short-run and print-on-demand books (and who I know from experience can do a good job of it). Given the display purpose of this book, I could wish that it had a sewn binding that would lie perfectly flat, but that’s not an option in this short a run, unless you manufacture the book by hand. I also wish I could read every word on every printed example shown, but that’s just a reflection of how fascinating the texts that Will worked on (or wrote) tended to be. This is a fine presentation of examples of Will Powers’s excellent typography and book design, of the words written about him, and of a few of his own words as well. And I love the fact that the text uses Zuzana Licko’s typeface Journal, an idiosyncratic but very readable text face of the digital era.

Flexible, adaptive, responsive

Published

For the past couple of days I’ve been devouring Ethan Marcotte’s new book, Responsive Web Design. It’s the fourth in the series of “brief books for people who make websites” published by A Book Apart (an outgrowth of A List Apart). Each one focuses on a specific subject, and is written in a direct, conversational manner with a hands-on approach for web designers.

“Responsive web design” is Marcotte’s term for what I first heard referred to as “adaptive layout” by Microsoft’s Geraldine Wade (now Banes) when she was working on the original New York Times Reader. I usually just call it “flexible layout.” (As the Times Reader app suggests, it’s not only applicable to web pages.) The essential idea is visual design that adapts itself intelligently to the size, orientation, and resolution of the digital “page” it’s displayed on. This can be done well or badly, of course, but first you’ve got to understand the importance of doing it at all.

Marcotte is cogent and persuasive about that. And he shows you exactly how to do it, step by step, even though this is not strictly speaking a “how to” book. More important, he shows you why to do it. His last chapter suggests a reversal of the notion of “graceful degradation” in onscreen design: instead of making a complex design for a big monitor and the latest, most capable software, and then figuring out how it should deal with smaller sizes or less capable systems, he suggests starting by designing a simple, uncomplicated basic design that will work on the tiniest mobile device (“mobile first”), then adding features as (and if) they seem useful in a more expansive environment. Both approaches are adaptable and responsive, but this one seems cleaner and more elegant.

Now the area that interests me most is text typography, which Marcotte doesn’t go into in any great detail. But this just means that there’s more to be learned and invented in this area.

I’m a fan of small, handy, precisely targeted books, and the Book Apart series is just that. These books are consistently designed (by Jason Santa Maria), readable, and easily portable (despite somewhat heavy coated paper). There are a few bits of sloppiness; the proofreader could have caught the glitches in the hyphenation algorithm that produced “wides-creen” and “in-teract” as word breaks, and a copyeditor might have questioned the author’s frequent use of “to better [do this]” or “to better [do that],” but these are quibbles. Responsive Web Design and its predecessors in this series are useful, well-done tools in their own right.

Regional powers

Published

I’ve been looking with interest at “CSS Regions,” Adobe’s entry into the arena of flexible page design on the web. This is clearly the sanguinary bleeding edge of onscreen design today – designing intelligent layouts that will behave differently (but coherently) under different circumstances, most notably on screens or in windows of different sizes and shapes.

Adobe Labs has released an experimental WebKit-based web browser, as a platform for showing off what CSS Regions can do. The demonstrations are mostly about shapes: they include multiple columns, arbitrarily shaped text blocks, text that flows from one text block to any other text block on the page, and a couple of other, more specific tricks. In the demos, text wraps neatly around images or around other text, in a highly flexible manner.

It’s good to see these problems being tackled. But there’s something missing. As an earlier Wedmonkey article about this technology put it, “when it comes to the flow of text around images, pull quotes and other block level elements, well, web typography falls apart.” CSS Regions is clearly aimed at enabling design with these “block level elements.” But that’s only macro-level typography; what about the typography of the text that’s doing all that wrapping? We need the same level of control over text typography on the web that we’ve got today on the printed page. And not just in an inflexible page created in InDesign and turned into a static PDF.

More tools, please.

Reading matter

Published

The new issue of Typo has a thoughtful article about the typography of onscreen reading – entitled, sensibly enough, “Electronic reading: the future is now.” It certainly is.

The author clearly knows his stuff. According to his bio note, “Martin Pecina is a designer and typographer, enjoys reading and designs books.” An enjoyment of reading is a prerequisite for designing books, or at least doing it well. (I know that my own approach to designing a book starts with imagining how it would be to hold and read that book.) And an enjoyment of reading should also inform any design for electronic books, as Pecina points out in a rather severe critique of the current state of the art.

He doesn’t just show off bad examples – something that’s absurdly easy to do with almost any current form of e-reader – he spells out the kind of typographic decisions that need to be made in laying out a page of text, whether that page is fixed and printed or fluid and controlled by dynamic rules. Anyone working in digital book publishing today ought to read this article.

Pecina analyzes the problem by dividing it into two parts: basically, the hardware and the software. The hardware may be a “universal device” (a computer or phone that serves a number of functions, of which reading is just one) or a “specialized device” (a dedicated e-reader). He is scathing about the nature of most computer screens: “But – it is impossible to read well from a lit display. Sure, we read websites on them, even PDF documents, maybe annual reports, press releases and various corporate documents. But it’s no good for reading long passages of text.” He feels that the only reasonable future for digital books is passive display technology using e-ink and reflected light. “In terms of electronic books, the backlit display is a dead end and brutal debasement; devices with this technology will never fully replace printed books, no matter how many millions of titles for the iPad or similar devices end up being sold.”

In the long term, I’m sure, he’s quite right. The future of long-form reading may be a few high-quality printed books, supplemented by a kind of smart paper, where nanotech “ink” forms and re-forms the text as needed on a single page.

Most of the essay, however, focuses on the software used to create e-books, cataloging both what the currently available systems do and what’s needed to make them work right. He makes a distinction between a “final” document, a composed page (whether in print or in a fixed form like a PDF file), and an “unfinalized” document, where both the form and the content may continue to change. (He doesn’t give much attention to the idea of a document whose content is fixed – nobody’s going to change the words of a novel – but which might be presented in a fluid variety of forms.) And he raises serious questions about books with complicated multi-level text, such as scholarly publications, which may have footnotes and several layers of nested content. (Scholarly books would benefit most from electronic publishing, since the audience is usually small and the cost of printing proportionately high, but creating a system that can handle that kind of complexity in a flexible manner is not easy.) “Simple text,” he says, “is flexible, can easily flow from a small into a large format or from landscape into portrait orientation, all quickly and without losing a bit of its essential nature. The situation is perceptibly different for scholarly or professional texts.”

Pecina gives a nod to the two-page spread, so innate to the nature of a printed book bound at the spine. Digital books, of course, do not have any need for a spine, and therefore no need for facing pages, although some e-reading software tries to present a familiar-looking facsimile of an open book. He mentions the “scrolling” model, which we’re all used to from websites and word-processors; what he doesn’t mention is that before the codex form of the book, handwritten scrolls too were composed in pages – though not in two-page spreads. I remember how surprised I was when I learned that real-life ancient scrolls were held horizontally and read side-to-side, not held top-to-bottom the way you see in cartoons and historical movies. Perhaps a royal proclamation would be held vertically, but an actual book – the literature of the Greeks and Romans, or the religious texts of the ancient world – was held horizontally and rolled open enough to view a single, relatively narrow block of writing: a single page. Perhaps we’re coming back to an older tradition than we’ve been following for the last millennium or so.

Pecina also mentions the design problems of books with illustrations or other images, which a traditional book designer deals with in composing a page. What he doesn’t go into is the other kind of editorial design, which shares a lot of its DNA with the book: magazine design. There are books that revel in image and display type with hardly any traditional “text” content, and there are scholarly journals that are essentially books in periodical form; the boundary is very porous. Do magazines lend themselves to display on an e-ink device? How about sumptuous art or photography books? Is the dividing line the need for color? The balance between image and text? The ephemeral nature of the content?

I suspect that the problems of designing complex books for reading on a variety of screens are akin to the design problems currently being posed by magazines with digital editions. The answer requires truly dynamic layout, with all the careful thinking-through of hierarchy and if/then behavior that that implies. If such systems of design and production are sophisticated enough, they’ll be able to handle text and image of any complexity, and do so in a typographically elegant way that just seems natural to read. That’s where the future is, now.

[Image: cover of Typo 43, Spring 2011, with its witty commentary on fonts’ spotty support of Central European character sets.]

Web type at last!

Published

This has turned out to be the year of web fonts. I don’t just mean typefaces designed for use on the web; that’s been going on for at least a decade and a half, most notably with the spread of Verdana and Georgia throughout the online world. I mean that at last we’re getting a workable system for using a variety of typefaces on web pages – and being reasonably certain that everyone viewing those pages will see the same typefaces, not some substitute based on what happens to be available on their computer.

A year ago, this seemed impossible. There was a whole track of programming at the ATypI conference in Mexico City about web fonts, and lots of interest in the topic, but there seemed to be no common ground for agreement about the right way to move forward.

WOFF

In the past year, however, the key players came together to form a Web Fonts Working Group under the auspices of the W3C (World Wide Web Consortium), and after months of hard work and persuasion, they agreed on a new format for web fonts. It’s called WOFF (Web Open Font Format), and it’s well on its way to becoming a generally accepted standard. According to Erik van Blokland, one of the creators of the format, WOFF will be “the only (!) specification that W3C will recommend for use on the web.”

All of the newest versions of major browsers, either out now or out soon, support WOFF, including the recently-released beta version of Internet Explorer 9. (Mozilla Firefox was the first to implement WOFF support; Mozilla was one of the developers of the format.) Browsers may implement other formats as well, but WOFF is likely to be the only format that’s guaranteed to work across all “modern” browsers.

Properly speaking, WOFF isn’t a new font format; it’s a software wrapper around an existing TrueType or OpenType font. The WOFF wrapper includes “metadata” – information about the font – that font vendors can use to tell you who designed the typeface, who licensed it to you, and what the terms are for that license. This is just information; there’s no enforcement involved, no DRM, nothing to prevent someone who’s willing to go to a little trouble from unpacking the font inside the wrapper. The purpose of the metadata is to make it obvious to anyone who downloads the font that it’s a web font, intended for use while viewing a web page, not a “desktop” font that you can use in any file or application you want. This whole approach is promulgated on the assumption that most people, if it’s clear and easy for them to do the right thing, will, in fact…do the right thing.

Web-font services

The newest versions of all the major web browsers support WOFF, which makes it a universal format going forward. Looking backward, of course, is another story. What about older browsers that don’t have WOFF support built in? Lots of websites will be viewed in older versions of all of the major browsers. That’s where web-font services come in.

At the same time that vendors and manufacturers are coming out with sets of fonts intended for the web, an increasing number of web-font services have sprung up, each offering its own system for supplying those web fonts to designers and end users.

There are two parts to a web-font service: 1) making the fonts available to web designers so they can specify them in the designs of their web pages; and 2) enabling those fonts to be downloaded to users’ systems when they view those web pages.

The web-font service takes care of delivering the right fonts in the right formats to each version of each browser; the website host or designer makes an arrangement with the service, usually for a fairly nominal fee, and then uses the fonts available for that service in designing their web pages.

The list of web-font services is growing almost daily; so is the list of font foundries who are offering their fonts in web versions. There are many different ideas about the best way to do this, both technically and from a business standpoint. A web designer just has to pick one and give it a try. They’re all available right now.

There is variation in quality, of course. Typekit, for instance, which is perhaps the best known, offers fonts from a lot of different foundries; some of them are better engineered for onscreen use than others. Webtype.com, launched by Font Bureau, offers not only a web-font service but several families of carefully designed new fonts, with their roots in metal but their forms dictated by what works onscreen. Adobe recently launched their web-font library, a wide selection of font families from their larger font library, and already Adobe has upgraded and improved the rendering of some of those fonts. On the web, it’s very easy to update things, to iterate; there’s no final form. Now that the floodgates have opened, you can expect things to keep changing fast, and the quality to keep getting better at a rapid rate.

For users, the WOFF revolution is a very good argument for upgrading your browser, since only the newer versions of each browser will support this format. (You may get good results from some of the backward-compatible formats offered by some web-font services, but you will get better results – the type will be more readable – with an up-to-date browser.) If you’re a web designer, it’s time to start looking into WOFF.

[Image: an apt slogan taken from the homepage of webtype.com]

“Systems for pages”

Published

Roger Black has been thinking about template-based editorial design for quite a while; when I was talking to him in Mexico City last year, he said he’d been focusing more and more on this kind of systematic design. Last week he, along with Eduardo Danilo, Sam Berlow, Robb Rice, and David Berlow, launched a new venture called “Ready-Media” that would market exactly that. “We’re making systems for pages, not pages themselves,” Roger said in their press release.

Over on spd.org, the website of the Society of Publication Designers, the shit hit the fan. Bob Newman’s brief article “Just Add Water” (Grids, July 20) generated a long slew of heated comments, many of them objecting to the very idea of design templates and worrying that Roger Black was (once again?) going to destroy the profession of publication design. A few people pointed out that templates have been with us for decades, and that the most likely effect may be to raise the base level of quality on low-end publications, rather than replacing “real” designers on big-ticket designs. (The real question there will be whether Ready-Media’s services are priced for low-end or high-end clients.)

Quite apart from the business of offering canned design for sale, templates are essential for what I call “automating quality.” This means not just crafting a beautiful page, but creating a flexible system that you can use to pour varying kinds of content into and create a reliably good result. When I was a compositor at Microsoft Press back in the 1980s, we worked on just this sort of problem with the books we were designing and producing. (I even found myself writing hexadecimal translation tables and complex logical “formats” in order to massage the text we imported into the CCI composition system.) On a text-paragraph level, this is also what Adobe implemented a decade later with InDesign’s multi-line composer. (In the interim, I had been writing a series of white papers for Aldus Corporation, delving into the details of the composition engines underlying, respectively, PageMaker and QuarkXPress, both of which were trying to create workable typographic defaults.)

Ideally, in a truly flexible layout system, you have the same kind of hierarchy of rules for laying out the elements on the page that you have for deciding where to hyphenate a word at the end of a line of text. It’s the same kind of “if, then” decision-making, but at different levels. I’ve seen web designers apply this kind of thinking (too rarely!) to the ever-shifting sizes and orientations of web pages, trying to make sure that the layout adapts to give the best possible result in any circumstances. (Not surprisingly, Ready-Media promises to add templates for web design shortly.) And at a simple level, even in a word-processing program, the use of paragraph- and character-level styles is a tool for intelligent automation.

Nobody can automate quality completely. At the end, you always need to apply a trained eye and make corrections and adjustments. But a good, well-thought-out decision-making system will get you to a much higher plane right from the start.

Don’t wrap it, I’ll read it here

Published

The demo of a new online interface for Sports Illustrated, based on HTML5, does a good job of showing off fancy magazine layout in a screen-friendly format. But it falls down when you look closely – when you tear your eyes away from the action photos and try to read the text.

Like all those current e-books, this e-magazine falls down in simple text typography. The text of the articles is justified, yet there’s no hyphenation. When your text composition engine doesn’t even hyphenate the word “grandmother” at the end of a loose line, it’s just not doing its job.

The page designers at Sports Illustrated make it even harder by shoving intrusive pull-quotes into the main text block and wrapping the text around them. This is a bad enough at any time (it says, in effect, “we don’t care about the words, just the shape”), but it’s inexcusable when you can’t even hyphenate those extra-short lines next to the pull-quotes. Text wrap and justification rarely work together. (Anybody heard of a multi-column grid?)

Oh yes, and the pull-quotes use straight apostrophes. With a non-typewriter typeface.

In a tweet today, after seeing the demo, Roger Black called it “The best digital magazine . . . yet!” Which may be true – but if so, there’s still a long way to go.

[Images at left from the YouTube video about the HTML5 new prototype.]