Falling Leaves: the Ardes blog

Archives filed under "bug"

I Shall Rant About Belkin KVMs Now

Ray Drainville

On a spare machine in the studio, we had a Belkin SOHO KVM DVI switch. We got it when Ian joined as a partner, so he could hook up his laptop & use the big screen as extra real estate. It was a weird setup: the monitor was VGA (one of those ancient 21″ Apple CRT Displays, a gigantic blueberry of a thing that gave you a hernia by just thinking of lifting it), but we knew that we’d eventually move to a DVI flat-screen, so we worked with DVI-VGA adaptors for years.

It wasn’t without problems. To get it working with the DVI computer & laptop to which it was attached, we needed DVI-VGA bridges; for Ian’s laptop we needed a (get this) DVI-VGA-DVI bridge, otherwise the damn thing wouldn’t work. When we first set it up, the damned thing would screech PIP every second or so when Ian’s laptop wasn’t connected—a frequent enough occurrence as he likes to work from home. We somehow, somehow got that to stop, but the trick was lost in the mists of history & sleepless nights.

When the display finally died, nearly a decade after its purchase, I promptly got a new flat-screen monitor, an Iiyama ProLite, which is pretty nice. Finally, we could rid ourselves of those DVI-VGA/DVI-VGA-DVI bridges. And that’s when everything started going very, very wrong.

You first have to hook in your DVI cables. OK, except for the bonheaded design of the switch: there wasn’t enough room for them. I used a crimper to pull off some of the decorative plastic in a couple of places to make room for the cables. But even then, they couldn’t fit as tightly as they should have. Oh, and the PIP was back, and it wouldn’t stop.

So I Googled other people’s experience of these switches, only to find that other Mac users were in a similar boat. What’s worse, to upgrade the damned thing, you needed a) a Windows computer—so we’re out of luck there, we only use Windows via VMWare Fusion; and b) a PS/2 port on that Windows machine. Despite the fact that it supports USB. Nice foresight there, Belkin.

So in a fit of pique I ordered a new KVM switch. As we were only connecting two machines to one monitor/keyboard/mouse, there was only one game in town: the Belkin Switch. Well, I clearly didn’t learn my lesson about Belkin, because I bought the damned thing, despite the negative reviews on Amazon. And of course, it wouldn’t work when I first started it up. The clue was that the switch button needs to be firmly inserted into the switch (as recounted in one Amazon review).

But then—surprise!—it worked. Great! Back to work. Until the installation of the recent Quicktime 7.6 update, where the computer had to be restarted afterwards. Whereupon the fucker didn’t work again. The switch button clearly wasn’t the issue: it hadn’t been dislodged. What to do?

That’s when I descended into Support Hell. You’ve been there, so you know that you have to tell them everything, model, OS, setup, shoe size, anal distension limit, etc. I got a couple of very useless suggestions (unhook everything, restart, hook it back up, piece by piece), which didn’t do anything, but reading about the Quicktime update suggested that some components need to be updated. I did that & the computer came back to life. Hurrah!

Until the next restart-required software update. Are you sensing a pattern here? What solved this was, essentially, voodoo: I restarted the computer again, cleared the PRAM three times, rubbed the cat’s tail around my left eye three times counterclockwise & we were back in business.

I have a suspicion that I’ll be engaging in multiple restarts for the rest of the KVM’s life…

Font Embedding: A Real-World Example

Ray Drainville

Well! We certainly haven’t updated in a long time. Happily, the reason is that we’ve been busy, in fact the busiest we’ve ever been.

I thought I’d go over one aspect of a site we developed, as the subject isn’t particularly well-covered on the web. The subject is font embedding, also known as web fonts, which has been around as a technique—although rarely ever implemented—since the original “browser wars” of the late 1990s. As this is a real-world example, I can provide information about font rendering, display & other bugs and finally tool usage.

What is font embedding—why don’t we see it used?

First, let’s define what we’re talking about. If you search for “font embedding” or “web fonts”, you’ll get wildly differing instructions because people are talking about different things. For instance, many people will use these terms to explain how to access standard fonts on a computer via the font-family declaration in CSS. Some older pages may describe using font-face tags inline to change the usage of fonts—that is, to use Arial instead of Times New Roman for a passage of a page. Both of these techniques refer to the fonts installed on the end-user’s computer & as such pick from the list of likely fonts to use: Helvetica, Arial, Times New Roman, etc.

Neither of these is what we’re talking about, however. Back in 1998, in the CSS Level 2 recommendation, the W3C discussed font downloading as a technique to use fonts that the end-user doesn’t have installed. In this case, the browser downloads the font for use on the site in its cache—once you’ve browsed away from the page or site that uses font embedding, the font is no longer used & you cannot access it for use on your system. While the W3C discussed different formats that could be supported, Netscape & Internet Explorer opted for competitor formats that were, essentially, encrypted, PFR (TrueDoc Portable Font Resource) & EOT (Embedded OpenType), respectively. Because the font is, essentially, embedded, this is why I’ve decided to opt for the term “font embedding”.

Developers’ responses to this innovation was best described as muted. In a period where the two browsers were going hammer & tongs at each other & supporting wildly different tags & formats, developers had their hands full supporting far more basic things than font embedding. Font embedding withered on the vine, despite some attempts to revive it.

WebKit—the engine that drives Safari, among other browsers—listed font embedding as a new feature in October 2007. This has spurred re-interest in the use of font embedding, as Safari & Internet Explorer now support it.

Here endeth the history lesson.

Why use font embedding? A practical example

So, back to us. We had a client who had a pre-existing website that was rendered entirely in images. Updating the site’s content was, obviously, a nightmare & moreover, search engines knew nothing about any given page’s content. They contracted us to make it editable. Accordingly, we developed a lightweight CMS for them to handle the content.

However, they also wanted us to use their typeface, based upon VAG Rounded Thin. What were the options? Hmmm. Hmmm. Hmmm.

The options for displaying non-standard fonts

It turns out that there are four options. They’re listed here from least desirable to most desirable (in this example):

  • Image replacement. Here, they’d type their text & we’d create an image that would be displayed in place of the text. This technique is known as image replacement. This wasn’t optimal because the clients wanted to be able to change the content on the page & make it viewable by the end-user.
  • font-family. We could display the font using the font-family CSS declaration & hope that the end-user had the font. This was deemed undesirable because of its unpredictability.
  • sIFR. sIFR makes use of Javascript to replace text with a version of the desired font rendered with the ubiquitous Flash plugin. We seriously considered using this, but heavy usage (say, for every glyph on a page) makes it very slow. As a fallback, we considered using sIFR for headlines & other important items.
  • Font embedding. It’s a W3C standard & has been so since 1998. What could possibly go wrong?!

And so we began our odyssey into the world of font embedding and undocumented bugs & features. Join us as I gather up the hair that fell from my scalp & attempt to glue it back on.

Font embedding practicalities: what works, what doesn’t, & why

There are few pages on the web that give you much information about font embedding. Moreover, even though the idea’s been kicking around for a decade, because few have ever really tried to exploit it, the featured is often half-baked in implementation.

So, looking at Safari & Internet Explorer, we know that we can use TrueType fonts & EOT files, respectively. You declare font embedding in your CSS thus:

  @font-face {
    font-family: "VAG Rounded Thin";
    font-style: normal;
    font-weight: normal;
    src: url('vag_rounded_thin.ttf');
  }

That alone won’t work, however. You also have to declare where it’ll be used:

  body { font: 1em "VAG Rounded Thin", "Trebuchet MS", sans-serif; }

And behold, in Safari, it works:

This doesn’t work in the most popular alternate browser, Firefox:

This is why, in this case, we opted for Trebuchet as a fallback above in the body declaration. It’s similar enough to VAG Rounded Thin that the difference isn’t jarring. For your own work, I recommend that you look for the common font most similar to the one you want to embed. Also, because font metrics vary so dramatically from font to font be very careful in your CSS declarations. I strongly recommend using Eric Meyer’s “CSS Reset” to give yourself as solid a foundation as possible.

Incidentally, font embedding also doesn’t work in Opera:

Font embedding in Internet Explorer

Now for Internet Explorer. You have to use a tool to convert your TrueType font to the EOT format. Microsoft provide WEFT, a free tool for doing this. It’s Windows only & I guarantee that its interface will take you back to the days of Windows 3.11.

WEFT works, but there are caveats. It would ideally like to attach the embedding information directly to your pages. This is really problematic if you’re using a template-based system—which we were, as we developed the site using Ruby on Rails. What you have to do is tell WEFT to ignore your site & place the EOT file onto your hard drive.

Because its intention is to restrict unauthorised use, WEFT also wants to know what URLs are allowed to display the typeface. Happily, it supports multiple entries, so be sure to add the name of your machine. For example, I added http://localhost:3000, so I could preview my work before showing it to the client.

NB: be sure to add all the URLs you’ll require, otherwise embedding will fail in Internet Explorer:

Here it is working in Internet Explorer version 7:

And here it is, with the “L”looking like ass, in Internet Explorer 6:

So why does it look like ass? Read on.

Caveats

Well, there are lots of things that I haven’t explained about font embedding. One of the things is that it doesn’t always work well. When we converted the typeface to EOT format, we discovered that, for some strange reason, it wouldn’t show typographically-correct glyphs (like “”, —, etc.) in Internet Explorer 6. However, we were initially provided with a free rip-off version of the original font. When we converted this to EOT, everything worked fine. Now why would this be?

Keep in mind that we’re now talking about different fonts. It turns out that font makers have the ability to declare embedding rights. It’s located in the fsType. It might be that when converting the font from TrueType to EOT, some of the characters of the font wouldn’t translate. This is guesswork & I might be entirely wrong.

Another problem, which I haven’t explained, is that accessing the boldface version of the font would make Safari crash. I thought that perhaps it was because I had declared the font in an incorrect way:

  @font-face {
    font-family: "VAG Rounded Thin Bold";
    font-style: normal;
    font-weight: bold;
    src: url('/vag_rounded_thin_bold.ttf');
  }

Do you see the problem here? I’ve declared the bold version to be bold—in other words, really, really bold—and initially thought that might have caused the crash. But when I changed the declaration to font-weight: 100;, the page would render—and then crash. We don’t have an answer to this problem & we’re still investigating the source of it. Once we’ve found out we’ll post the answer as an addendum to this article—but any suggestions from you would be most welcome.

So, that’s font embedding for you. A fairly mature declaration is hobbled in part by not having been used—the more usage it had, the more bug fixes we would have seen & the process would become more transparent. But at least this is a start.

Update

Well, at least I know why Safari was crashing with the bold font now—and it doesn’t crash any longer. The solution is very obvious, actually—as things are always obvious once you’ve figured them out.

First, you declare the boldface version of the font:

  @font-face {
    font-family: "VAG Rounded LT Bold";
    font-style: normal;
    src: url('vag_rounded_thin_bold.ttf');
  }

First of all, note that the font-weight is set to normal: you don’t want to make your bold font bold twice, as it then becomes very heavy. Now, in your stylesheet, style your strong (or, if you’re Old Skool, bold) with the font’s name, thus:

  strong {
    font-family: "VAG Rounded LT Bold", "Verdana", sans-serif;
    font-weight: normal;
  }

You see that we set the font-weight again to normal: otherwise, the font becomes entirely too heavy. Voilà: complete!

And don’t forget to repeat this effort for your Internet Explorer users on your EOT files.

Update (27 April 2009): There’s an interesting article by Tal Leming about embedding web fonts from a type designer’s point of view. It’s an interesting read & Tal makes some very good points that are worth serious thought. The idea of a new type format with the option of specifying a domain in the root table is an attractive one, but he’s conscious about what this means for legacy fonts (i.e., the exclusive support of a new format would break sites using previously available fonts).

Two CSS Debugging Tips

Ray Drainville

Ian may claim to be doing nothing but git-work (and what an unfortunate name that is), but the fact of the matter is that we’re both eyebrow-deep in client work. This business has been running since April 1999 & we’ve never been so busy.

When you’re so busy, the last thing you want is a series of bugs that won’t seem to go away. Since most of my work is in the HTML/CSS/Rails templates realm, I’m speaking mostly of visual bugs, things that seemingly won’t budge no matter how much work you put into them. I thought I’d share two tips which have helped me squash a considerable number of visual bugs, one created by someone else & the other merely a process that I follow.

CSS Debugging Tip 1: Burn it all to the ground

First, the work supplied by someone else: Eric Meyer’s CSS Reset. If you’re unfamiliar with it, go & read up on it ASAP. For those unfamiliar with why you’d need to reset something your CSS, the answer is simple: different browsers have different default sizes for fonts, lists, buttons & a hell of a lot else. By resetting all these items via CSS, you help ensure that all your browsers—Safari, Firefox, Opera & the thorniest of them all, Internet Explorer—start from a common vantage point.

The idea is not new. For years I’ve employed a very basic, simple reset:

  html * { margin: 0; padding: 0; }

The problem is that this didn’t reset nearly enough things—and it often didn’t even reset everything it was supposed to! Eric’s reset is a total razing to the ground of all browser-specific sizing quirks & as such should be adopted by every designer. In my experience, it’s particularly useful for a project that you’re just starting up: my IE-specific stylesheets are a fraction of their former size. For pre-existing sites, however, it’s not going to be a magic bullet. You still assembled your CSS based on different assumptions & short of starting from scratch, it will be of more limited use (although still recommended in my book).

CSS Debugging Tip 2: Build it back up brick by brick

The second tip is merely a process that I’ve been following. I’m surely not the first person to do this, but since it doesn’t appear to be widely discussed I thought I’d write it up here.

I’m going to take a real-world example from a site we’re building. In this site, we’re using some Scriptaculous effects to aid in the creation of a visually compact secondary navigation for a database of imagery. The markup is simple:

    <h4>Section Heading</h4>
    <a href="subsection/1">Subsection 1</a>
    <a href="subsection/2">Subsection 2</a>
    ...

Clicking on the H4 tag will cause the subnavigation links to reveal themselves, or hide themselves if they’re already revealed.

Unless you’re viewing in Internet Explorer 7, that is—no, the problem for once isn’t IE6! In IE7, the links were invisible—they were clickable, but you couldn’t see them.

I tore out what little hair I had left, for weeks, trying to figure out this bug. I even thought it might have been Scriptaculous’ fault. It wasn’t, however & eventually I realised I was compounding the problem by adding CSS declarations instead of removing them—instead of trying to figure out what was triggering the bug, I was trying to pave over the bug. If you’re adding more declarations in order to fix a bug, you may very well be creating a shifting target, which is definitely not what you want to be doing. Particularly when you have a lot of other work to do.

The answer is simply a process & a very simple one at that: take your CSS declarations & strip them out. Add them incrementally, viewing in the target browser every time, until you trigger the bug.

In the example above, removing a declaration of a:link { display: block; } rendered the links visible again in IE7. I don’t know why—I’ve used this declaration countless times with no problems—but nevertheless the declaration wasn’t necessary & it was causing a big problem.

Again, though, it’s the process of stripping away your CSS & then re-implementing your declarations which is the key. It’s all too easy to add more & more to your declarations, but remember: you may only be making the job of fixing your problems worse.

Mac OS X 10.4.11 Safari Crash

Ray Drainville

If you’re running the newly-released Mac OS X 10.4.11 update & are having lots of crashes in Safari, then the likely culprit is going to be items in your ~/Library/InputManagers/ path. Some popular Input Managers include:

SafariTidy was the culprit for me. The developer, Kasper Nauwelaerts, has upgraded this to 0.2.4. I’ve not yet been able to successfully install the update, however—Safari just isn’t recognising its existence.

Input Managers act as a patch to the applications for which they’re intended, and as such are unsupported—even actively discouraged—by Apple, because they can patch applications in dangerous ways. Those of us who rely upon such items—as I am to Safari Tidy, so I can validate my work on-the-fly—are in something of a quandary. As Daring Fireball’s John Gruber implied regarding input managers and unsupported software, this situation isn’t going to get better but worse as time passes.

Because the use of the InputManager system is so bad, I’m left wondering what’s the best recourse. Tidy is really useful & there are extensions for Firefox, but none are to my mind as elegant as SafariTidy. I’m left hoping that Kasper will port his plugin to a different architecture…

Update: I just got some tips from Kasper & some very good news:

…You should put [SafariTidy] in the SIMBL plugins folder, which usually resides in ~/Library/Application Support/SIMBL/Plugins/.
Please remove all traces in any InputManagers folder you put the bundle, as this plugin isn’t technically an InputManager (anymore).

Three cheers for Kasper! I’ll be donating to him right now.

Update 2 (03/03/09): for those using the new Safari 4 beta, you’ll want to upgrade to the latest SafariTidy.