The Future Of Screen Typography Is In Your Hands

Advertisement

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 OpenTypography31, 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() {

/* Quotation marks
‹ = ‹
› = ›
« = «
» = »
‘ = ‘
’ = ’
“ = “
” = ”
*/

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 <img alt="" />
	  	$(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, "<sup class=""sup"">©</sup>") );
			// Superscripts (c)

			$(this).html( $(this).html().replace(/u00ae/g, "<sup class=""sup"">®</sup>") );
			// 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 <sup class="sup">©</sup>

<span class="old-style">2011</span></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

Fontdeck2 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 OpenTypography31.

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, Skrivr4, 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 OpenTypography5, 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)

Footnotes

  1. 1 http://opentypography.org/
  2. 2 http://www.fontdeck.com
  3. 3 http://opentypography.org/
  4. 4 http://www.skrivr.com
  5. 5 http://opentypography.org

↑ Back to topShare on Twitter

Andreas Carlsson is a developer and typographer based in Linköping, Sweden. He is currently working on the Dropbox/Markdown based CMS Skrivr. Skrivr lets you save a text-file in you Dropbox and Skrivr turns it into a complete site. Since january 2012 Andreas works as Creative Director at Swedish-American digital agency Nansen. Follow him on Twitter where he is @nofont.   Jaan Orvet is the San Francisco based Head of Creative at Nansen since November 2011, and former UX & Design Director at Huddle. He is co-creator of Skrivr, believes in clarity and simplicity above all else and likes coffee quite a lot. He tweets as @orvet.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    I have no idea what this is about :( Does it mean I can´t simply type?

    • 2

      Features that OpenType has supported for years has never made it to the web in any real capacity. OpenTypography is aimed at offering these features in a simple, intuitive way via javascript.

      What it means is you now have a great tool available to improve typography on websites with minimal effort. It still needs a lot of work, but this is an important tool to have around.

      • 3

        Thank YOUUU! I came to your site to see if there were any new wallpapers (I was in deasprete need of something new) and there these were! I knew I could count on you!

    • 4

      Adam, keep typing as usual :-)

      This only means that when your texts are published then this script will fix the typographic details so that people reading them will have a much better reading experience.

  2. 6

    I love screen typography and the efforts being done to enhance it and make it fully usable. But what pains me the most is that even the most celebrated web designers do not pay any attention to proper contrast in their font colors and go on to select high contrast text fonts. In turn such shoddy, unreadable text goes on to win accolades among other designers and CSS galleries. Which sets an unwanted precedence.

    We need to take a step back, and first make text on the web readable in its current form. Otherwise all our efforts to enhance typography are nothing but shots in the dark.

    In a sense, even the existence of apps like Readability in its purest form is an insult to the world of web designers.

    Sorry about the rant. Had to get it off somewhere. :)

  3. 7

    Interesting idea.

    I’ll bet if you grab the nearest book with handcrafted typography and look at its copyright page, you’ll find the copyright symbol on the baseline, not superscripted.

    • 8

      I believe that depends on the size the font is set at. In print, 8 pt. and below would be considered “fine print”. Superscript-ing an already small font size would annihilate legibility. Thus, setting it at the same size and on the baseline. Similar to the philosophy of using old-style numerals in body copy so that they imitate the surrounding text, maintaining the flow of the type while remaining legible.

      But, yes, you are right. Most of the copyright symbols on the copyright pages of the design and typography books that I checked do sit on the baseline. Great observation! There’s that attention to detail that we’re so know for ;-)

  4. 9

    We also need better control of leading, such as the ability to specify where line-height space is applied, i.e. not always evenly top and bottom of the text. It makes aligning columns with different type sizes a pain.

  5. 10

    Looks like a very promising start. I certainly think regular expressions (RegEx) would dramatically improve the speed of such a solution. I was an editor and designer at a university press in the 1990s and am quite familiar with “expert” font sets. OpenType was the Holy Grail of typography then, bringing all of the supplemental font files into one that could provide all the typographic features we wanted. It would be nice if we didn’t have to go back to separate font files in order to provide decent typography on the web. How sad!

    • 11

      Glad you like the start of the project :-)

      No, I neighter don’t want the web to be flooded with home-made subsets and prefer the use of type services. But more than that the browser vendors to speed up the introduction of Open Type features.

  6. 12

    Javascript is a bad idea.
    Alternatives :
    – use text-rendering: optimizeLegibility; in your main CSS
    – do your strings operations server-side

    If you want to use Javascript anyway, perform all the operations on a copy of the string and update the DOM once.

    $(this).html( $(this).html().replace(/fl/g, “fl”));
    $(this).html( $(this).html().replace(/fi/g, “fi”));

    should be :
    var html, original_html;
    html = original_html = $(this).html;
    // perform strings operations offscreen
    html = html.replace(/fl/g, “fl”);
    html = html.replace(/fi/g, “fi”);
    // rendering : no need to perform DOM operation if no change was made
    if (html != original_html) $(this).html( html );

    I made a little benchmark (just one test case).
    The offline operations are about 10x faster than the original version.

    • 13

      Yes, yes, yes :-) this is exactly the kind of comment we were hoping for. Typesetter.js is just started and the goal is plant an idea, to push things one little step further, thinking that this is the ultimate solution would be stupid and naive. One of the big things we need to tackle is performance and you feedback is exactly the kind of feedback/input Typesetter needs.

      I really appreciate your benchmark and code examples.

      OptimizeLegibility would work great together with Typesetter.js but it won’t take care of microtypography in a broader way.

      I totally agree that the ideal would be to do it server side, and the wish is that people can take ideas, bits and pieces of the search/find thinking of Typesetter.js and develop it further and port it into .Net, php, rails, node or any other server side language as a complement to the Javascript version. But as I said earlier, this is a forst small step towards better typography on tje screen.

      I wish I could upvote this +10 :-)

    • 14

      I disagree that the replacements should be made server-side. JavaScript is (almost) globally available in client devices, while server software can be wildly different. They’d have to create several implementations of the script just to achieve a high penetration rate.

      Having said that, the JavaScript is indeed a little painful to look at. Your suggestion to do replacements off-screen and avoid repaints is incredibly important. The project does look interesting, so I would suggest the authors to open it up (say on Github) and let the open source community lend a hand. I would do so in a heartbeat, as I’m sure others far more talented than me would.

      • 15

        Hi Bruno!

        We are in the middle of translate all the inline comments from Swedish to English and then we will put it up on GitHub.

        I would love if you would get involved cos my javascript skills are limited as you can see :-)

        I’ll update the post with the GitHub url in a day or two.

    • 16

      I agree that this should be done on the server side too. Doing this in JS is an easy fix, but in the end brings a lag to the user experience. If the original text was “tagged” better in the first place, users could enjoy a clean experience with no hassle.

      I’m working on something that could benefit from this and would be interested in contributing to an open-sourced package of some sort…

    • 17

      Joey, here’s the GitHub url for the project, would love if you could help out with the code/performance if you have the time :-)

      http://github.com/nofont/Typesetter.js

    • 18

      What is jquery doing that is causing the perf drop? Is every character replacement triggering a re-insert of innerHTML?

  7. 19

    Are there any live examples of websites that are using Typesetter.js?

    I would love to see a demo, and not just rasterized images of the examples :)

  8. 22

    While I love the community support for better online typography, I fear that most all solutions for advanced type setting require JavaScript. It seems that most sites today are using an excessive amount of JavaScript as it is, from libraries like jQuery, to additional helper scripts to handle HTML5 rendering in pre-modern web browsers. We’re adding more and more http requests and thusly increasing initial page load times.

    This may be considered as fine for the desktop environment where the majority of users are on broadband connections. But what about mobile where the service may be spotty 3G coverage, or off shores users with slower load times depending on location from the server?

    It would seem that the perfect solution is better browser support. Though that may be a eutopia solution. I applaud the effort here, I just feel that with more and more JavaScript we will run into more load time issues making our content equally inaccessible as flash of the old days…

    • 23

      Chris, please see my other responses on the performance and javascript stuff :-)

      The actual choice of javascript is secondary, the primary goal is to automate the task of finding and “tagging” the typographic details in a text so that it can be “treated” via css.

  9. 24

    Kudos to you for recognizing the problem with onscreen typography – that it still in most cases comes nowhere near supporting typographic features which have developed for print over the 550 years since Gutenberg, in order to make reading easier and more comfortable.

    I agree, we absolutely do need to tackle this issue to move onscreen typography forward.

    The problem with this solution is speed, or rather, lack of it. Indeed, the authors themselves identify “making it faster” as one of the major tasks to be undertaken. Problem is that no matter how fast you make the .js execute, screen rendering will be a bottleneck.

    Just turning on “optimize legibility”, for instance, can slow down rendering by as much as 10x – at least it did last year when I was working on a project and was methodically measuring rendering times for eBooks with a stop-watch. It is possible to speed this up, but only with major effort in the browser, and the extent of the potential improvement in rendering times is unclear. I cannot believe that a .js solution will be faster than .

    The good news is that even a huge 10x hit is fairly invisible to the reader if you are rendering a short page. But if you are rendering an eBook, for instance, be prepared to wait for a minute or more for all the pages to render just so you can navigate to the right page.

    I’ve been working with personal computer typography since 1984. Speed has always been an iissue. However, it was less of a problem if you – the page creator – had to cope with rendering wait times. You took the rendering pain, but the reader did not, because you were delivering fully-rendered print. Print-quality typography onscreen means that pain is passed directly to the reader.

    Solutions like this one are good in that they do offer a hack which works for shorter content. And they do illustrate the tasks which browsers need to handle, and which are not today receiving the investment of effort they require. However, add in the additional – and equally essential – requirement to do proper hyphenation and justification of text, and watch render times climb to totally unacceptable levels.

    First thing for the Web to realize is that all of the features in your .js, plus great H&J, are not luxuries, they’re essential requirements for onscreen text in the 21st Century. All of the browsers and other rendering engines need to be able to handle them.

    Computing power needs to improve – especially graphics rendering – in order to be able to handle the load at speeds which are transparent to the reader.

    I have often heard people say that computers are powerful enough already – why do we need more power and speed? This is why. The continually-improving speed of data transmission on the Web is irrelevant if local rendering time is not improved by at least an order of magnitude. The fastest, smoothest freeway drive can be spoiled if you have to wait in a long line to pass through a toll booth at the end of it.

    Sorry to be so negative. Slapping on a JavaScript Band-Aid is only OK in the Wright Brothers phase, when biplanes were held together with string and sealing wax. It’s not the fast, crash-free air travel we need to be able to depend upon. But it’s a start.

    • 25

      I don’t think your comment is nagative at all. It focuses on very real issues that we have with rendering content in browsers and the performance it takes.

      We are very aware that javascript is not a long-term solution. But this is the first step.

      The core idea of Typesetter.js is not to create another plugin/framework in js. The whole idea is to find an automated way of finding text/language patterns and wrap them in tags/html. Currently it’s beeing done with javascript but it can and must be done in serverside languages as well for the resons you mention above.

      The exact same solution in php would render an article in html that would include abbr-tags and the lot of typographic features from Typesetter.js. That would be much faster and that would remove the rendering time from the reader.

      As you say, this is essential stuff when we have hidef screens and type services like Fontdeck serving small caps as subsetted fonts.

      And that is why we need to push development further.

      • 26

        I’m a developer, but having read Elements of Typographic Style in preparation for publishing my e-book, my eyes were opened. Why is the web 500 years behind? It’s sad that only now this is being implemented in JS. Why weren’t the typographic pundits yelling and screaming for this 5, 10, 15 years ago?

  10. 27

    I forgot to mention pagination. The sooner the Web realizes that pagination is important, and that the simplistic solution of the bottomless scrolling window which the first browser engineers adopted for expediency reasons means the reading experience will continue to be sub-optimal, the better. Still more local computing load, since pagination needs to optimize for size of screen. And let’s not forget that if the reader wants larger or smaller type as a personal preference, that’s a whole fresh rendering pass.

  11. 28

    I’m going to use this / convert to a node.js app and include as a pre deploy build script.

    Sever side is the right way to do it.

  12. 29

    This may be one of the most confusing things I’ve ever skimmed.

  13. 30

    Isn’t it fun reading an article about screen typography where images’ captions are made that messy way when you should look at them for few times to compare and understand what goes where? Section “TIME TO FIX THE PROBLEM” — that’s what I’m talking about.

    Also, caption under the image it has to be related to is really bad, especially on screen. Or, at least, please consider the rule stating that there should be less space between the caption and its “captioned content” than between caption and something unrelated like the previous paragraph or image or whatever.

    Sorry to be boring and somewhat off-topic.

  14. 31

    Looks really promising. Is there a way to stay up-to-date on progress?

  15. 34

    I agree that typography on the Web needs to move forward. I have some reservations about this method, though.

    First of all, you’re replacing the actual content for visual effect. It’s fine to introduce real ellipses, dashes and quotation marks, since those serve a purpose, but substituting ligatures within the text itself breaks at least search and copy/pasting. That’s why the best solution is to let the browser take care of such minutiae.

    Speaking of browsers: Firefox, for one, has supported OpenType features for a long time. It automatically uses ligatures where appropriate. Other features can be activated by the designer using CSS.[1] I guess other browsers don’t feel it’s important enough, as yet.

    You’re unnecessarily changing the meaning of the content again when it comes to abbreviations. Why do you lowercase them just for the sake of small caps? And what happens if all I’m doing is SHOUTING (which is unfortunately such a common convention)? What about abbreviations and acronyms that I’ve already correctly marked up?

    I don’t understand why you’re wrapping ®, © and ™ in ‘sup’. Isn’t it upto the font to decide how to render those glyphs?

    You’re blindly replacing all hyphen-minuses with en dashes. What about ‘font-family’ and ‘-10’ (which ought to be ‘−10’)?

    Using custom font subsets for OpenType features… I don’t even know where to begin. You’re not seriously saying everyone should create their own subsets of the fonts they use to get slightly better small caps and be able to choose between old-style & lining numerals, are you?

    Finally, the JS could use some work. I have a few suggestions on that front. Cache the result of $(this) instead of calling it again and again. Look for /(w+)/ to find words; that way, you won’t have to worry about leading or trailing punctuation, or hyphenated words. Use /s*(.s*){2,4}/ to find ellipses. Perform all your replacements offscreen, then update the HTML, rather than repeating the replace/update cycle over and over again, as other commenters have mentioned. If you insist on making characters superscript, you can do it one shot: foo.replace(/([®©™])/g, “$1″)

    • 35

      … substituting ligatures within the text itself breaks at least search and copy/pasting. That’s why the best solution is to let the browser take care of such minutiae.

      Yes, letting the browser do this is by far the best solution, but currently there is no widespread browser support for it. Firefox has it. You can get it in Safari but that’s about it. But IE 10 will have pretty good Open Type support. Although I have’nt read the spec yet.

      … Why do you lowercase them just for the sake of small caps? And what happens if all I’m doing is SHOUTING (which is unfortunately such a common convention)? What about abbreviations and acronyms that I’ve already correctly marked up?

      The reason they are lowercased is because some subestted fonts contains uppercase glyphs in the uppercase positions. And that’s why they are changed into lowercase to make sure small caps are used. But it’s an easy thing to add this to the Typesetter.js settings so that you can choose not to have them converted to lowercase depending on the font you are using.

      You should not SHOUT, typographically you shout.

      I don’t understand why you’re wrapping ®, © and ™ in ‘sup’. Isn’t it upto the font to decide how to render those glyphs?

      It is equally up to the publisher/typographer/designer to decide how to render them.

      You’re blindly replacing all hyphen-minuses with en dashes. What about ‘font-family’ and ‘-10’ (which ought to be ‘−10’)?

      Currently yes. But that’s a tricky part to solve. In an ideal world the solution would have some king of language “intelligence” and detect the context of the hyphen-minus and replace it or leave it. But that’s a damn hard thing to solve.

      Using custom font subsets for OpenType features… I don’t even know where to begin. You’re not seriously saying everyone should create their own subsets of the fonts they use to get slightly better small caps and be able to choose between old-style & lining numerals, are you?

      Yes, we are very very serious about the subsetting. But we are not saying everyone should do their own font-files, that would flood the web with defunct font-files. We prefer that type services like Fontdeck or Typekit serve the subsetted files until there is a wider/better support for the Open Type format in all modern browsers.

      We are even more serious about the subsetting when it comes to e-books and longer texts/digital literature. Then it’s even more important to get the typographic details right.

      But, please note that as soon as there is wider OT support there won’t be any need for the additional subsetted font files.

      Finally, the JS could use some work.

      Yes, and I really really appreciate your additions/tips. They are exactly what this project needs.

      • 36

        [Dunno what markup is allowed here; time to find out!]

        Yes, letting the browser do this is by far the best solution, but currently there is no widespread browser support for it. Firefox has it. You can get it in Safari but that’s about it. But IE 10 will have pretty good Open Type support. Although I have’nt read the spec yet.

        I know that, and as I’ve already said, I agree with better typography as long as it doesn’t change the meaning of the content, the way that the script does when it swaps in ligatures.

        The reason they are lowercased is because some subestted fonts contains uppercase glyphs in the uppercase positions. And that’s why they are changed into lowercase to make sure small caps are used. But it’s an easy thing to add this to the Typesetter.js settings so that you can choose not to have them converted to lowercase depending on the font you are using.

        Alright, fair enough. However, bear in mind what DjKav said below about acronyms vs. abbreviations.

        You should not SHOUT, typographically you shout.

        Like I said, SHOUTING is, unfortunately, a common convention. It’ll come up anywhere user-generated content is a factor. It’s not one I use personally when there are alternatives.

        It is equally up to the publisher/typographer/designer to decide how to render them.

        Okay. I’ll defer to your expertise on this head.

        Currently yes. But that’s a tricky part to solve. In an ideal world the solution would have some king of language “intelligence” and detect the context of the hyphen-minus and replace it or leave it. But that’s a damn hard thing to solve.

        Indeed… and meanwhile, you have a lot of false positives. Not just for hyphen-minuses but for everything you work with. For example, you’ll end up turning ‘type “cd ../foo-bar/BAZ/” at the prompt and press Enter’ into ‘type “cd …/foo–bar/<abbr>BAZ</abbr>” at the prompt and press Enter’. I suppose whether that’s acceptable is upto the end-user to decide.

        Yes, we are very very serious about the subsetting. But we are not saying everyone should do their own font-files, that would flood the web with defunct font-files. We prefer that type services like Fontdeck or Typekit serve the subsetted files until there is a wider/better support for the Open Type format in all modern browsers.

        I see.

        We are even more serious about the subsetting when it comes to e-books and longer texts/digital literature. Then it’s even more important to get the typographic details right.

        But, please note that as soon as there is wider OT support there won’t be any need for the additional subsetted font files.

        This still feels like the wrong solution to me, but at the same time I can appreciate that things aren’t moving fast enough on the browser front. Maybe I just need to lump it.

        Yes, and I really really appreciate your additions/tips. They are exactly what this project needs.

        Glad I could provide at least some constructive criticism. ;-)

    • 37

      Aankhen, please contribute with your JS skills. The project would really need it. You’ll find the repo here: http://github.com/nofont/Typesetter.js

  16. 38

    The number of times you manipulate the DOM looks really inefficient, maybe try only rewriting the content once.

  17. 39

    I think there needs to be developed some good “InDesign” for typesetting on web. I think there are only few lets say web programmers that can not only can not only appretiate, but also rather understand needs of it. So to start this “revolution” there must be some user freindly interface first for us – normal people without programming knowledge – i can imagine better editors in CMS systems able to work this out. So people which know something about typography can use it in user friendly way. Only this can widespread good web typography globaly. /sorry for my english/ Jan

  18. 40

    I like the idea but not the JavaScript quality. Though I‘m not an expert on JS and JQuery, I have some knowledge that helps me write JS/JQuery widget and many code to some extend.

    So, as one said, the performance is not ideal in this code.

    I also don’t quite understand it. I created my own Polish-typography keyboard layout with all typography goodies. So I can type en, em dashes, ellipsis, typographic quotation marks like „this” (as we use in Poland), ’this’ or «this» ones and others typographic characters with no effort.

    What I like is automatic replacement of ligatures and small caps and would like to embrace this idea in my next project… ← true ellipses :D

    Anyway, I wish you all the best!

  19. 41

    This seems like a bad idea, using Javascript. It’s a waste of resources; something like this should be done right the first time, not on-the-fly. I agree with Joey that if anything the documents should be processed server-side and then cached–that way it only needs to be processed once and not every time.

  20. 42

    I had to lookup the definition of ligature.

    After learning what it is, I’m guessing a [ctrl]+f for any word containing the “ligature” representation would never match what you type on the keyboard?

    How do you reconcile with those who want to use a keyboard to find text and those who want to read text you can’t type using a keyboard?

    • 43

      Browser support is an interesting problem. I just checked this page in Chrome, Firefox, Safari, Opera, and IE9, to see how they handled the ellipsis character: whether a search for ‘…’ (three full stops) would find it. Surprisingly, only Chrome and Safari worked in this way. If searchability is more important to you than typography, then I think it makes sense to just use regular characters – it might even affect your rankings with search engines, if they aren’t written to support ligatures either.

      However, like a lot of things on the web, there’s a problem where the browsers don’t support a feature because nobody uses it, and nobody uses it because the feature is poorly supported. Making ligatures searchable is a problem for the web browser to deal with, and they’ll start supporting it more and sooner if the demand is there.

      Personally, I know very little about typography, and I don’t see that there is much of a difference in using or not using ligatures. But better browser support is still a positive step, as designers shouldn’t have to worry about this sort of thing.

      • 44

        Yes, designers shouldn’t have to worry about this sort of thing—browsers should be automatically substituting the ligatures for display, rather than content authors forcing the issue and mangling the content itself. On the other hand, in the case of ellipses, dashes, and other punctuation, it makes sense to put the right characters directly in the content as they affect the meaning of the text.

        IOW, making ligatures searchable is not ‘a problem for the browser to deal with’. Automatically rendering them where appropriate /is/.

  21. 45

    Why the slow and bulky js when all (and more) these features will be supported natively in the nearest future?

  22. 46

    This is a great project. Anything to help get better typography on the web. On a happy note, more browsers are picking up on the OpenType features – Internet Explorer 10 Preview 4 also implements Opentype features and Chrome (on Windows only) (I can’t find a reference but I remember reading it recently). So it’s slowly catching on with browsers.

  23. 47

    In the English language, abbreviations are generally long words shortened by the use of an apostrophe mid-word or a full stop at the end. Eg., “Can’t meaning cannot, or approx. meaning approximately.”

    I think you refer to acronyms, eg., CSS. Acronyms themselves are capitalised, as they usually represent a group of words. I wouldn’t create a rule to convert acronyms lowercase, as this is not the English language rule.

  24. 48

    I wonder if a script like this would be a good test case for using HTML5 web workers? I know web worker scripts don’t have access to the DOM, but maybe you can just pass it the text to work on then have it return specific changes. It’s just a thought, I think it’d be fun to start messing around with some of the new HTML5 toys ;)

  25. 49

    WordPress handles some of these concerns automatically. See the wptexturize() function http://codex.wordpress.org/Function_Reference/wptexturize

    It’s nice to have tools to do the right thing for you without even needing to think about it.

  26. 50

    Hi!

    It is great that you are trying to improve the web typography. Unfortunately most of the corrections should not be done at the rendering stage but by the editor (with help of the text editor).

    Look at the text processing software. All corrections and replacements are made during typing – dashes, quotation marks etc are replaced automatically. Other fine tunings are always made by the editor manually. If the editing software replaces a character the editor always can restore the original one (for example if he really wants to use the en dash).

    If a page needs a good typography then the editor should have proper knowledge of typography issues. Just like in print – the results will not be very good if the editor does not have proper skills.

  27. 51

    Very nice work indeed.
    I would like to bring to your attention following use-case. Longer documents are sometimes/often navigated with the help of browser’s build in search function. After cleaning the typography with the code above will it still be possible to look for the word, … say “difference”? It seems it will not be found as the “ff” will be gone.

↑ Back to top