Here’s a version for Movable Type that can be used to automatically convert entry titles to title case. It is essentially a wrapper for John’s script that adds some functionality to deal with html entities (so it should play nice with Smarty Pants and Widon’t).

Download

Title Case for Movable Type v1.1 (2008-05-23)

Installation

Unzip the file and place TitleCase.pl in the plugins directory of your Movable Type installation.

Usage

For titles, add the global filter titlecase="1" to your entry title tags:

I’ve tried several ways of formatting my CSS to balance these two views, without much success. I’ve tried indenting rules based on their place in the document hierarchy, or making heavy use of summary comments to facilitate searching, broken groups of selectors over several cumbersome files and used single line selector blocks. None of these techniques helped tame unruly CSS files once they exceed a few hundred lines.

That last technique though, of using single line selector blocks, does help with the broad level view, but renders the property rule level unreadable. I still want each property on its own line. How do I achieve both views?

Code folding in TextMate

TextMate for OS X (and probably other quality text editors on other platforms) has the ability to fold blocks of code, collapsing each block except for their first lines. Doing this to a CSS file (Alt+Cmd+0) leaves just the document selectors on single lines, temporarily hiding their property rules. This is perfect for scanning through a large file to locate a specific selector. When it’s time to focus on the finer level of detail, the block can be revealed by toggling the selected block (F1 or clicking the arrow in the gutter). When you’re finished, toggle it back up again. As there is only one or two blocks unfolded at a time, it’s very easy to focus on the code without getting lost.

I started subscribing to feeds a couple of years ago, using the serviceable Sage extension for Firefox, before ditching it in favour of the remotely hosted Google Reader. It’s taken some time to attain a sustainable habit, swinging between binge and fast, but recently I think I’ve pegged it.

In Google Reader, having the articles laid out on a level playing field seemed like a good thing, at least initially. Set as they were under the uni-identity of the reader, I was ploughing through several hundred posts a day, not exactly at my most discerning.

But, I started to miss the design of the web-sites, even though I was reading their actual content. I wanted to enjoy posts in their proper context again. I ended up reading about my field (web design), while at the same time cutting myself off from it.

Recently, I started following a practise picked up from Zen Habits (I mentioned it previously in my Interesting elsewhere links):

RSS posts: I’ve been adjusting this as I’ve experimented, but I’ve settled on reading 6 posts per day. The method: I open my Google Reader in list view, scan through the headlines, and choose just 6 to read, opening them in new tabs. I then “Mark All as Read” and go and read my 6 posts in further detail. It has made RSS reading super fast.

I definitely read more than 6 a day, but a lot less than previously. That leaves just the interesting articles, and the crucial step of opening them in a series of new tabs means leaving the sterile environment of the reader. It’s like using a catalogue with a printed list to shop for books. Select the ones you want to read, then leave the list behind.

I also don’t want to rely on having rated everything just to help organise my listening. It’s certainly helpful to have a few smart playlists which use track ratings, but I can’t rate it all! And I definitely don’t want to be nagged to rate unrated tracks. I’ve got about 60 days of audio, I’d go insane.

I want to rate a song when the feeling takes. To say, “I’m liking this!”, without too much baggage and without having to switch into iTunes and decide which of the fiddley stars to click on, or to engage in what it might mean. I want the results of a system, without having to engage too actively with it. I don’t want to have to remember whether I’ve previously rated it. In fact, I want to make a virtue of this possibility.

To achieve this I use the wonderful Quicksilver and its iTunes plugin. If I like something, I use the iTunes plugin’s Increase Rating.scpt script which will increase the tracks rating by one, whatever its previous rating, up to five. As soon as I’ve thought of doing it, it’s done. The more often a track grabs my attention, the more likely it will eventually achieve a high rating. It’s a system that matures, and where each track has to earn its stars.

I've also fixed the unquoted string warnings some people were experiencing.

Get the latest version of Widon't for Movable Type (works with both 3 and 4): Widon't for Movable Type

I can't offer much in the way of support, and the script does do some heavy lifting (like removing all GLIFs in the UFO before exporting a new one), so please have a good look at the script before using it. I don't want to be held accountable if your machine starts vomiting kittens. The script is meant to serve as an example use of pysvn in the context of typeface development. Having said that, I find it very useful.

Features

The current version (v1.3) of ExportToUFOCommitSVN.py does the following:

• exports the current font in FontLab to UFO,
• add new GLIFs to the working copy,
• delete removed GLIFs from the working copy (new in v1.1!),
• commit a new revision to the SVN repository.

Requirements

In addition to having a copy of FontLab, you'll need:

• RoboFab: Python library for font development
• pysvn: SVN extension for python (make sure you get the same version as your own SVN installation if you intend to use both)

Download

ExportToUFOCommitSVN.py v1.3 (2007-03-28)

The script is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike license.

At the moment it covers Adobe's OpenType Feature File Specification used by the AFDKO. As well as syntactic highlighting, there are also a couple of snippets for creating features, tables etc.

Download

Typeface development Bundle for TextMate v1.1 (2007-03-02)

Update

Tal Leming generously donated the contents of his own bundle for feature files. I've incorporated some of his snippets and keywords and released a new version, above. There's also a bug fix related to single quote use in substitutes (thanks Ben!).

Installation

If you've got TextMate installed, you should be able to just unzip the archive and double-click the .tmbundle file.

(Windows users can try Adam Twardoch's Typographic extensions for UltraEdit-32.)

Font files are software (and how SVN can help)

First off, I'll start by stating that Fonts Are Software. And not just in a pragmatic fit-the-definition-for-intellectual-property-law sort of way, but in a real code-compile-interpret sense. Obviously fonts aren't just software, they contain tables of data that are the realisation of a designer's vision for a typeface, but because the design transmitted is in the form of code, there are coding practices we can learn from the software engineering community that can help us make better font files. One such practice is the use of version control systems.

Version control systems, like the open-source, Subversion (SVN), store files in a repository who's job is to manage change between versions. To work on these files, you have to check-out a copy, then save back any changes to the repository. Every time you save a new version of your files to the repository, known as 'committing', the revision number for the repository increments, starting from 0. So, every revision of your work has a unique rev number.

The most fundamental benefit of using version control is as a simple backup of your work. The repository is stored separately from your working copy, often remotely on a web-server. So, if the worst happens to your computer, you've got a recent copy of your files saved to go back to. The life of a typeface project is long, the chances of losing work are high, so this alone sells it for me!

But better than that, version control systems don't just save a copy of the latest version, they also allow you to go back to any version you've committed to the repository. This is great, because if you've made a bad design decision, after a night at the pub say, you can easily go back and retrieve a previous version not inspired by several pints of terrible British lager.

If you work in a team, you're likely to run into problems if two people have made changes to the same file. It can be a fiddle to get changes integrated or in the worst case, someone's work is going to be overwritten and lost. Subversion uses a copy-modify-merge model to handle this problem. Each user has a copy of the file from the repository. They make modifications. Then, when they each commit that file back to the repository, the changes are merged together.

For example, Alice makes a change to the features file by adding some more substitutions to the LIGA feature. Bert is also working with a copy of the same features file and has made changes to the LOCL feature. Alice doesn't have Bert's changes and visa versa. After Alice has committed her changes to the repository, when Bert commits his changes, Subversion will merge the changes together automatically creating a file with both changes to LIGA and LOCL.

What if Alice and Bert have both been working on LIGA? If there is an overlap in the changes made to a file, when the second person (Bert) commits the file there will be a conflict. This isn't as bad as it sounds. The file will be flagged as being conflicted and Bert can decide which changes to keep, mark the file as resolved and carry on committing it to the repository.

For a (much) better description of this process have a look at Versioning Models in the SVN book.

Binary to text files

SVN prefers plain text files (like this HTML page). This is a bit of a problem for most of us, because programs like FontLab Studio store your work in a binary format, like .vfb files. SVN is happy to store them, but we can't easily do the cool stuff SVN offers, like merging or dealing with version conflicts. Feature files and class data can be exported as text files, but what about glyph data?

Thanks to Robofab, and in particular the UFO format, we can store our glyph data in text files! Robofab comes with tools, written in Python, for exporting and importing between FontLab and the UFO format.

When you export a font to UFO, each glyph is stored in its own text file, the GLIF. So when you've added or modified a glyph to the SVN repository, it's easy to see what was committed during a particular revision, and conversely, which revisions contain changes to a particular glyph.

Python and SVN

If you're into Python scripting, you might want to use the pysvn extension to make use of SVN in your FontLab and Robofab scripts. Here are some examples:

Export to UFO and commit to SVN

Below is an example script that uses pysvn to export the current font to UFO, add un-versioned files to SVN control, and commit the changed UFO and .vfb files to the repository as a new revision.

ExportToUFOCommitSVN.py v1.3

(Works within FontLab, and requires Robofab and pysvn. More info about the script here.)

Generate a font with the latest rev number attached

When you generate a font file from your project, you can include the revision number as part of it's font information. Below is a modified version of Ben Kiel's betterGenerateFont.py, that generates a font file and adds the current revision number as part of the minor version information. This way, you know exactly which revision a font was generated from. So, if your font is major version 1, and it was generated from rev. 23, the generated font would be version 1.23.

betterGenerateFontSVN.py

Works within FontLab, and requires Robofab and pysvn.)

You can now prevent widows appearing in header tags (h1, h2, etc) used in the entry body as well as in entry titles.

You can find version 1.2 here: Widon't for Movable Type

Proposing Free Fonts to the ATypI is analogous to arguing for "Intelligent Design" to a society of evolutionary biologists. It's simply not considered necessary to debate within the expert group, but it seems to get a lot of undue attention around the margins. Still, the mere suggestion raises the blood pressure while casual acceptance of license violations within the graphic design community, and the scars of unabashed piracy, set the context for such a suggestion.

It's not that her idea is necessarily bad, it's just ill-defined. Both the issue it's trying to resolve and the solution proposed fall wide of the mark (sounds familiar).

As far as I can interpret, the suggested beneficiaries fall into three groups; students, users of under-represented character sets, and the rest of humanity (whoever they are?).

A student addiction

Apparently, students need more free fonts. But they already have some, right? Well, yes, but they're unsatisfied with the fonts available on their operating systems, or bundled with their design applications, or even those available as part of the site licenses provided by their academic institutions. So, they're seeking out unlicensed typefaces and criminalising themselves. Poor souls, it's a tough life when you have to make a decision between having a night-out, or licensing a typeface.

They want more, damn it! Their insatiable appetite for a type high drives them to the dodgier parts of town where they can find the perfect letterage on which to binge. There's nothing sadder than stepping over the prone body of an unconscious design student lying in a puddle of their own punctuation, with the stains of tightly spaced extra-black around their mouth from the previous night's font debauchery.

They say they're looking to expand their minds (man), but really they're just bored with the current scene.

But the damage to society is too great to be left in the hands of criminals. We need to legalise this unlicensed addiction! By controlling the quality, and regulating the dose, we can strive towards teaching a better understanding of moderation.

Yet more free fonts will do nothing to prevent the real separation between students of design and the designers they should be learning to view as their peers. Rather than fostering further separation, I'd prefer to see students being encouraged to actually engage with type designers and foundries, carefully select a font purchase and view it as an investment. Something to become familiar with and understand. Payment is tangible recognition of another's work and helps to encourage the investment in time it takes to use a typeface well. It also teaches against the assumption that typefaces are just "there", as if by magic. An expectation that fonts are free is a bad habit to get into. Habits picked up as a student will be with you for life, good and bad.

What's getting given away

I don't see many foundries truly giving away their best assets. Many foundries already give away single, obscure members of a larger family or some display face that wasn't selling anyway. I can't see this changing anytime soon. A good typeface just represents too large an investment to turn over to the public domain. When it comes down to it, there a lot of typefaces in the world, but few good ones.

A student building up a collection of these rag-bag, disparate fonts might actually be tempted to use them! Perhaps students don't need access to more fonts, but less.

Meet specific needs, empower appropriate designers

Our second beneficiary are the groups who's languages aren't adequately represented by the currently available free fonts. Projects like Victor Gaultney's Gentium best represent movement in this area.

These projects require a lot of research and a specialist knowledge that manifests as a proportionate investment of time and resources. It's just not possible to produce this sort of work for free. The work is usually supported by a funding organisation, or private investment.

There's certainly something to be said for further work in this area. Currently, under-represented language groups are either creating typefaces themselves, or extending existing efforts, with varying degrees of success.

Requesting this work to be given away by foundries might be asking the wrong group, though. My immediate thoughts were that a foundation to fund work like this would make the most sense. That way, the most appropriate designer/researchers could be funded by an organisation to represent and ensure the interests of the recipient groups. Perhaps a foundation like this could help finance scholarships (similar to the Linotype scholarship) for native users of the language in question to study at somewhere like Reading. Simply asking designers/foundries to submit work they happen to have around is not likely to fulfil the need for typefaces of this sort adequately.

Andrei acknowledges that properly addressing font distribution for the web is a difficult issue, but seems to think getting Adobe to release a set of fonts from their collection will be a quick win in the mean time.

Although polite and well intentioned, addressing the problem of fonts for the web to Adobe is slightly wide of the mark. Apart from de-valuing the work of Adobe's awesome type development team (as if fonts that have been decades in the making should be distributed like sweets), there are some major technical and licensing difficulties.

All the typefaces mentioned in Andrei's dream list are PostScript-flavoured OpenType format (the majority of the fonts in Adobe's collection are either PostScript or PS flavoured OpenType). This is significant because to render type on screen is a tricky business and requires additional, size specific, instructions called hinting. PostScript OT fonts have a basic hinting model that's fine for previewing in InDesign, but doesn't quite stand up to the pressures of extended reading for the web. This basically means they will look like smudgy thin trash at small sizes in a web page, not because they aren't good typefaces, but because they weren't designed specifically for the screen.

We take them for granted, and familiarity has certainly bred contempt, but Verdana, Georgia and the like are an astonishing achievement. They have defined the standard for screen rendering for many years. The reason for this is because they were primarily designed for the screen and, getting back to formats, they are TrueType. With TrueType (and TrueType flavoured OpenType) comes TrueType hinting. Unlike PS hints, TT hinting is a sophisticated programming language that can define very precisely the rasterizing of individual characters at small sizes. Hinting type to this quality is a long-winded manual process and usually requires quite a "special" personality (i.e. it's boring).

The other problem with Andrei's list is that half of these typefaces are licensed from Linotype. Although the "amount of revenue lost [...] surely can’t have a significant impact on Adobe’s bottom line" (this may or may not be true), for Linotype it's their core business. Frutiger, Futura, Helvetica Neue and Univers are all top sellers.

Perhaps Andrei is just looking toward the wrong company for a quick fix. Along with Microsoft's release of Vista, they will be bundling a new set of fonts designed specifically for screen. These are modern typefaces designed by some of the world's top typeface designers. As suggested by Jeff Croft, if Microsoft bundled these with the upcoming IE7, that would go some way to reinvigorating type on the web.

Top tip: Windows users can "beta test" the new Microsoft ClearType fonts as part of the Office2007 Beta. In fact, I've specified Corbel, Constantia and Consolas as the default typefaces in the CSS of this very site.

Widon't simply adds a non-breaking space entity between the last two words of an entry title, so if the last word has to wrap, it takes a friend with it.

Widon't for Wordpress was originally released a few days ago by Shaun Inman, but I didn't want to be left out as an MT user, so I've ported it across to Perl. All credit for the idea and PHP version goes to Shaun, any failures in this MT version are down to me.

Download

Widon't for Movable Type v1.4 (2008-07-11)

Installation

Unzip the file and place Widont.pl in the plugins directory of your Movable Type installation.

Usage

For titles, add the global filter widont="1" to your entry title tags:

To prevent widows in header tags used in entries, add the widont filter to the appropriate MTEntry tag:

I'm no Perl ninja, so if there are any problems let me know.

Update: 25th August 2006

This article relates to IE7 Beta3. A day after I wrote this article, Microsoft released IE7 RC1 which seems to have fixed this problem (at least, according to the tests below). So, hooray!

Alpha support for PNG images is one of many fixes and features we can get excited about in IE7. Well... sort of.

Following news that the new PNG transparency support might not be as native as previously supposed, I ran into another strange issue while preparing a website for IE7.

In some circumstances, transparent PNG background images of a parent node will be rendered within a child node. IE7 seems to triggered this behaviour when a Flash movie is embedded into a page. This situation isn't particularly unusual, for example, we have a heading with a link inside:

The h2 is then styled with a background image and the link is coloured red when hovered over:

If a Flash movie is embedded in a page the link will render the background of its parent when hovered over. Strangely, minimising, then restoring the window will reset the link background (until it's hovered over again). Also, once the bug is triggered by a Flash movie, visiting pages without Flash will still render the background when the link is hovered over. Below is a screen capture of the rendering bug.

Check out the live demos (you'll need IE7 Beta3):

Transparent PNG test with no Flash

Transparent PNG test with Flash movie embedded

Getting the tools together

When you install Internet Explorer 7 Beta 3, as downloaded from the Microsoft website, Internet Explorer 6 is replaced. This is bad news for web developers who understand IE6 isn't quite off our backs just yet and want to be able to test easily in multiple browsers.

There are two ways to have both IE6 and IE7 run on the same machine (three if you include Virtual PC but I resent having to install a whole OS just to run a browser!). The first is to install IE7 then a standalone version of IE6 from evolt.org's browser archive.

The second method is slightly more complicated, involving changes to the registry and startup scripts, but it allows you to keep the default installation of IE6 and run IE7 as a standalone. This is done using either the method described by Jon Galloway or the pre-packaged standalone installer created by Yousif Al Saif.

Whilst IE7 is still in beta, I prefer to keep IE6 installed as the default, so older versions and beta browsers are run as the exception. With this in mind I opt for the second method and use the standalone installer for IE7beta3. Once the final version of IE7 is released (4th Quarter of 2006, allegedly), I'll switch to the first method; running IE6 as a standalone.

Checking previous hacks

After getting the browser sorted, I want to check through the hacks I implemented for IE6 and see if they still affect IE7.

I keep all browser specific rules quarantined in separate .css files. Much like plague victims. These get included in the top of my main css file. Opening up ie6win.css I can see the various workarounds and hacks I used to bully IE6 into submission.

In my example, all the rules use the invalid * html selector to target for IE6. As mentioned in the previous article, this particularly useful bug has been fixed so none of these rules will apply to IE7. This is actually good though, because some of the rules used to workaround IE6 bugs and deficiencies are no longer needed.

The good news -- transparent PNG support

Most of the IE6 specific rules we used for Ingenious Ireland were to overcome the browsers terrible support for transparent PNG images. For example, the page header is a transparent PNG so its rounded corners would allow the various colours of background to show through:

This rule defines a proprietary filter allowing partial support for PNG transparency.

Luckily, IE7 will support PNG transparency, and because IE7 will not recognise the invalid * html, it will not see the IE6 specific rule, so we can just forget about all this filtering nonsense.

The bad news -- the language pseudo selector

As Ingenious Ireland is a bilingual site, certain text-carrying background images, defined in the CSS, are selected based on the value of the language attribute in the html tag. This attribute can be targeted in the CSS using the :lang() pseudo selector, e.g. an Irish banner image:

(More details about this technique have been described in a previous article.)

The problem is, no version of Internet Explorer on the PC supports the :lang() pseudo selector, including IE7. (IE 5.x on the Mac does support it, but it always was the Best Browser In The World.)

We used an additional value for the class attribute in the body tag to specify the base language of a page for browsers that don't support the CSS language pseudo selector, targeting it thus:

Now the Internet Explorer team have fixed all those useful bugs we used to filter for IE6, like * html how can we target rules for IE7?

Conditional Comments and The Volatile Header

If you want to target CSS rules specifically for Internet Explorer, the official recommendation from Microsoft is to use conditional comments. This is a proprietary method for specifying html for various combinations of Internet Explorer 5 and above.

So, to link an IE7 only stylesheet, we add the following into the head of every document:

All rules we want to target for just IE7 go in this stylesheet.

Why, after our best efforts creating stable mark-up, do we have to make additions to the header to make up for a browsers CSS deficiencies? I'd much prefer to link one stylesheet per alternative or device. The IE7 only stylesheet is really just an supplement for the main, screen stylesheet, not a new alternative.

It's a shame there isn't an officially sanctioned way to target for specific browsers within the CSS specification. The reality is we use hacks to achieve this anyway with the potential risk that the hack will be fixed, or new browser implementations will interpret the rules in an unexpected manner. Much better would be to provide a safe, stable way to achieve this by using some sort of conditional in the CSS.