Skip navigation
Help

web typography

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
(author unknown)

For ideal typography, web designers need to know as much as possible about each user’s reading environment. That may seem obvious, but the act of specifying web typography is currently like ordering slices of pizza without knowing how large the slices are or what toppings they are covered with.

If someone asked me how many slices of pizza I wanted for lunch, I would probably say it depends on how large the slices are. Then—even if they told me that each slice was one eighth of a whole pie, or that they themselves were ordering two slices, or even that the slices were coming from Joe’s Pizza—any answer I might give would still be based on relative knowledge and inexact assumptions.

Such is the current situation with the physical presentation of responsive typography on the web. The information at a designer’s disposal for responsive design is virtually nonexistent outside the realm of software. Very little knowledge about the physical presentation of content is available to inform the design. The media query features of today can only relay a very fragmented view of the content’s actual presentation, and related terms from CSS are confusing if not downright misleading.

The immeasurable pachyderm

Among all the physical qualities of web typography, the elephant in the room is the issue of size. I’m not talking about em or rem or “reference pixels” ¹ or even device pixels. I’m talking about real, actual, physical, bona fide, measurable, size!

It’s ridiculous that we can send robots to Mars yet it’s still virtually impossible to render a glyph on a web page and say with confidence: “If you measure this glyph on your screen with a ruler, it will be exactly 10 millimeters wide.” Although actual physical size isn’t always the most important factor in web design, in some cases it is critical. For example, consider content for partially-sighted or low-vision readers: the ability to tweak designs according to physical sizes would enable designers to make conscious design decisions with much more sensitivity to how the type is actually being seen. And even where physical sizing is secondary to relative sizing, why shouldn’t we nevertheless be able to factor in physical size when establishing the relationships between different elements?

Physical considerations ≠ print design

I don’t believe web typography should be a screen-based imitation of print typography. One of the greatest benefits of web typography, and web design in general, is that it is flexible, adaptable, fluidly adjustable, without being locked into any one specific configuration. However(!), that doesn’t mean web designers should be forced to design without any means to address the issues of physical presentation. On the contrary, responsive design will not reach its full potential until it allows the ability to respond to the very important physical variables of digital media.

Please pardon the cliché, but when it comes to typography, on screens or otherwise, size matters. Physical size affects optical issues that change how the eye and brain process typographic images. Not surprisingly, typographers and typeface designers have been compensating for optical size-related issues as far back as Gutenberg.

You can’t expect a paragraph of type with the same relative line-height, column width, letter-spacing, and glyph proportions to function just as well on two different displays that have the same number of pixels but completely different physical sizes. It’s great that designers can adjust proportions between typographic elements if the canvas varies in relative size, but any such compensation is still based on guesswork and assumptions about the physical size of that canvas. When people disagree about the size or spacing of type on a website, there’s a very good chance that their opinions are based on completely different physical manifestations of the same content, even if their software and settings are identical.

Resolute resolution, absolute absolution

One of the most crucial factors in the size equation is resolution. And when I say resolution, I don’t just mean “how many pixels is this?”, or even “how many device pixels is this?”, but also “how large are these pixels?”

This is very different from the W3C’s “resolution” media feature in the current draft of the Media Queries Level 4 spec. You will note that the spec refers to resolution in terms of “CSS ‘inches’”—the quotes around “inches” are theirs, implying that they are not actually inches at all.

For an example of why physical resolution matters, imagine you are rendering text on a digital billboard with a physical resolution of one pixel per inch (1 PPI). Now imagine you are rendering the same text on a 200 PPI mobile device display. Even if you knew the actual number of device pixels that would be used to render your type (which itself is difficult to do with confidence these days), you would want to treat the two compositions very differently, both in terms of the typeface as well as typographic layout. The billboard type would likely require less space between letters. The letterforms themselves would benefit from narrower proportions, and could endure a higher ratio between thick and thin strokes. The type might even require different colors to optimize contrast at that size. These are all basics of typography and typeface design.

Unfortunately, in the current landscape of media query features, there is no way to know the difference between 16 device pixels on a crude LED billboard and 16 device pixels on a high-density mobile display. Heck, there isn’t even a reliable way to know if your type is 16 device pixels at all, regardless of how large the pixels are!

Pixels still rule, for better or worse

I know what some em-based enthusiasts might be thinking: “But you shouldn’t be specifying type sizes in pixel units to start with! All type sizes should be spec’d abstractly in relation to each other or a base font size!” However, in the current world of web typography, no matter what unit of measure you use to spec your onscreen type sizes—em, rem, px, pt, in, %, vh, or whatever else—at the end of the line, your specification is being mapped to pixels. Even if you leave the base size of your document to the defaults and specify everything else with em, there is still a base size which all other sizes will ultimately refer to, and it is defined in pixels.

This is because, currently, the only unit of measure that can be rendered onscreen by any operating system with absolute confidence is the lowly pixel. Until we have media query features that allow us to spec for situations like:

@media (physical-resolution: 1device-pixels-per-physical-inch) { … }

or:

@media (device-width: 10physical-centimeters) { … }

… any compensation for physical size is based entirely on rough guesses about the devices our content will be presented on.²

It’s a complete fallacy that the official CSS spec allows so-called “absolute” units of measure like inches, points, and centimeters to be mapped to anything but actual physical units. Ironically, previous versions of CSS treated these things as you would hope and expect, but a change was made “because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.” Call me idealistic if you will, but I am more of the mind that a spec should be written based on what is best for the future, not to cater to things that were made in the past.³

Getting physical

Any ability to leverage physical variables for web design will require a joint effort by several groups:

  • Device manufacturers will need to provide APIs that can inform the operating system—and, by extension, web browsers and web designers—of the actual physical properties of the hardware being used to present content to the user. Some device APIs are already beginning to show up in the world, but there is a long way to go before functionality and adoption are anywhere near dependable.
  • Standards organizations—the W3C in particular—will need to establish specifications for how to reference physical properties when formatting content. They will need to update (or at least augment) their existing “absolute” units of measure to be more meaningful, so they are more than just multipliers of sizeless pixels.
  • Software manufacturers will need to implement support for new specs relating to physical media features. Browsers are the most obvious software that will need to implement support, but the biggest challenge might be in getting native support for device APIs in operating system software.
  • Type manufacturers and type services will need to provide more diverse ranges of typefaces that have been optimized for a variety of physical properties. Ideally, many of the needed variations could even be provided on the fly using a broader approach to the ideas of font hinting.
  • Web designers and developers, last but not least, will need to build their sites to respond to physical properties, leveraging all variables to the benefit of their users.

Size and resolution are just the tip of the iceberg of physical variables that could be considered when improving web typography. Things like viewing distance, ambient light, display luminance, contrast ratio, black levels, etc., etc., could all be factored in to improve the reading experience. Even the ability to know some variables within the realm of software, like the user’s rendering engine or the presence of subpixel positioning, would go a long way toward helping web typographers design a better reading experience.

In the meantime, I’d love to see more of the players mentioned above start to at least experiment with what’s possible when physical features can be specified, detected, and factored into responsive designs in structured, meaningful, and predictable ways. Until we can do that, we’re all just ordering pizza without knowing exactly what will end up on our plate.

0
Your rating: None

  

For years you have been searching for it. You hear the question being asked in your dreams as you go on an Indiana-Jones-type-crusade to find the answer. When the answer comes to you, you know that the confetti will fall from the ceiling and the band will start playing your favorite song. You might even get a kiss from that special someone. So what is this question?

What is the secret to Web design?

A tough question and one that might not have an answer. In 2006, Oliver Reichenstein wrote Web Design is 95% Typography. Some people loved it, others were not so amused. If Web design was based that much on typography, then what was the point of learning anything else? All you needed to do is understand the elements of typography and you were good to go.

Of course typography doesn’t mean font selection. With the advent of @font-face and services such as Typekit, Webtype, Fontdeck, and Google Web fonts, your skills in typography won’t improve. You can easily create wonderful designs with one font for the rest of your life if you choose to—they had to do it centuries ago and they didn’t have Photoshop sticking things to guides for them. If anything, more font selection will make things worse for you because creativity and beauty become hard to achieves when more options are given to us.

More toys means more fun though, right? If you want to go that route, then by all means go for it. I love to look at the different fonts being used and admire anyone that can successfully pull off using newer fonts for the Web. However, I’ve seen too many times what can happen when development options are given to the masses, and it isn’t pretty (re: Myspace). Instead of having a user agreement it would be cool if Typekit made you read a book on typography before you could begin using a font—the Web would improve tenfold, if that was the case.

I’m not being sarcastic, saying that is all you need to know for a majority of websites. Try going through all of the Web designs that you love, strip out the images and ask yourself “how would that website look with just text and spacing?”. When designers say “text is the interface”, they really do mean it. The iA site is a great example of that.

Information Architects
Information Architects is based around strong typography.

One of my all time favorite designs is A Working Library. The site is a showcase of text being the interface. The spacing is just right and the typography is on point.

A Working Library
A Working Library by Mandy Brown.

Some people find design like this to be dull and boring, they feel that design should have more pop to it. At the end of the day some extra visual flair might be what separates your design from the rest, but you need to get the first 95% down. The website that you are reading this article on now has done a wonderful job of presenting a visual design that isn’t reliant on images to be beautiful.

Well That Isn’t Hard

It’s possible to create a wonderful design without the use of images at all. I know that sounds crazy, but it is possible. I’m not saying it should be done, but if we can create elegance simply with typography and white space, then why shouldn’t we be able to create greatness when we start throwing in images, videos and other effects?

With the use of images I’m not talking about images that are needed to represent something such as icons, but images that are there for flare. Sometimes a picture is worth at least ten better words than any word you could use, so it’s better to go with an image (but you still need to consider using white space with it).

Here are two more examples of beautiful websites that place a heavy emphasis on typography to control the design. The first is Blake Allen Design and the second is The Harriet Series (both use images to represent their typography, but you get the point).

Blake Allen Design
Blake Allen Design uses images, but with great typography.

The Harriet Series
The Harriet Series by OkayType.

What makes the two designs above so interesting to me is that the typography not only guides you along a journey, but it does so with personality. You almost feel as if the typography is an expression of the person that designed it. Blake Allen uses Helvetica which gives the website a Swiss, clean and structured personality. On the opposite side of the spectrum, the Harriet Series website is a bit more playful and experimental—there is beauty in the organized chaos that the typography creates.

For 99% of the designs out there, typography and white space are going to be your underlying foundation. So if you can’t get them right, then the rest of your design has nothing to stand on. Stop worrying about the pop of your design and first worry about how it will stand tall. Once you get that down then you can begin to dress it up.

Clear is a very simple to do list application for iOS devices. While the majority of the excitement around it are the gestures used to control the interface, you will notice that the typography does enough to get out of the way and allow you to enjoy the application. Sure it is nothing more than Helvetica, but what if it was Comic Sans and had bad spacing all around? Great typography doesn’t have to stand out in a good way, but that doesn’t mean it should do enough harm when it stands out in a negative way, either.

Typography In Other Disciplines

Art of the Menu
Art of the Menu is a great website on menu design.

The Art of the Menu does a great job of showing the importance of typography in menu design. While a lot of restaurants like to add images and illustrations to their menus to give them a bit more pizzaz, they fail in providing a decent typographical structure that allows you to easily browse through the menu.

If you are a designer you have no excuse to say you can’t come up with a decent design. When you create a design that lacks a strong foundation, anything else you add to it is just going to make it worse. Too many designers attempt to save their designs with fluff without understanding they are pouring gasoline onto the fire. If a design is not enjoyable to read then it is not an enjoyable experience, no matter how many images, colors or sounds you decide to add to it.

Looking to understand typography a little bit better? Not too long ago Smashing Magazine did a comprehensive overview of some wonderful typography tools and resources.

(jvb)

© Paul Scrivens for Smashing Magazine, 2012.

0
Your rating: None

  

We do more reading on the screen today than we did even a year ago. If we are ever to have a golden age of reading on the screen, this might be the start of it.

Tablets, Nooks and Kindles make buying a book or magazine for the screen almost unavoidable. With smartphones, we carry our reading material with us and enjoy instant Web access, enabling the reading experience to flow smoothly from one device to another. And those devices probably have stunning HD reader-friendly screens. Throw in companion services like Readmill and 24symbols, which allow us to share our reading experiences, and we have perfect screen-based access to all aspects of the written word.

So, why isn’t Web and screen typography keeping up?

Good Typography Cannot Be Handcrafted Anymore

In the past, typography was viewed as living only when it reached paper. Once a publication was edited, typeset and printed, it was done. Nothing changed after that. Good typography and readability were the result of skilled typesetters and designers.

Today, typography exists not only on paper but on a multitude of screens. It is subject to many unknown and fluctuating parameters, such as operating system, system fonts, the device and screen itself, the viewport and more. Our experience of typography today changes based on how the page is rendered, because typesetting happens in the browser.

In all of this, the browser is probably the most important part of the screen typography equation. Ironically, the lack of support in modern browsers is the single biggest hurdle to good Web typography.

Type-as-service providers are offering an alternative, with an increasing number of fonts that are fairly cheap and easy for us designers to use when typesetting text. But they, too, want better support of Web typography.

Identifying What’s Missing

Let’s look at some of the basic things that are missing from most, if not all, screen-reading experiences. When we say basic, we mean the things that you read and benefit from whenever you look at a book or magazine on paper or screen.

  • Kerning and spacing of individual characters;
  • Basic ligatures (fi, fl)
  • Other ligatures (fj, ffi, ffl, ffj and more);
  • Lining and old-style numerals;
  • True small-caps;
  • Replacing uppercase with small-caps for abbreviations;
  • Superscripted symbols such as © and ™;
  • Language-based quotation marks;
  • Correct replacement of en and em dashes, and the spacing around them;
  • Spacing of ! ( ) [ ] / ; :.

Doesn’t seem like much. Except that it is. The elements in this list are some of the things that help us read, process and understand information. They represent in many ways the difference between how a soulless machine would relate to text and how thinking, organic humans do it.

Those of you who were around during the desktop publishing boom might see similarities. In 1999, QuarkXPress did not support OpenType, InDesign was just born, and you had to use “expert” cuts of fonts to be able to work with small-caps and old-style numerals. So, we had to create workarounds for micro-typography — such as Apple-Script frameworks for QuarkXPress, where the script traversed documents and isolated hyphens, dashes, ligatures and small-caps abbreviations, replacing them with the correct typographical equivalents.

In many ways, 2012 is the new 1999. We have the freedom to work with any font we like via the @font-face selector. But our main tool, the browser, does not have any OpenType features to speak of. We have to create workarounds.

Can we use the same type of solution that we used back in the old days of print?

We say yes.

Time to Fix the Problem

We researched existing JavaScript libraries and found a ton of great stuff. But none focused on micro-typography as a whole. When we started the project, we laid out five clear goals:

  • Correct micro-typography, including as many of the elements in the list above as possible;
  • Degrades so that devices without @font-face or JavaScript support are not negatively affected;
  • OS independence;
  • Browser independence;
  • Correct markup;

We named the project OpenTypography, and we named the solution Typesetter.js.

JavaScript and @font-face and styles disabled.

JavaScript disabled.

JavaScript enabled and @font-face-enhanced Web typography.

Typesetter.js

Typesetter.js has two ingredients: a JavaScript and a custom font file

The JavaScript traverses the DOM, finding and replacing things like quotation marks, ligatures, en and em dashes, ellipses and more. It also finds ©, ®, ™ and wraps them in sup tags.

Most importantly, it finds uppercase abbreviations and wraps them in abbr tags, giving us true small-caps. This is possible thanks to a bit of CSS and the services of font-on-demand houses such as Fontdeck and Typekit.

Finding, replacing and wrapping.

Here is a rundown of how Typesetter.js works.

1. The JavaScript

The code is divided into two parts, giving you the option to use the small-caps replacement. But let’s start by looking at how the small-caps replacement works.

Here is the sample HTML that we will use to explain what the script actually does:

<p class="typo">The fine details of screen typography can be improved with JS-scripts and CSS.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

Our sample text rendered with Georgia and browser-native typographic features.

In this text, we want to find all-uppercase words.

The code starts by getting all elements of a user-chosen class, in this case .typo. These elements are stored in an array.

mainArray[0] = 'The fine details of screen typography can be improved with JS-scripts and CSS.';
mainArray[1] = 'That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011';

Each array element is then looped one at a time and split into a sub-array containing each word as a string.

subArray[0] = 'The';
subArray[1] = 'fine';
subArray[2] = 'details';
subArray[3] = 'of';
subArray[4] = 'screen';
subArray[5] = 'typography';
subArray[6] = 'can';
subArray[7] = 'be';
subArray[8] = 'improved';
subArray[9] = 'with';
subArray[10] = 'JS-scripts';
subArray[11] = 'and';
subArray[12] = 'CSS.';

Each item in the sub-array is tested to see whether the character count of the word and the count of the uppercase letters (ASCII values between 65 and 90) are equal. If so, the word is treated as an uppercase abbreviation.

The test actually checks the first and last character of the sub-array item. If they are uppercase, then it is fair to assume that the whole word is an uppercase abbreviation, and then we would run a more specific test. Here is what the script returns from our sample text:

  • “The” = false (do not run specific test)
  • “details” = false (do not run specific test)
  • “Andreas” = false (do not run specific test)
  • “CSS.” = true (run specific test)
  • “JS-scripts” = true (run specific test)

As you can see, the test also spots uppercase words when they are used with a hyphen or have an trailing period.

Our special uppercase test creates an index array that holds the indexes of the uppercase words (i.e. it identifies where in the full sentence they occur). After the whole sub-array is tested, we would have the sub-array and the index array containing the all-uppercase indexes.

indexArray[0] = '10';
indexArray[1] = '12';

Now that we know where all of the uppercase words are in the string (i.e. sentence), we can prepare them for small-caps replacement.

Small-caps replacement is done by extracting the word, converting the letters to lowercase, wrapping the whole word in an abbr tag and inserting it into the sub-array again.

subArray[0] = 'The';
subArray[1] = 'fine';
subArray[2] = 'details';
subArray[3] = 'of';
subArray[4] = 'screen';
subArray[5] = 'typography';
subArray[6] = 'can';
subArray[7] = 'be';
subArray[8] = 'improved';
subArray[9] = 'with';
subArray[10] = 'js-scripts';
subArray[11] = 'and';
subArray[12] = 'css.';

Now we only need to convert that array into a string and replace the original HTML element with the new small-caps-ified HTML element.

Before:

<p class="typo">The fine details of screen typography can be improved with JS-scripts and CSS.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

After:

<p class="typo">The fine details of screen typography can be improved with js-scripts and css.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

Our sample text set with Tanger Serif from Typolar, using the @font-face rule. Uppercase words are now wrapped in abbr tags.

Nice and neat. Now for the second part of the script, the one that replaces quotation marks, ligatures, en and em dashes, and ellipses; renders characters such as © in superscript; and converts numerals to old style by wrapping them in a user-defined class.

The code is fairly self-explanatory:

var charReplacements = function() {

/* Quotationmarks
‹ = ‹
› = ›
« = «
» = »
‘ = ‘
’ = ’
“ = “
” = ”
*/

var quoteCharClose = "»";
var quoteCharOpen = "«";
var triggerID = "#display";
var smallcapsClass = "old-style"

$(triggerID).each(function() {
$(this).find('*').each(function() {
	if (($(this).html()) != 0) {
		if (($(this).find('img').length) === 0) {
		// Performs replaces on any element that is not an

	  	$(this).html( $(this).html().replace(/(\.\.\.(\.)?)|(\.\s\.\s(\.\s)?|(\.\.(\.)?))/g, "…"));
		// Finds and replaces .. | ... | .... with an elipsis

		$(this).html( $(this).html().replace(/fl/g, "fl"));
		// Replaces fl with ligature

		$(this).html( $(this).html().replace(/fi/g, "fi"));
		// Replaces fi with ligature

		$(this).html( $(this).html().replace(/\s-\s/g, " ‒ "));
		// Replaces | space en-dash space | with: | space em-dash space |

    		$(this).html( $(this).html().replace(/"([\s\.\,])/g, quoteCharClose + "$1"));
		// Replaces | " space | with | » space |

		$(this).html( $(this).html().replace(/\s"/g, " " +  quoteCharOpen));
		// Replaces | space " | with | space « |

		$(this).html( $(this).html().replace(/(\d+)(?=((?!).)*(-tag with the .old-style-class but ignores digits within a a-tag. Read full explanation here http://www.phpbuilder.com/board/archive/index.php/t-10221442.html

		if ( (($(this).children().length) === 0) || ($('this:contains("u00a9")')) ) {

			$(this).html( $(this).html().replace(/\u00a9/g, "

©

") );
			// Superscripts (c)

			$(this).html( $(this).html().replace(/\u00ae/g, "

®

") );
			// Superscripts (R)
		};
	};
   };

});
});
};

Most of the typographic details in the script are declared in the variables at the beginning. This is the beginning of a “settings” type of solution that we are working towards building.

”Settings” is a pretty important feature because typographic rules change depending on the language; for example, quotation marks and the spacing of em dashes. English, French and German each use different quotation marks, so the designer needs to be able to easily change the typographic settings.

Now we have pretty decent typography in our example:

<p class="typo">The fine details of screen typography can be improved with js-scripts and css.</p>

<p class="typo">That is the goal of «Typesetter.js» — an open-source solution by Andreas Carlsson and Jaan Orvet

©

 2011</p>

Our sample text with much better micro-typography than what the browser supports natively.

We have covered a lot, but the most important part is still to come!

2. The Custom Font File

Let’s move on to the font file itself.

Putting Small-Caps and Old-Style Numerals in Place

Our text is now wrapped in classes; we can use CSS to set it in small-caps and old-style numerals. Since no browser supports OpenType, we cannot use the regular font-variant: small-caps rule, because this would only shrink the uppercase letters, resulting in thinner and lighter characters.

The font-variant: small-caps rule merely shrinks uppercase letters, resulting in thinner and lighter characters. To get real small-caps, we have to use our custom subsetted font file.

The font file we need is a subset of the regular cut; in it, the uppercase characters have been replaced with small-caps characters, and the lining numerals have been replaced with old-style numerals. (Remember the days of “expert set fonts”? It’s a bit like that. If you don’t remember, you’re better off for it.)

We can now specify in our CSS files to use the subset for abbr tags. This will give us true small-caps on the Web and allow us to choose between old-style and lining numerals in our text.

abbr {
   font-family: "Tanger Serif Expert", Cambria, Georgia, serif;
   letter-spacing: 0.15em;
   text-transform: lowercase;
   font-variant: small-caps;
   font-weight: 650;
}

Get the Font File

Fontdeck supports the OpenTypography project by kindly serving subsetted fonts in addition to its main fonts.

Other type services and foundries make subsets available as well. We keep an updated list with examples at OpenTypography.

Create Your Own Font File

If you have experience working with fonts, then creating your own subsetted font files is fairly straightforward.

Open the regular cut in your favorite font editor. Copy the small-caps glyphs, and paste them where the uppercase and lowercase glyphs are. Copy the old-style numerals to where the lining numerals are. Once this is done, you only have to generate a new font file and convert it to all the required Web font formats: TTF, OTF, WOFF, EOT, SVG.

You can easily create your own subsetted custom font file. Just replace uppercase and lowercase glyphs with the small-caps versions and the lining numerals with the old-style ones.

Now you have your own custom Web font ready to be used with Typesetter.js

But be sure to check the license to make sure you are permitted to adjust the font file and to embed it via the @font-face selector.

Get Involved In The Future Of Typesetter.js

We are currently testing Typesetter.js in our Dropbox- and Markdown-based CMS, Skrivr, but Typesetter.js is at a very early stage and needs more development in order to work seamlessly with all of the great things that the Web and digital-screen community is creating.

Mainly, we want it to be faster. Another question we’re facing is whether to use RegEx or not. Also, how do we create a better solution for targeting parts of the DOM and isolating those that shouldn’t be replaced?

You’ll find all the latest information, examples, code and more at OpenTypography, which is also the best place to get in touch and let us know if you are interested in bringing better typography to the screens around us.

(al)

© Andreas Carlsson & Jaan Orvet for Smashing Magazine, 2012.

0
Your rating: None

Japanese typeface classification

Japanese type is largely dominated by two genres of typefaces which share a relationship of contrasting form and usage, much like that of serif and sans-serif.

Mincho typefaces, which are based on brushstrokes, have a highly modulated stroke-width and serif-like terminals. Like most serif faces designed before 1985, Mincho faces are difficult to use well on the web. Their delicate curves are shredded and blotted by screen resolution at small sizes.

Gothic typefaces are even closer in form to Latin sans-serifs than Mincho are to serifs. They have even stroke-widths, blunt terminals, and come in a wider range of weights. For all these reasons, they are often the better choice for web text.

Due in part to their construction, Mincho and Gothic are used differently off the web as well. Mincho faces are used more often for general-audience publications such as newspapers. Mincho is also used for most book-length texts. Gothics are used more often in technical, explanatory documents, magazines, and text intended for a younger audience. Gothics are also used for captions since they can be set legibly at smaller sizes.

HTML fonts

While you may feel limited by the Chocolate, Strawberry, Vanilla selection of fonts available for English body text on the web, you will soon be pining away about the finer points of Verdana and Georgia.

To start, you can forget about italics and boldfaces. Italics are not a natural part of the Japanese language, and any attempt to italicize Japanese will be neither attractive nor legible. Bold faces, while not improper, do not display as bold on some systems. This becomes especially problematic when Latin type is mixed in the line, since that will display bold, adding unintended emphasis.

There are also only a few reliably available Japanese system fonts available, and not a single are shared by Windows and Macintosh. The most common choices for body text are MS Gothic for Windows and Osaka for pre-10.x Macintosh. Windows also includes MS Mincho, though the stroke width is rendered evenly at all but the largest sizes because of pixelization. OS X and Windows XP include other options and the luxury of anti-aliasing, but penetration of these operating systems is still modest.

Comparison Chart of Japanese HTML fonts and sizes.

3
Your rating: None Average: 3 (1 vote)

Web typography used to be something of an oxymoron, but recent browser advances and tools like Typekit have helped bring web typography out of the dark ages with custom fonts. Thanks to JavaScript libraries like Lettering.js you can tweak those custom fonts — targeting specific words or letters — and adjust them to your liking.

Lettering.js even makes it possible to do custom kerning on the web. Kerning refers to the space between characters in proportional width fonts. CSS has long offered the letter-spacing property, but because it applies to an entire element — for example an h2 tag — what you’re really doing with letter-spacing is adjusting the tracking.

To actually control kerning you need to target each letter individually. Because Lettering.js can wrap each letter in your text with span tags, you can then target each span separately, adjusting the spacing of individual letters, or, kerning.

But, handy as Lettering.js is, tweaking the letter-spacing, hitting refresh, tweaking some more and so on is still a rather tedious way to improve your kerning. That’s why designer Brendan Stromberger created the Kern.js JavaScript bookmarklet. Used in conjunction with Lettering.js, Kern.js allows you to adjust kerning by simply selecting and dragging letters (or you can use the arrow keys). Kerning adjustments can be made in pixels or ems, so even you if you have a liquid layout there’s no reason you can’t get in on the kerning fun. Once you’ve got your kerning looking the way you’d like, just hit the “finish editing” button and Kern.js will spit out the necessary CSS to apply.

Kerning is admittedly a somewhat nerdy pursuit in a field that’s already pretty nerdy to begin with, but if you’ve developed an obsession with good looking typography, you know that there’s more to it than just dropping in some Typekit fonts. Thanks to Lettering.js and Kern.js, you can finally improve kerning on the web without the tedium of endless page refreshes.

See Also:

0
Your rating: None