Comping with Web Fonts (you don’t need SkyFonts)

I wrote about problems downloading web fonts for desktop use when Google’s Web Fonts debuted, but years later it’s still an issue. There’s no way to anticipate the twists and turns a creative project will take. Designers should be free to play and experiment with typefaces without worrying about running out of time or exceeding a monthly usage cap. Convoluted, fragile workflows only create anxeity, they don’t foster creativity.

Monotype’s SkyFonts service is a nice idea, I guess, but their usage terms seem impractical and unrealistic. The few designers I know who’ve tried it found it restrictive and expensive.

The thing is, with a little knowledge of how web fonts work, using those typefaces in desktop apps is quite easy.


Web fonts are normally provided in three file formats, two of which, TrueType *.TTF and Web Open Font Format *.WOFF, are easily converted back to standard TrueType or OpenType fonts. Because of browser variation and font-face implementations, all three font containers are usually linked from a site’s stylesheets.

To use any web font for comping in desktop apps, just convert the ttf or woff file to otf, then use it like you would any normal font. There are a number of tools for converting fonts, but the following web sites work well enough that I didn’t bother downloading an app.

Standard-level accounts allow for self-hosted webfont projects. This means the font files can be downloaded and hosted on the web server alongside other assets like images or stylesheets. Having those files makes converting fonts for comping easy, but it’s just as simple to download the files with a web browser. Any file on the web can be copied, in fact every file viewed on the web already is a copy.

Yes, you can steal fonts using this. Don’t. “Good Artists Copy; Great Artists Steal” wasn’t about shoplifting.


  • Web TrueType fonts often won’t show in menus because their name-tables have been munged to discourage copying/theft. Converting fonts to a different container format makes them work correctly.
  • Some woff files didn’t work, in those rare cases the corresponding ttf worked fine–you might need to dig into the stylesheets to find the url.
  • Converted web fonts usually have messy names in menus.
  • Disable or remove any local copies of fonts when the mockup phase ends. Locally installed fonts can conflict with web versions and lead to maddening discrepencies in testing.

A few workflow links and examples

This morning I had a nice breakfast with a friend where various workflow and technology advances came up. This is really an email to him, but I thought it was worth sharing.

Composer and Packagist for PHP

Composer is a project-based dependency manager which makes it very easy to integrate PHP libraries into projects. Packagist is where you find which libraries are available, and has the simplest installation instructions. With Composer installed, adding features like Markdown or YAML parsing literally becomes as trivial as editing a json file.

Composer relies on modules being authored according to PHP Framework Interoperability Group’s PSR-0 standard. Since I’ve been guilty of bashing PHP, it’s probably worth mentioning Fabien Potencier’s post, PHP is much better than you think. PHP is far better than it used to be and the developer ecosystem is very, very active. (but I still prefer Python)


Homebrew is a package manager for OSX. Similar to apt-get or yum on Linux, this is the successor to MacPorts or Fink. It installs with one line pasted into the terminal (assuming you’ve got XCode already) and makes installing and removing packages ridiculously clean and easy. Homebrew is pretty much the first thing I install on a new Mac.

The weather app is a terrific example of what’s possible with web apps that perform like native code. They’re also pushing a lot of cutting edge HTML 5 technologies. Startup times could be better, but that will come with hardware. Forecast is an offshoot of Dark Sky, my favorite iOS weather app.

Unreal on the web

Continuing the theme of what’s becoming possible on the web, Mozilla and Epic recently demoed the Unreal engine running in a browser. You’ll need Firefox Nightly for the best experience. The port uses HTML5, WebGL and JavaScript compiled from C source. This runs at 50+ frames per second from my laptop full screen on a second display. Crazy.

Download Google’s Web Fonts

May 1, 2013 update: I’m no longer providing a download link to the font files. Please use the googlewebfonts repository on GitHub. Just click the Zip button.

Google’s Font Directory and API for web fonts could have a transformative effect on how we read the web. The only problem is, Google has made it very difficult to download all of the actual font files.

Web designers must be free to experiment with fonts, to sketch, comp and get to know the typefaces in browser and non-browser applications. Making the fonts difficult to get or requiring special software isn’t helpful.

A web-focused Git workflow

After months of looking, struggling through Git-SVN glitches and letting things roll around in my head, I’ve finally arrived at a web-focused Git workflow that’s simple, flexible and easy to use.

Some key advantages:

  • Pushing remote changes automatically updates the live site
  • Server-based site edits won’t break history
  • Simple, no special commit rules or requirements
  • Works with existing sites, no need to redeploy or move files


The key idea in this system is that the web site exists on the server as a pair of repositories; a bare repository alongside a conventional repository containing the live site. Two simple Git hooks link the pair, automatically pushing and pulling changes between them.

The two repositories:

  • Hub is a bare repository. All other repositories will be cloned from this.
  • Prime is a standard repository, the live web site is served from its working directory.

Using the pair of repositories is simple and flexible. Remote clones with ssh-access can update the live site with a simple git push to Hub. Any files edited directly on the server are instantly mirrored into Hub upon commit. The whole thing pretty much just works — whichever way it’s used.

Getting ready

Obviously Git is required on the server and any local machines. My shared web host doesn’t offer Git, but it’s easy enough to install Git yourself.

If this is the first time running Git on your webserver, remember to setup your global configuration info. I set a different Git to help distinguish server-based changes in project history.

$ git config --global "Joe, working on the server"

Getting started

The first step is to initialize a new Git repository in the live web site directory on the server, then to add and commit all the site’s files. This is the Prime repository and working copy. Even if history exists in other places, the contents of the live site will be the baseline onto which all other work is merged.

$ cd ~/www
$ git init
$ git add .
$ git commit -m"initial import of pre-existing web files"

Initializing in place also means there is no downtime or need to re-deploy the site, Git just builds a repository around everything that’s already there.

With the live site now safely in Git, create a bare repository outside the web directory, this is Hub.

$ cd; mkdir site_hub.git; cd site_hub.git
$ git --bare init
Initialized empty Git repository in /home/joe/site_hub.git

Then, from inside Prime’s working directory, add Hub as a remote and push Prime’s master branch:

$ cd ~/www
$ git remote add hub ~/site_hub.git
$ git remote show hub
* remote hub
  URL: /home/joe/site_hub.git
$ git push hub master


Two simple Git hooks scripts keep Hub and Prime linked together.

An oft-repeated rule of Git is to never push into a repository that has a work tree attached to it. I tried it, and things do get weird fast. The hub repository exists for this reason. Instead of pushing changes to Prime from Hub, which wouldn’t affect the working copy anyway, Hub uses a hook script which tells Prime to pull changes from Hub.

post-update – Hub repository

This hook is called when Hub receives an update. The script changes directories to the Prime repository working copy then runs a pull from Prime. Pushing changes doesn’t update a repository’s working copy, so it’s necessary to execute this from inside the working copy itself.


echo "**** Pulling changes into Prime [Hub's post-update hook]"

cd $HOME/www || exit
unset GIT_DIR
git pull hub master

exec git-update-server-info

post-commit – Prime repository

This hook is called after every commit to send the newly commited changes back up to Hub. Ideally, it’s not common to make changes live on the server, but automating this makes sure site history won’t diverge and create conflicts.


echo "**** pushing changes to Hub [Prime's post-commit hook]"

git push hub

With this hook in place, all changes made to Prime’s master branch are immediately available from Hub. Other branches will also be cloned, but won’t affect the site. Because all remote repository access is via SSH urls, only users with shell access to the web server will be able to push and trigger a site update.


This repository-hook arrangement makes it very difficult to accidentally break the live site. Since every commit to Prime is automatically pushed to Hub, all conflicts will be immediately visible to the clones when pushing an update.

However there are a few situations where Prime can diverge from Hub which will require additional steps to fix. If an uncommitted edit leaves Prime in a dirty state, Hub’s post-update pull will fail with an “Entry ‘foo’ not uptodate. Cannot merge.” warning. Committing changes will clean up Prime’s working directory, and the post-update hook will then merge the un-pulled changes.

If a conflict occurs where changes to Prime can’t be merged with Hub, I’ve found the best solution is to push the current state of Prime to a new branch on Hub. The following command, issued from inside Prime, will create a remote “fixme” branch based on the current contents of Prime:

$ git push hub master:refs/heads/fixme

Once that’s in Hub, any remote clone can pull down the new branch and resolve the merge. Trying to resolve a conflict on the server would almost certainly break the site due to Git’s conflict markers.


Prime’s .git folder is at the root level of the web site, and is probably publicly accessible. To protect the folder and prevent unwanted clones of the repository, add the following to your top-level .htaccess file to forbid web access:

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]


If you’re seeing this error when trying to push to a server repository:

git-receive-pack: command not found
fatal: The remote end hung up unexpectedly

Add export PATH=${PATH}:~/bin to your .bashrc file on the server. Thanks to Robert for finding and posting the fix.


These didn’t fit in anywhere else:

Web Syntax Coloring

February 2011 Update: This post was originally published in 2007 and hasn’t aged well. For code snippet syntax coloring, I currently use Google’s Prettify script (prettify.js). The script is dynamically inserted by jQuery if there are code elements to style.

Recently I’ve been experimenting with two very different methods of syntax coloring source code in web pages. The first method uses a Dan Webb’s CodeHighlighter JavaScript library to convert appropriately tagged content into syntax colored code. It’s necessarily simple, but easily extensible. As an example, here are the CSS rules I’m using to style CodeHighlighter’s conversions:

code.html span.comment         { color: #999;}
code.html span.tag             { color: #07f;}
code.html span.string         { color: #080;}
code.html span.attribute     { color: #07f;}
code.html span.doctype         { color: #07f;}

code.css span.comment          {color: #999;}
code.css span.keywords         {color: #fd2;}
code.css span.selectors        {color: #0b0;}
code.css    {color: #66f;}
code.css span.units            {color: #33c;}
code.css span.urls            {color: #4a0;}

code.javascript span.comment     { color: #999; }
code.javascript span.brackets     { color: #07f; }
code.javascript span.string     { color: #4a0; }
code.javascript span.keywords     { color: #07f; }
code.javascript span.exp         { color: #808; }
code.javascript     { color: #06e; }

The second method uses two more fantastic TextMate features, Create HTML From Selection and Create CSS from Current Theme. What these two commands do is translate exactly what I’m seeing in TextMate into very precise and valid XHTML with accompanying CSS rules. The main disadvantage of this is the weight of the code, the above 721 bytes of CSS converts to nearly 36k of HTML and CSS rules. It’s a seriously heavy pile of span tags, but the cost is immediately outweighed by 148 very specific reasons. And that’s just bundles, there are dozens of great themes too.

Aaron Quint also deservingly gushes over these two commands.

What these do is convert exactly what I’m seeing in TextMate into very precise and valid XHTML. Here’s the same CSS as above translated by TextMate:

code.html span.comment      { color: #999;}
code.html span.tag          { color: #07f;}
code.html span.string       { color: #080;}
code.html span.attribute    { color: #07f;}
code.html span.doctype      { color: #07f;}

code.css span.comment       { color: #999;}
code.css span.keywords      { color: #fd2;} 
code.css span.selectors     { color: #0b0;} 
code.css    { color: #66f;} 
code.css span.units         { color: #33c;} 
code.css span.urls          { color: #4a0;} 

code.javascript span.comment    { color: #999;}
code.javascript span.brackets   { color: #07f;}
code.javascript span.string     { color: #4a0;}
code.javascript span.keywords   { color: #07f;}
code.javascript span.exp        { color: #808;}
code.javascript     { color: #06e;}

Just for the sake of comparison, below is a screenshot of how my code looks in TextMate. It’s not a perfect translation, but it’s a very good start:

Syntax Coloring CSS in TextMate

One of the purported advantages of the JavaScript method is that the source code remains unchanged. That’s sort of true, but not really. The JavaScript functions work by inserting a bunch of spans, so by the time the user sees it the main difference between JavaScript converted code and pre-processed code from TextMate is the detail (and weight) of the TextMate result. Also, any HTML would need to have entities escaped which is another step and a further degradation of the original code.

The main advantage then becomes convenience. A simple block of code doesn’t need to be run through TextMate (on the off-chance I’m writing somewhere else), it can be entered directly and tagged for styling without breaking focus.

Two little MonoBook styling hacks for MediaWiki

Recently, I’ve spent some time working with MediaWiki for Lila’s school’s web site. A small part of what I’ve been doing has been implementing an exisiting design onto the wiki backend. In an effort not to overcomplicate anything (think longevity) I built the entire design adaptation on the default MediaWiki MonoBook theme. Everyone who’s visited Wikipedia has seen what this looks like. Monobook is a very well constructed theme with clearly defined parts that degrade nicely without its stylesheets. So far, with the exception of these two small changes, I’ve able to do everything I needed to with the default page structure.

First change: Fixing bad portlet IDs

Editing Mediawiki:Sidebar allows for nearly complete customization of the sidebar links. Custom sections automatically get custom IDs which can then be styled. There is one thing that seems like a bug however: If a section heading has a space in it, the portlet ID will have an illegal name. Classes can have spaces in their selectors, but IDs can’t. Here’s what I did:

<div class='portlet' id='p-<?php echo htmlspecialchars($bar) ?>'>

and the new one:

<div class='portlet' id='p-<?php echo str_replace(' ', '_',htmlspecialchars($bar)) ?>'>

Simple enough, PHP’s str_replace is used to swap underscores for spaces. I’m still feeling my way around the MediaWiki codebase, so this might not be the best solution to the problem, but it does what it needs to with a very lightweight function.

Second change: Classes from page title

I needed to change the background of the globalWrapper element depending on the page, the way I accomplished this was to use the page-title. This has one initial drawback, namely that colons are not allowed in CSS class names. However the workaround above can be recast here with added benefit. Switching colons for spaces results in multiple class names, so namespaces can be styled too.

Here’s the old code:

<div id="globalWrapper">

And the new code:

<div id="globalWrapper" class="<?php echo str_replace(':', ' ', $this->data['titleprefixeddbkey'])?>">

This method would seem preferrable to adding a CSS import rule which would look for a custom-named file. Even though CSS load errors don’t break pages with visible 404 errors, they would slow down page loads and litter the server logs. Checking that the CSS file exists is somewhat costly, and I suspect MediaWiki’s cacheing isn’t something that can be quickly skimmed over and implemented.

There appears to be a pageCSS extension somewhere, the hooks are even specified in MonoBook’s header, but I couldn’t find a working download and CVS repository doesn’t seem to be working anymore.

getSelection() Workaround for Safari 1.3, 2.0 and Firefox 1.0.3

update 2: These workarounds also work with Safari 2.0 in Mac OS X v10.4 .
update: There’s a simpler fix, jump to the bottom.

Yesterday morning I noticed a change to the JavaScript/DOM getSelection() behavior in the new Safari 1.3 (in 10.3.9) and the most recent version of Firefox 1.0.3.

I’ve been using this method for years to pull selected text from web pages for several of my bookmarklets. The one I use most frequently generates a link from whatever text is selected. If nothing is selected, it grabs the document’s title. The change in getSelection() broke that bookmarklet, no selected text was recognized.

After a bit of research, I found Mozilla’s Safely accessing content DOM from chrome page which describes the security fixes behind the modification and detailing other problems the changes had caused. Based on Mozilla bug 290777 and this post by Buzz Anderson, both browsers seem to have problems with the change. Despite those bugs, I managed to find the simple workaround as described below.

What Safari and Firefox now seem to be doing is creating a DOM selection object from getSelection() instead of treating it as a simple string. The result is that getSelection() appear to be a string, but few of the string manipulation functions work without additional considerations.

The following examples are all intended to be tested as bookmarklets, drag them to your bookmarks bar for testing:

  • getSelection() test 1

    Works as expected in Safari 1.2.4, Safari 1.3 and Firefox 1.03, popping an alert containing the selected text. Trying to measure that returned string fails in Safari 1.3 and Firefox 1.0.3 but works in Safari 1.2.4:

  • getSelection() test 2

    The older version of Safari returns a character count for the string of selected text. Firefox and Safari 1.3 return “undefined”. There are quite a few other problems:

  • getSelection() test 3

    Works in Firefox and Safari 1.2.4 but not in Safari 1.3.

  • getSelection() test 4

    Getting the length after toString works in Safari 1.2.4 and Firefox.

Further inconsistencies between Safari 1.3 and Firefox 1.0.3:

  • getSelection() test 5

    Returns “Range” in Safari with a selection, returns “Caret” or “None” with nothing selected. Fails with “undefined” in Firefox. (I think the Firefox 1.0.3 DHTML regression bug might be preventing it from working in Firefox but I didn’t try any of the recent nightly builds.)

  • getSelection() test 6

    Fails silently in Safari, returns selected text in Firefox. Safari dumps this into the Console log:
    [5956] :TypeError - Value undefined (result of expression d.getRangeAt) is not object.

  • getSelection() test 7

    Fails with “undefined” in both.

There is some good news:

  • getSelection() test 8

    Works in both Firefox and Safari 1.3; fails in Safari 1.2.4 as “undefined”. This means (finally!) there is a workaround for my problem.

I was using the length property to determine whether a selection was empty or not, then fetching the title of the window if that value was 0. Knowing that length no longer works in Firefox and Safari, isCollapsed can be used as a conditional switch.

  • getSelection() Workaround

    That will return any selected text or the document title if there is no selection. Tested successfully in Safari 1.2.4, Safari 1.3, Firefox 1.0.3 and presumably Safari 2.0 as well.

Line breaks were added to visible code examples because my style-sheet choked on long lines and I can’t redo the CSS right now…

Update: After working through all of the above, I realized there is a far simpler solution: +''. The Safari problem seems to be that string methods do not work on the returned object from getSelection(). Forcing the result into a string by concatenating with an empty string fixes all of my bookmarklets. Concat() fails because it’s a method of string, use the "+" joining operator and an empty string '' instead.