Fortes

Introducing Treesaver

2010-08-15T17:32:27Z

The word is out about my latest venture: Treesaver. Nomad Editions is our first customer to make a public announcement, you can see their promotional video below:

The response and interest so far has been fantastic, and it's great to finally be able to talk about what I've been working on for the past several months.

We've been getting a ton of questions, and I thought I'd take some time to answer the most common ones.

What is Treesaver?

It's a way to make column and page-based layouts using HTML, CSS, and JavaScript. Text and image layout is tailored to fit whatever screen the user is using, in order to create a attractive, usable experience. Here's a video demonstrating how Treesaver adapts to a changing window size:

Why use HTML?

There are many reasons to use HTML, but the most important ones in our opinion are:

Lingua Franca of the Internet: HTML is supported by an incredible variety of devices, from expensive desktop computers to cheap mobile phones.
Linking & Search Engines: Articles within Treesaver websites have their own URL which can be linked to or spidered by search engines. Users searching in Google can be taken directly into the rich Treesaver experience.
Bookmarking & Social Media: Because Treesaver can run in the browser, users can bookmark and directly link to articles when sharing with friends. Friends and Family can immediately view shared content in a rich experience without having to go to an app store to download a viewer.
Leverage existing content: Treesaver articles are simply-structured HTML files, meaning little to no conversion is required for existing text content. Existing web assets like video and Flash can continue to be embedded (assuming the browser/device supports Flash, of course).
Ecosystem: Because Treesaver is built upon standard technologies, it can leverage the wide variety of tools available in the web ecosystem: Google Analytics, embedded YouTube videos, slideshow widgets, etc.
Embedding: You can embed a Treesaver article within other webpages, as you would a YouTube video. Embedded articles continue to be formatted by Treesaver, meaning branding and advertising are preserved, even if the article has been embedded on another site.

What are Treesaver's Browser/Device Requirements?

The column and page-based layout works on most modern browsers, specifically:

Internet Explorer 7 and above
Firefox 2.0 and above
Safari 3 and above (including iPhone, iPad, and many smart phones)
Chrome 3 and above
Opera 10 and above

Because Treesaver content is just HTML, it degrades gracefully onto legacy devices. Users with IE6 or older phones will still be able to read any article that uses Treesaver, although it will have a simpler, primarily text layout.

Can Treesaver content be distributed via the App Store?

Yes. We will provide the ability to package Treesaver content as an application that can be downloaded and sold through the App Store.

When can I use Treesaver?

We're not giving public access to Treesaver right now, although we will be doing a limited beta test in the coming weeks. Subscribe to the Treesaver mailing list to be notified when beta invites are ready to be sent out.

I'm interested in using Treesaver for my publication, how do I get in touch?

Will Treesaver be Open Source?

Yes. I'll be releasing the client libraries Treesaver under an open source license later this year (it's not quite ready yet, I have to remove all the dirty words first).

Got any Screenshots?

Sure, here are a few from a Nomad Editions sample issue:

Treesaver Sneak Peek

2010-08-07T00:55:32Z

Treesaver sneak peek video

Coming Soon

2010-07-27T17:16:03Z

Soft Hyphenator

2010-02-14T21:45:59Z

I'm happy to announce Soft Hyphenator , a simple utility I wrote this weekend that adds soft hyphens into HTML content.

Today's web browsers don't provide hyphenation, which makes justified text prone to rivers of white space. However, browsers do support the soft-hyphen: the  HTML entity. Soft hyphens tell the browser where it can break a word, if necessary.

Adding these hyphens manually is quite tedious. The Soft Hyphenator takes HTML and adds the soft hyphens automatically.

The site is written in Python and deployed on Google AppEngine. It uses the BeautifulSoup and python-hyphenator libraries, along with OpenOffice's hyphenation dictionaries. For the nerdy & curious, I've made the source code public.

I'm still quite new to Python and Google AppEngine, but I'm pretty happy with both so far. The entire site took less than 24 hours to write, and WTF/minute rate was pretty good.

jMetronome: Using jQuery to keep typographic rhythm

2010-02-12T15:36:28Z

A couple of years ago, Richard Rutter wrote Compose to a Vertical Rhythm, which described how web developers could use CSS to maintain proper vertical typographic rhythm when designing pages. The technique is fairly straightforward, requiring some basic math to ensure consistent margins and leading across all page elements.

One issue that many people face with this technique, is that vertical rhythm can easily be thrown off by non-text elements, such as images. To illustrate, here's a sample page which contains text, images, a code block showing a horizontal scrollbar, and even a video. Notice how the text no longer lines up perfectly within the vertical grid lines after the first image. This is because the image is 240 pixels tall, which is not a multiple of 18, the line height used throughout the document.

One solution to this issue is to make sure your images always have a height that is a multiple of the line height being used by your document. Unfortunately, this is usually not practical for production sites.

Here's some jQuery code that you can use in order to make sure your document keeps its rhythm:

$(function() {
  var lineHeight = parseInt($('body').css('line-height'));
  function balanceHeight(el) {
      var h = $(el).outerHeight();
      var delta = h % lineHeight;
      if (delta != 0)
      {
        /* For images and objects, we want to align the bottom w/ the baseline, so we
         * pad the top of the element. For other elements (text elements that have a
         * scrollbar), we pad the bottom, to keep the text within on the same baseline */
        var paddingDirection = ($(el).is('img') || $(el).is('object')) ?
                                              'padding-top' : 'padding-bottom';

        /* Adjust padding, because margin can get collapsed and cause uneven spacing */
          var currentPadding = parseInt($(el).css(paddingDirection));
          $(el).css(paddingDirection, currentPadding + lineHeight - delta);
      }
  }

  /* Depending on your content, you may want to modify which elements you want to adjust,
   * by modifying the selector used below. By default, we grab all img, pre, and object
   * elements. */
  $('img, pre, object').each(function() {
      /* Only works if we're manipulating block objects */
      if ($(this).css('display') == 'inline')
      {
          $(this).css('display', 'block');
      }

      /* Images need to load before you get their height */
      if ($(this).is('img'))
      {
          $(this).load(function(){ balanceHeight(this); });
      }
      else
      {
          balanceHeight(this);
      }
  });
});

The code is fairly straightforward. Briefly, what it does is add padding to the top or bottom of an element in order to ensure its total height is a multiple of the document's overall line height. Here's the same sample page as before, but this time using the script above.

Usage

You can use this script as-is, but you may want to change the selector used in the following line:

$('img, pre, object').each(function() {

The reason is that this selector is probably too broad for your page. You most likely do not want to adjust every single image on your page, just the ones within your main content block. On my page, I adjust any pre elements, because I've set them to overflow with scrollbars, which can alter the height of the code block and mess up vertical spacing just like an image.

Known Issues

I've only found two issues with the code, and they both affect Internet Explorer:

object tags don't get adjusted (see the Vimeo video at the bottom of the sample page). This might be a jQuery issue, but I haven't investigated it yet.
If you use unitless line heights, jQuery doesn't retrieve the correct line height in IE. You can either modify the code and hard code a line height, or just don't use unitless line height on the body element

Let me know if you run into any other issues.

Introducing the Dynamic Layout Library

2010-02-12T15:36:28Z

I'm happy to introduce version 1.0 of my Dynamic Layout JavaScript library.

Dynamic Layout is a simple library that allows you to easily adjust page layout based on the current browser width.

The script works by modifying the class property on the body element, adding a new class name that will look something like bw-1000, where 1000 is one of the numbers in a predefined list of possible browser widths.

Unless you're reading this in your RSS reader, you can see a live demo by resizing your browser window. I've also created a simple multi-column demo, which will display one, two, or three columns depending on your browser width.

To download, and for details, see the Dynamic Layout project page.

Introducing Sistr

2010-02-13T18:33:39Z

Over the weekend I spent some time seeing if I could replicate the functionality found in the excellent sIFR, using Silverlight instead of Flash. The result is Sistr. For the impatient -- here's a demo test page.

Note: This definitely isn't ready for a production site, this is an early version for feedback purposes only. There are still plenty of bugs, trust me.

Usage

Download sistr.js and save it to your web server (or reference it directly from this site).
Create a zip file with the font(s) you wish to use. Upload this to your webserver as well (Silverlight will only use fonts that are retrieved via HTTP).

Add the following into your HTML page:

<script type="text/javascript" src="sistr.js"></script>

In your CSS file, define a new class called sistr-replace (anything that starts with "sistr-" works). Here's an example:
```
.sistr-replace { }
```
Use the font-family property to set the font name and URL to the font files, enclose them in quotes and separate with the "|" character (e.g. font-family: "Fil's Font|filfont.zip"). Make sure you also specify backup fonts for users who don't have Silverlight installed, like so:
```
.sistr-replace { font-family: "FontName|fonts.zip", Verdana, Arial, Sans-Serif; }
```
Set the class property on some of your HTML elements to sistr-replace (or whatever else you used) and re-load. For example:
```
<h3 class="entry-title sistr-replace">Hello World!</h3>
```
Your text should now be rendered using Silverlight.

Take a look at the demo test page as well.

Pros & Cons vs. sIFR

Pro:

Simpler setup: All you need to do is include the sistr.js file in your page and edit your CSS -- you do not need to edit any Silverlight or JavaScript code. sIFR is pretty easy too, but you need the Flash editing program in order to create a SWF file.
Support for Transparent Backgrounds: sIFR provides partial support, but it's not recommended within Firefox (I believe this is an issue with Flash).

Con:

Lack of Silverlight Install Base: Silverlight is nowhere near as common as Flash.
No protection for Font Files: In order to use a custom font with Silverlight, you have to have the font file available for download on a web server -- you cannot embed it or protect it in any way. This means you must use fonts that you either created or are liberally licensed (public domain, etc).
Immature: Both Flash and sIFR are much, much more mature than Silverlight and Sistr. There are many bugs that I have not sorted out yet.
Many limitations: See below

Known Issues

No support for line height: Limitation in Silverlight
Must use absolute units for font-size in IE: Due to IE's lack of a getComputedStyle equivalent.
Occasional sizing issues: I think this may be a Silverlight bug, but occasionally text will get cut off in the vertical direction. Not sure how to fix it yet
Font size doesn't respond to user changes: Works fine if you reload though
No support for :hover state
No support for nested hyperlinks
Text selection does not work: Not sure how screen readers react either
Cannot support nested bold in Firefox: Works in IE though

Let me know if you find others -- or want to help fix bugs!

Adobe OnAir Seattle

2010-02-12T15:36:30Z

I went to Adobe's OnAir Seattle yesterday, which was a really interesting event that I'd recommend attending if you have the time. Unfortunately, I had to leave before the end of the day, but here's a summary of the notes I took while I was there.

The Big Picture

Adobe's goal is to let web developers can use their existing skills (HTML, CSS, JavaScript, Flash, and Flex) to create desktop applications. AIR (formerly Apollo) provides cross-platform installation and application updates, a local database, and a variety of new APIs for managing local resources (local file access, controlling window chrome, drag and drop, etc). The Adobe guys were clear that this isn't about porting existing web sites onto the desktop -- assets and web services will obviously be re-used, but the emphasis was on not needing to learn new technologies (just a few new APIs).

Interesting Tidbits / Nerdy Technical Details

Installation: Applications are installed via a single .air file. Installed applications can be removed just like normal applications (i.e. via Add/Remove Programs on Windows, or by throwing the application in the trash on the Mac). An express install (which can bootstrap the AIR runtime) and detection is also possible via Flash.
Application Updates: AIR will provide support for automatic application update checking and upgrading.
HTML Rendering: Adobe chose the WebKit HTML engine (used by Safari and Konqueror) specifically because of it's size and speed. Someone asked if they were considering moving to Firefox at some point, and they were clear that Firefox just couldn't meet their size requirements for mobile.This cements WebKit's position as the number three browser family (sorry Opera).
PDF Support: Requires Adobe Reader 8.1 -- unlike HTML and Flash support, the Adobe Reader must be installed separately (I'm not sure what happens if it's not installed).
HTML / Flash Integration: It looks like Adobe's done a good job integrating the two -- you can make script calls between the two, and there don't appear to be any visual differences between the technologies. I'm not sure about PDF though, I'll need to look into that.
Script Engine: They're using the Tamarin JavaScript engine, which is far faster than what's in browsers today. They showed a demo of BuzzWord, a word-processing program built on Flash, which implements their own line layout and pagination APIs that run pretty fast thanks to the JS engine. The Mozilla team plans to use Tamarin in Firefox version 4.0.
SQLite: This must be fairly new, because none of the talks or demos I saw were using the local database. Adobe did mention that they're working with Google to make sure they're API-compatible with Google Gears, which also uses SQLite.
Native Windows: Can create native windows, or go chrome-less windows with transparency that give full-freedom (at the potential cost of consistency with other applications on that OS).
Plugin Support: Currently only Flash and PDF can be embedded within HTML. Adobe says they're open to feedback as far as other plugins (QuickTime was requested by a member of the audience).
SDK and Tools: Adobe already has mature tools with the Flash authoring environment, Flex builder, and Dreamweaver. They making sure to adding support for creating AIR packages (which are ZIP files) in their existing products, lowering the learning curve for developers. Command-line tools for packaging AIR files are provided as well.
Adoption Rates: Adobe made sure to mention how quickly new versions of Flash get adopted by users -- they get 85% penetration within 9 months, which is quite impressive. Obviously, it's unclear if AIR could get this
Linux Support: Planned in late 2008. Adobe says they've been waiting for the latest version of Flash for Linux before they port AIR.
Random Notes: Built-in support for associating file types at install time, don't need admin rights to install AIR or AIR applications, events for regaining network connection, file dialogs, drag and drop support, use PNGs instead of dealing with .ico files, and Creative Commons licensing for the books.

MS vs. Adobe: My Take

This is the right strategic move for Adobe. They've managed to attack the biggest weaknesses of their chief competition, Microsoft's WPF, by being cross-platform and leveraging existing technologies already used by web developers. Using existing technologies also means there are many mature tools for both designers and developers coding in HTML/Flash, which is not the case with WPF. Adobe made a good choice not trying to boil the ocean with a lot of new technology.

Granted, WPF's target market is a bit different than AIR's (there are a large number of WinForms developers already using .NET technologies), but for web developers the learning curve and lack of cross-platform support made WPF a non-starter (notice how much more interest Silverlight has recieved in the community). Obviously, there are still many areas where WPF is superior (3D and document layout, to name two), but I think AIR's advantages more than make up for these drawbacks (from a web developer's point of view).

Although still in it's infancy, Silverlight will likely become the real competitor to AIR. Although it's feature-poor in comparison to Flash, Microsoft's clearly devoting a lot of resources to catching up quickly (notice the simultaneous release of 1.0 beta and 1.1 alpha -- which surely required a lot of testing resources). Silverlight plays nicely with HTML and JavaScript, provides good language support (including trendy languages like Ruby and Python), and has a very fast script runtime as well. It already lets you go into full-screen, I don't think adding more windowing APIs wouldn't be a stretch. I fully expect Microsoft to move in this direction.

Obvious Disclaimer: I do not work for Microsoft (although I used to). I don't have any inside information. Don't take blog posts too seriously, especially ones typed hurriedly on a hot day.

Top Level Categories Plugin 1.0

2010-02-12T15:36:30Z

There's a new version of the Top Level Categories plugin. The changes aren't huge, but they do fix all known issues, including:

Will now work correctly with the /%category%/%postname% and %postname% permalink structures (this was the top request).
No longer need to manually update the permalink structure on install or uninstall.
Fixed incompatibility with some installations of the K2 theme.

If the previous version works well for you, then there is no need to upgrade.

Download

Top Level Categories v1.0 (ZIP file).

Let me know if you encounter any new bugs or issues.

Font Rendering Across Rich Platforms

2010-02-12T15:36:30Z

Although I used to work for Microsoft on the WPF team, I'm not tied to the platform. WPF and its alternatives (Flash, HTML, Apollo, Silverlight) each have advantages and disadvantages and choosing between them depends on your requirements. Since I'm doing a lot of work around reading experiences, I thought it was a good time to go back and re-evaluate the existing choices.

In this post, we'll look at how each platform renders fonts at 9, 10, 12, and 14 points -- sizes commonly used for reading. I've used three fonts:

Verdana: The old standby, installed on many systems.
ITC Cheltenham: A serif frequently used in newspapers.
Gotham Rounded: A sans-serif that I happen to like.

For no good reason, I've placed the results in alphabetical order. First up is Flash.

Flash

Up until a few years ago, Flash used to render fonts poorly at small sizes. Most authors worked around this limitation by changing the type of anti-aliasing used when displaying fonts. Flash provides two anti-aliasing options, one for readability and the other for animation. Additionally, Flash also allows the author to disable anti-aliasing altogether, and use aliased bitmap fonts. Flash 8 introduced a new rendering engine that vastly improved the quality of small-type text.

At small sizes, the readability setting is (unsurprisingly) far superior to the animation setting. Here's a sample of the readability anti-aliasing for Verdana at 10 point:

For the same font and size, the animation setting is quite ugly:

Although it creates clearly more readable results, the readability smoothing creates a strange coloring affect that can be pretty noticeable at small sizes. Here's Gotham Rounded at 9pt:

On my monitor, the effect is subtle, but noticeable -- I see a bit of color around the edges of the letters.

Flex / Apollo

Apollo (through Flex) has two different font rendering engines -- one of which seems to be shared with Flash (the documentation is a little vague here, so feel free to correct me if I'm wrong). The other rendering engine has access to installed fonts, and is recommended for small type sizes -- however the quality is quite bad. From my simple tests, it seems that the fonts are always aliased, producing the jaggy look seen below:

This aliased look is acceptable for some fonts, such as Verdana, that have reasonable bitmap representations at small sizes. However, for many fonts the result is unacceptable, such as this sample of Cheltenham at 10 point (from Flash set to bitmap, not Flex):

Except for extreme cases, it looks like it's best to use the Flash font rendering system when writing an Apollo (or Flex) application. (Once again, I'm under-educated in the Apollo and Flex realms, feel free to drop some knowledge in the comments)

HTML

On my machine, the Firefox and Internet Explorer 6 both rendered extremely similar results. The Firefox rendering is shown below:

The lack of subpixel positioning destroys the serif font at small sizes. You can see the effect at larger sizes as well -- here is Cheltenham at 14 point:

You can see the strange letter spacing in the first line -- compare "Marketing" and "cross" to see the difference.

The sans-serif fonts fared better in the browser, with Verdana doing particularly well as it was specifically tuned for on-screen use.

Internet Explorer 7 uses ClearType for its font rendering, and should therefore produce results that are nearly identical to WPF.

Silverlight

Silverlight is the least mature of the platforms (since Apollo leverages both Flex and Flash). The 1.1 Alpha version that I tested unfortunately does not support for the Adobe CFF font format -- meaning I was unable to test Cheltenham or Gotham Rounded. Silverlight doesn't use the ClearType algorithm used by WPF, instead it uses gray scale anti-aliasing with gamma correction. The results are generally good, with the clear weakness being at small sizes. Here is Verdana at 9pt in Silverlight:

At this small size, Verdana looks a bit fuzzy. The effect is less noticeable at 10 point, but still there.

WPF

All text in WPF is rendered with ClearType -- developers have no way of opting out of this (actually, there is a way, but it's pretty awkward and not really well known). The quality of text at small sizes is impressive, here's Gotham Rounded at 9pt in WPF:

It's slightly fuzzy and a bit gray, but overall a bit better than the flash version.

Verdict

Overall, the results are pretty good. The only engine with poor results is the native Flex engine, but with support for Flash, there's a clear, easy to use alternative at your disposal.

Although the browsers work quite well with standard web fonts (and any other specifically tuned for small sizes), they are not an acceptable choice for traditional print fonts -- especially Serif faces (Internet Explorer 7 being the exception). Considering the lack of cross-browser font-embedding, this probably isn't a problem for most.

Silverlight is still a baby in this space, and it shows (there's currently no way to set line height, for example). The anti-aliasing looks pretty good at larger sizes, but is noticeably fuzzy at smaller sizes. Although it's better than what most browsers provide, it still has a way to go before catching up to Flash and WPF.

The final two contenders are Flash and WPF -- and it's a close call when it comes to rendering. Here are three side-by-side samples for WPF and Flash. The first is Verdana at 9 point (all samples show Flash with readability anti-aliasing):

Although the Flash version has a nicer color, the WPF wins by a hair here, for being a bit smoother and less blurry (look at the "B" in "Branding" in the Flash version, third line from the bottom). Let's move on to Gotham Rounded at 9pt:

Once again, Flash has stronger lines that WPF, but it's uneven and has a bit of color fringing. Finally, let's look at Cheltenham at 12 point:

This time, WPF is a bit darker than Flash. This one is really a toss-up and depends on personal preference. Flash is a bit sharper, but the WPF version is smoother and more consistent.

Overall, I think WPF has the edge when it comes to font rendering, although it's quite close and could easily come down to user preference.

Next Steps

This analysis is a bit rough, there's a bunch on my to-do list here, including:

Testing FlashType in Flex and Apollo
Testing non-CFF fonts in Silverlight
IE 7, Mac OS, and Ubuntu screenshots
More fonts

Also, the font rendering is just one aspect of a user's reading experience. Obviously layout, performance, installation, and many other factors come in to play here. Subscribe to feed to make sure you don't miss the next installments.

Raw Results

If you're interested, here are the screenshots from each test application, in PNG format: fontrendering.zip (Zip, 500K)

Fortes

Introducing Treesaver

What is Treesaver?

Why use HTML?

What are Treesaver's Browser/Device Requirements?

Can Treesaver content be distributed via the App Store?

When can I use Treesaver?

I'm interested in using Treesaver for my publication, how do I get in touch?

Will Treesaver be Open Source?

Got any Screenshots?

More Questions?

Treesaver Sneak Peek

Coming Soon

Soft Hyphenator

jMetronome: Using jQuery to keep typographic rhythm

Usage

Known Issues

Introducing the Dynamic Layout Library

Introducing Sistr

Usage

Pros & Cons vs. sIFR

Known Issues

Adobe OnAir Seattle

The Big Picture

Interesting Tidbits / Nerdy Technical Details

MS vs. Adobe: My Take

Top Level Categories Plugin 1.0

Download

Font Rendering Across Rich Platforms

Flash

Flex / Apollo

HTML

Silverlight

WPF

Verdict

Next Steps

Raw Results