Tag: font

Categories
In The News

Common Application Bugs

There’s a curious article in the NY Times about the Common Application‘s technical glitches. The Common Application is a uniform way of filling out one application to apply to many colleges, as opposed to filling out an application for each individual college.

As a web developer, this struck me as particularly odd:

As it turns out, applicants do not have, say, 150 words to discuss their most meaningful extracurricular activities; they have something closer to 1,000 characters (Max said he eventually figured this out). And because some letters may take up more space than others, one applicant’s 145-word essay may be too long, while another’s 157-word response may come up short, Mr. Killion said.

“A capital W takes up 10 times the space of a period,” he said. “If a student writes 163 characters that include lots of Ws and m’s and g’s and capital letters, their 163 characters are going to take many more inches of space than someone who uses lots of I’s and commas and periods and spaces.”

Asked why the problem had not been fixed, Mr. Killion said, “Believe me, if there’s a way to do it, we’d do it. Maybe there’s a way out there we don’t know about.”

Sounds like the folks behind the common application need to go back to middle school and learn about variable width and fixed width fonts. If they had switched to fixed width fonts in the <textarea/> and used the same number of cols and font size it should be pretty accurate. I’m guessing some designer insisted on Helvetica or whatever they are using.

That said, are they actually printing these things out? Is there no way to do this electronically in 2010?

Back in my day (2002), I was advised to go the paper route since many still felt/feared that electronic applications weren’t being fairly considered (and in some cases not processed correctly). That was also the first year public colleges could join the Common Application as I recall. I suspect I was the last class where the majority did it on paper. I guess it’s still an improvement for a technophobic educational system.

Categories
In The News Politics

The Real Cost Of Changing NYC Street Signs

There’s outrage today over a story that NYC needs to spend $27.5 million to replace street signs because they are uppercase and federal regulations require title case. They will also now be using the font ClearviewHwy rather than what I believe is Highway Gothic (I’m no font geek).

However the headline is misleading if you read the actual article. A little common sense and a trivial knowledge of accounting (you most likely learned this in High School) will make you scratch your head.

The article even says typical sign lasts about a 10 years. They have until 2018 to make the change, which is 8 years. Assuming an even distribution that would mean 80% of the signs would have been replaced by 2018 anyway due to their age. The remaining 20% would be nearing their replacement time anyway. 20% of $27.5 million is $5.5 million. That’s the cost of the signs that will be replaced prematurely.

Even that however is not correct since the city would almost definitely use straight-line depreciation on the cost of the signage. The reasoning for this is as follows: If you have the sign for 8 of the 10 year lifespan, you got 80% of the value. Each year is worth 10% of the value.

The formula goes something like this:

annual depreciation expense = (cost of fixed asset - residual value) / useful life in years of asset

Again we’ll assume an even distribution of the remaining 20% (that’s 10% replacement per year or about $2.75 million). We’ll also assume no residual value though they are likely sold for scrap metal and have some token value.

($2.75M-0)/10 = $275,000

Now 10% of the signs are being replaced 2 years early, another 10% are being replaced 1 year early. That’s 3 years of value lost. That means:

$275,000 x 3 = $825,000

The actual cost to the city is $825,000 in lost value due to prematurely replacing signage. Not $27.5 million. I guess you can throw in a little more for labor, though I doubt you’ll get $26M and change out of that.

Categories
Mozilla Web Development

Optimizing @font-face For Performance

You want to use @font-face, then you realize it’s got some downsides. First of all, it’s another http request, and we know that the golden rule of web performance is to keep http requests to a minimum. Secondly fonts aren’t even small files, they can be 50k+ in size. Lastly the lag of fonts loading last means you page seems to morph into it’s final form.

Here’s a cool little optimization. By using a data: url you can use the font inline by encoding in base64. For example:

@font-face {
    font-family: "My Font";
    src: url("data:font/opentype;base64,[base-encoded font here]");
}
 
body {
    font-family: "My Font", serif
}

You can see this in action here. This seems to work fine in Firefox 3.5, and Safari 4 (presumably any modern WebKit based browser). Other browsers will simply act as if they don’t support @font-face.

In practice I’d recommend putting it in a separate stylesheet rather than inline css so that your pages are smaller and css can be cached for subsequent page views.

Data url’s are part of Acid2, which most modern browsers either pass or plan to pass. If you use an Open Type font you’d get pretty decent compatibility (IE only supports Open Type). Using True Type you’d still get pretty good compatibility sans IE. Check the @font-face page on MDC for more details. Unlike images, browsers that support @font-face are likely to support data: url’s as well, making this a pretty good solution.

Special thanks to Open Font Library for having some nice free fonts with awesome licensing. This post was partially in response to a comment left the other day on my @font-face hacks blog post.

Categories
Mozilla Web Development

@font-face Hacks

I’m going to make a bold prediction on the night before a certain web browser is scheduled gets an upgrade. @font-face (MDC) will change web design, but not just for typography. As I suggested a few days ago, to use a font on the web it needs to sit on a webserver so the browser can download it, hence the website is “distributing” the font. Licensing for many fonts doesn’t currently permit this, making @font-face for fonts somewhat problematic and hard to use… at least today.

Cool Trick!

Rule #1 of Steve Souders popular book “High Performance Web Sites” is simply:

Make Fewer HTTP Requests

That said, @font-face can be essentially as an image sprite by creating your own font with the glyphs you want. Unlike image sprites they aren’t hacky in nature requiring tricky coordinates, nor are they obnoxiously memory intensive (and a drag on mobile devices). Firefox also loads fonts last, so you can be assured it won’t slow down the rest of your page. They also degrade nicely for devices that don’t support them.

Of course this changes webdesign to use simpler icons and pick 1 color per glyph… but there are some pretty interesting enhancements for example the ability to scale. Fonts are designed to resize much better than an image.

The other caveat is that this can make your markup slightly ugly. However it’s not so bad when your building something in JavaScript. Consider for example implementing Pac-Man. Rather than a dozen images, or some complex sprite you can simply move <em>p</em> around. You can have quite a few glyphs in 1 font file.

Of course you can also use <canvas/> or a data: url to embed images, but IE doesn’t support <canvas/> and only recently started supporting data:. IE has supported OpenType (not TrueType) fonts since IE 4.

I’d be curious if anyone actually implements this and how well it works in practice. It’s not a true replacement for image sprites, but for a few cases, such as simple icons, it could actually do the trick.

Um What?

This trick can also be engineered to work against the way the web traditionally works. For example, I could create a ROT13‘d font or any other encoding I imagined. This essentially lets you remap the way characters are on the page, and the way they appear. For example on the page may appear:

<span class="rot13font">rknzcyr@qbznva.gyq</span>
<small><strong>Note:</strong> Do not copy/paste my email address</small>

That looks like a totally invalid address, but with a ROT13 font, you’d know what it is… though if you copy/paste it you’re going to get the encoded version. (I could in theory course engineer some JS to ROT13 the string). This also could deter some spam bots, which lore says have found ways around JS munging.

Conclusion

Moral of the story: @font-face can be fun for more than just typography. Cult of Helvetica be damned… all you typography geeks.

Categories
Apple

Resource Forks Suck

Dear Apple,

Please kill off resource forks. They add an unnecessary complexity to data archiving and management that’s unneeded by todays standards. Since Mac OS X it seems only a few places exist where resource forks are actually used. For example the older pre-Mac OS X “font suitcases” used a resource fork, while the modern “Data Fork Suitcase Format” as it’s name implies, does not1.

One could argue keeping resource forks is good for legacy purposes. But since Mac OS X 10.5 can no longer run Classic even on PPC systems, is there really a need?

If that’s really not possible, could you please make rsync suck a little less?

Ideally since rsync 3.0 looks like it will be a lot better, make it a high profile download for Mac OS X 10.4 and 10.5 similar to what was done to push Safari 3.0. That would be a nice stop gap solution.

I hope you’ll fix this since it’s a real pain in the butt for people like me.

Thanks,
Robert

1. 25251 Mac OS X: Font file formats