Menu

Category / Web Design

In the first and second parts of this series you learned what version control is, and how to put a place a website under version control using Subversion. In this final article I will talk about configuring a local Apache webserver to integrate smoothly with your development working copy, and how to deploy a version controlled website to a live webserver.

In part 1 of this series you learned what version control is, and how it can be useful for website development. In this second article I will give specific detail about establishing a Subversion workflow.

In this three part series of articles I will explain my approach to using Subversion, the open-source version control software, for web development.

For a long time I steered clear of version control, dismissing it as too complex, or something that was only useful for large development teams. I took Subversion for a test drive, but didn’t really “get it”, and decided version control wasn’t for me.

I changed my tune earlier this year when I was employed to work on a project that was already under version control. I had no choice but to get up to speed with Subversion, and once I got the hang of it I was excited to discover that version control streamlined my entire workflow. I now use Subversion for all of my web projects and consider it an integral part of my development process.

If you want to create your own @font-face kits, you absolutely must check out Font Squirrel’s new @font-face generator tool. All you have to do is upload a TrueType or OpenType format font, and the generator spits out a zip file containing:

The original typeface for Safari and Firefox 3.5

A WOFF font for Firefox 3.6+

An SVG font for Opera, Chrome, and iPhone

An EOT font for Internet Explorer

A sample HTML page

A sample CSS stylesheet

The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.

Now that all major web browsers finally support the CSS @font-face declaration, embedding fonts in a web page is possible with just a few lines of CSS. In theory this means that web designers no longer need to limit their font choices to a handful of system fonts, and are free to use any typeface they please. In practice that freedom comes with a caveat: we are only allowed to use fonts with a license agreement that allows web embedding.

The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.

That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

My friend John Gillespie recently wrote about the inauspicious origins of the Arial typeface, namely that it is a blatant copy of Helvetica. While I agree with the general thrust of John’s argument (I’m a self confessed Helvetica fanboy) I do think that Arial has one redeeming feature that deserves mention, especially in the context of web design: Arial renders better at small point sizes on Windows systems than Helvetica does.

Recently I was developing a website for a client whose primary export market is in China. Needless to say I was a little alarmed when my client’s representatives in China reported that they couldn’t access their new site.

My client has reps in both Shanghai and Beijing, neither of who could see the website, so I knew it wasn’t a localized issue. My immediate suspicion was that the infamous “Great Firewall of China” was to blame. Thankfully I was able to take a few simple steps to diagnose the problem and get the site up and running.

In my last post I outlined some of the problems that might arise from the proposed version targeting changes to Internet Explorer 8. My major concern was that by removing the motivation for web authors to update legacy sites, version targeting might hamper the adoption of modern web development techniques. During the week I have given some more thought to this issue, and it occurred to me that in Adobe Flash we have a fantastic real-world test case from which we might learn if version targeting is a viable strategy for a web browser.