What were the key changes made when we started designing typefaces for screens?

Niteesh Yadav

I'm trying to find the design features/ strategies used to design typefaces specifically for screens as opposed to how we designed typefaces for print.

Jasper de Waard

I would say Verdana and Georgia are your best starting points.

Tall x-height, open counters, low contrast, loose spacing. 

James Puckett

This goes back much farther than Verdana and Georgia. You need to research the people who started creating bitmap fonts back in the late 1960s. And the Hershey fonts go way back, they might be the first vector fonts.

Lucida might have been the first vector type family based on bitmaps. But I’m probably wrong about that.

John Butler

Demos and Praxis by Gerard Unger come to mind. And Marconi by Zapf.

Chris Lozos

You might also look at early typewriter as an attempt to compromise a very rigid grid-fit to a small number of units.  Also look at "The Stroke" to try and parse what the hand naturally does to fit a mechanical rhythm. There has always been a struggle between hand/eye decision and measuring systems. It seems to me that we never perfectly solve this in movable type, we just find a finer allotment of units to reduce visible difference. We are no-longer stuck with 72dpi.

John Hudson

You can’t talk about typeface designs for screen without talking about specific display technologies, resolutions, and renderers.

There are two different aspects to ‘designing typefaces for screens’: designing typefaces for specific screen display technologies and the resolutions and rendering systems involved, and designing typefaces for reading on screen. Obviously, there is overlap between these two aspects, but the former may be independent of the latter and was commonly so in the pre-Web period, and the latter may generalise certain design concepts or features independent of specific resolutions or renderers.

Niteesh Yadav

John Hudson said:

...designing typefaces for reading on screen. Obviously, there is overlap between these two aspects, but the former may be independent of the latter and was commonly so in the pre-Web period, and the latter may generalise certain design concepts or features independent of specific resolutions or renderers.

if we take "designing typefaces for reading on-screen" into consideration then what would be the design features/ strategies employed in those cases? Also is there a resource that I can refer to?

John Hudson

A lot of case studies exist regarding design of type for reading on screen, but I am not aware of a single, comprehensive resource. I am going to second the recommendation to look at the design process for Georgia and Verdana. While these were not the first types designed for screen, they were ubiquitous in the crucial period of transition from people mostly reading ink on paper to reading pixels on screens. They also represent a particular approach to design for screen that proceeds from bitmaps to outlines and then back to bitmaps, i.e. target text size bitmap glyphs were created, and Matthew draw the outlines of Georgia and Verdana to fit those bitmaps, the outlines then being hinted for a range of additional bitmap sizes. These fonts also belong to a period of change in rendering technologies: straddling the needs of b/w bitmaps, greyscale rendering, and colour subpixel LED rendering.

As I recall, Tobias Frere-Jones has written about the ways in which design for text on screen follows that of small optical sizes for print: larger x-height, looser spacing, more robust stems.

John Hudson

Speaking of outlines designed around bitmaps, here is an ugly thing we made in 1998: a TTF for a terminal emulator, targeting a specific ppem size and reproducing the shapes of the client’s older, and frankly not very good bitmap font.

Christopher Slye

It’s only tangentially related to the subject here, but I wouldn’t discount how early Adobe Originals were designed to conform to the limitations of PostScript and low-resolution printers. Especially with PS hinting, where there’s less control than with TT instructions, one had to pay close attention to their design decision (consistent heights, stems, etc.) to ensure good gridfitting results. If you’ve ever seen a thoughtlessly-designed font printed on an old 300-dpi monochrome laser printer, you’ll know what I mean.

Life was pretty bleak for screen reading when screen were both really low-res and monochrome. Most design for that was probably in the bitmap realm anyway. There must be some good information from Emigre about that, and maybe Apple’s system fonts. (Remember Espy?)

Thomas Phinney

Also, the Mac versions of  PostScript Type 1 fonts had matching bitmap fonts, initially for Mac screen use, and later just because they were required for the fonts to function—even when not actually used.

At least when they were actually in heavy use on screen (1985 to early 90s), they were generally handmade. Their actual use for on-screen rendering was rendered obsolete by increasing use of ATM beginning in the early 90s, and full integration of Type 1 (and OpenType CFF) support in operating systems circa 2000.

As I wanted to learn all aspects of font production, among my early tasks at Adobe (in 1997 or so, when they were already kind of obsolete) was making the hand-tuned bitmaps to accompany the non-MM Type 1 version of Myriad Condensed.

Nick Shinn

Especially prior to the introduction of the “Retina” high-res screen, we tended to standardize x-height and overshoot by means of alignment zones.

Similarly, stem widths were standardized (and still may be).

These hinting accommodations for “low res” media led to a sober quality in traditional serifed styles. For instance, compare the liveliness of older metal-era Garamonds (Monotype, Linotype) with the cool demeanour of Adobe Garamond.

But Adobe Garamond was not designed “for the screen”; it occurred in the Low-res Era, when print was still king, between the introduction of Desktop Publishing and the Internet. Nonetheless, what we might think of as screen issues also affected laser prints (as Christopher notes), and nothing was more annoying in those days than to proof a text type design on one’s low-res studio LaserWriter and see the overshoots jumping all over the place in a way they would not when eventually output at high res on a Linotron, for the finished job.

Hence the distinction between type tech eras:

1988-1999 Low res (laser) print
1999–2010 Low res internet
2010– High res internet

***

The ability of designers (whether type designers or graphic designers/art directors) to zoom into a set piece of typography on-screen (in Quark, Illustrator, Photoshop etc.), coupled with the sharper printed type of the digital-to-plate workflow, promoted an interest in very light-weight types. I documented this in an article I wrote, Seeing the Light, for Graphic Exchange magazine in 2001.

John Hudson

Another way to think about the relationship of screen and print media is to consider that ‘scaleable type’ not only scales to different sizes, but also to different output resolutions and rendering methods, but not losslessly, hence ‘hinting’ which is the adjustment of vector outlines to the rendering grid.

Mark Simonson

Also, the Mac versions of  PostScript Type 1 fonts had matching bitmap fonts, initially for Mac screen use, and later just because they were required for the fonts to function—even when not actually used.

This was because the font metrics were stored in the bitmap font file. The "printer font"—i.e., the PostScript part—contained the outlines, but not the metrics (spacing and kerning). But, yeah, the bitmaps were no longer used once ATM existed. Before ATM, the PostScript was only for printer output, and not used on-screen.

Thomas Phinney

The printer font contained the outlines, and the spacing, but neither kerning nor menu name and style linking information. All that was in the (Mac) suitcase file which also contained the bitmaps or the (Win) PFM.

Mark Simonson

Right, thanks for the clarification.

Essentially, a reference to the separate PS font file was added to the existing Mac screen font format (NFNT), which already supported everything else, so that you could print to a PS printer. Everything needed for screen display of a font family was in the NFNT file.

Thomas Phinney

Exactly, yes.

Christopher Slye

A couple further thoughts on this topic. I’d say “design for screens” used to be approached completely differently because of the hardware. Screens used to be relatively predictable. Those tasked with designing type for screen reading often had specific hardware at hand, or at least understood that they would target, say, single bit pixels at one resolution, or maybe a narrow range. Design was often all about manipulating individual pixels.

These days, the requirements are more environmental — understanding light-emitting screen media, ambient light, viewing distance, color, interfaces, motion, and so on. Hardware can’t really be predicted, and nobody worries much about pixels like they used to.

I think it’s right to look at Microsoft’s screen fonts (Verdana, Georgia, etc.) in this context. They signify the transition, being technically equipped for lower resolutions (i.e. TT super-hinting), but for grayscale and color screens (subpixels), and also acknowledging how ubiquitous but unpredictable screen reading was about to become. The actual designs were a much bigger factor than what came before.

So in a way I think the “design strategies” of the desktop era aren’t so relevant. Not only do we now have decades of real-world experience looking at type on-screen to understand what works and what doesn’t, but younger (meaning: not old) people have learned to read on screens and bring in far fewer expectations and requirements from print media.

In a way, I think we’re back to where we were. Maybe we don’t really “design for screens” anymore, we just design for reading. Screens are not the special case they used to be.

Dave Crossland

Christopher Slye said:

I think we’re back to where we were. Maybe we don’t really “design for screens” anymore, we just design for reading. Screens are not the special case they used to be.

I agree with the exception that I guess the new AR/VR media might take us away from where we were, again

John Hudson

I agree with the exception that I guess the new AR/VR media might take us away from where we were, again

That was definitely the case when we were testing fonts on a variety of AR/VR headsets shortly before COVID. The project didn’t come to anything, alas, but I learned a lot about lens types and what happens to text rendering on tilted planes. The range of quality across different headsets and rendering technologies was, if anything, broader than that of monitor resolutions in the 2000s, compounded by different lens types. On the other hand, we now have variable fonts and the possibility of tuning a design for different media and hardware.

PabloImpallari

For Libre Caslon, I've designed the Text cut specifically for web body text.



I've also optimized the UPM so that the Text version renders bigger too.

Niteesh Yadav

Dave Crossland said:

Christopher Slye said:

I think we’re back to where we were. Maybe we don’t really “design for screens” anymore, we just design for reading. Screens are not the special case they used to be.

I agree with the exception that I guess the new AR/VR media might take us away from where we were, again

I started this discussion just to dig a bit into history so that I can get more insights into how we adapted to screens when the transition was happening from print. Trying to figure out more design strategies that I can reference while designing the typefaces for AR/VR 😀

Really grateful to all the people who have contributed to this discussion 🙏