I'm sure they're great for photographers and print designers and so on. The problem is, on the web, we deal with browsers and image formats that don't support colour profiles. With a few exceptions, we can't use them even if we want to. That means an embedded profile is usually worse than a nuisance, it's actively harmful: when saving out JPGs and GIFs the colour often shifts from what's intended to something very different.

The answer seems to lie in turning off colour management for the RGB space, which helps when creating brand new source files. But what happens when an existing file has an embedded colour profile? How do you get that to render accurately when saved out to a web-friendly file format?

A couple of years ago I wrote up my best guess. Converting from whichever profile the source file uses to a generic monitor profile would get you closer to an accurate result when saved out as a GIF. If I have source imagery in sRGB, a quick convert to the generic "Color LCD" profile takes care of things.

And that's probably as far as most people will ever need to worry about. It's good enough for most web work. But I just stumbled across a problem that, while an edge case, has turned me around completely. I used to think colour profiles were a solved problem. Now I have to wonder whether I can ever rely on them.

Over the weekend I released a new, free mini-set of icons. This is the first time I've produced a Chalkwork set on a new computer; since I started working on the set a few years ago I had done everything on an iMac that I no longer own.

That's relevant because when I was originally struggling with this colour profile issue, my solution was to convert from sRGB to a profile called "Working RGB - iMac". I had embedded the results of that particular profile into an icon set with thousands of files, and going forward, I needed to continue using it to ensure any new sets would match my previous work. This is an icon family with a common palette; colour precision is pretty darn important.

I realized I needed to save out that profile somehow. There still doesn't seem to be a facility built in to save and load custom colour profiles as of CS4, but you are able to expose the numbers behind each profile by selecting it in the Convert To dialog, then immediately after selecting "Custom RGB". This pops up a new dialog with Gamma, colour temperature and so on. You can set these values manually using the same dialog, so I figured this was a roundabout way to save and load a profile.

Sometime last year I pulled out all these numbers and saved them on my hard drive as a text file that looks like so:

Name: Chalkwork Icons
Gamma: 1.80
White Point: Custom
          x        y
White:  0.2819   0.2942

Primaries: Custom
         x        y
Red:   0.6331   0.3404
Green: 0.2855   0.5943
Blue:  0.1273   0.0603

Armed with that file (which I don't understand in the slightest) and detailed instructions for myself about converting profiles and saving out the icons every time I produce an icon set, I figured I had my rear covered for the next time I wanted to do it. You can see where this is going: the profile above isn't even close on the new computer. I ended up spending an hour or so testing different profiles to find a new one that was closest to the original, and the one I had previously saved isn't it.

Below you'll see two icons saved to various profiles, the arrow is from an older set and the credit card is from the new set:

With the exception of the actual icon files on the far right, each is saved using my regular process: I took the raw, unprofiled pixels, converted to sRGB, then converted to the respective colour profile, then saved. (Though with the sRGB example I did convert back to a generic color LCD profile for the sake of rendering it accurately here.)

The differences seem a bit slight in some of them, so I've taken the blue outline colour and filled an entire block with it in this next image which more clearly shows the differences:

It took a lot of experimentation, but in the end it seems that Apple RGB is currently the closest match; even in the blue strips it's hard to see any difference, but there's a block above the word "Actual" which is slightly duller (#1C356C vs. #19366E) that shows the difference between the old icon save process and the new one. It's a slight difference, sure, but knowing that I can never match the older icon sets precisely is going to bug me.

So I'm really not sure what I've learned here. I think I fundamentally understand colour profiles at this point, but I don't seem to be able to duplicate past results using them. Is it a version difference between CS2 (what I used prior) and CS4 (what I'm using now)? Is it a hardware difference between two Macs? I thought the entire reason for profiles in the first place was to alleviate those issues. I need precision, but I don't seem to be able to achieve it.

My ideal of having a way of carrying a previous profile forward doesn't seem to exist, so I'm really not sure how to plan for future icon sets. My best guess is to hope that sRGB and Apple RGB stick around, and rely on them in the future; will my next Mac produce the same results that this one does? Who knows. I can't trust that what I just did this past weekend will work in the future. And that really bothers me.

Anyone from Adobe well-versed in colour profiles would be more than welcome to respond here.

So the technology that allows us to embed custom fonts is more or less here, but the licensing debate rages on. Richard Rutter and Simon Klein have written a great pair of posts summarizing the concerns some foundries have with embedding, while countless other opinions have come out in favour of both addressing and ignoring these concerns.

But this is really for the foundries and the browsers to figure out. What you or I think should happen probably isn’t going to change the outcome of the debate; only overall trends in the market have a hope of doing that. So it seems to me that if we want font embedding to take off sooner rather than later, a change in our own methods and expectations is in order. And maybe a little voting with our pocketbooks.

Designers — myself included — are hoping for a wide open playing field; that’s not going to happen yet. What we can have, however, is a larger field than the one we’ve been playing on. There are countless free fonts out there that have commercial-usage licenses which allow for embedding. Yeah, a lot of them (if not most) suck. But there are resources like FontSquirrel and the webfonts.info wiki that are collecting some of the better ones, and the list is only going to increase over time.

If I were to start using font embedding now by, say, designing sites that use only those fonts I know to allow embedding, it opens up my options and causes me to start seriously considering embedding as a legitimate tool in my toolbox. The available typefaces may be limiting, but they’re bound to be a step up from Georgia and Arial everywhere. If enough designers are doing the same, and font embedding becomes a fairly common practice on the web, the foundries may see that they’re effectively being ignored by this medium. Perhaps then we’ll start seeing some actual change.

I’m going to try it. Let’s see what happens.

(This article was set in Museo Sans, a typeface by Jos Buivenga using the Cufón library. There are clearly some problems with the latter, as noted in the comments below; I doubt I'll be setting full pages using Cufón, probably more like just headers. However, I decided to make an exception for this article for the sake of playing with it a bit.)

retraining myself not to /> close img, input, and meta tags. It's an uphill battle.

Which received an instant string of responses asking, in a nutshell, “why?” So I clarified:

because I'm done with XHTML is why. Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Which caused more replies and follow-up emails than I was really prepared for. People are still passionate about this stuff, which kind of surprised me.

So I'll take the luxury of a few more than 140 characters to expand my thoughts. Within the last few months — though I'd been intending to do so for much longer than that — I made the decision to switch all my client work starting point templates from XHTML over to HTML 4.01 and start delivering everything as plain old semantic HTML, minus the X.

The XHTML/HTML choice still seems to be a bit of a dilemma, with most having a fairly established opinion one way or the other. Some love XHTML for its strict syntax and easier learning curve, some despise it for being so misused by the average content producer.

I made the switch more because of overall trends. Six years ago, many of us thought XHTML would be the future of the web and we'd be living in an XML world by now. But in the intervening time it's become fairly apparent to myself and others that XHTML2 really isn't going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today's browsers, XHTML2 is a non-issue. No browser support, no use to today's web authors. End of story.

And as a result, there seems to be a shifting of consensus from "XTHML is the future of the web" to "XHTML2 is pretty much never going to happen, looks like HTML5 is the pony to back now". For proof, just compare how fast the major browsers are implementing HTML5 features now to the significant steps they've made with XHTML2 over the past 5 years (hint: crickets are chirping).

Not to say that HTML5 doesn't have its own set of problems; I've been seeing a lot of the same blog posts you have regarding the difficulty of implementation today, and the working group issues plaguing its development. It's got a long ways to go. But if I were to make a bet on which of the two languages I'll be writing in ten or fifteen years, HTML5 seems like a safer bet.

So given that I've lost faith in XHTML, it doesn't make much sense to continue propagating it. I'm not ready to start working through the contortions needed to make my sites work with an HTML5 DOCTYPE yet, which leaves me with the most recent implemented version of the language. I may start writing HTML5-ready HTML 4.01 like Clear Left did for their UX London site, but until I get a better sense that HTML5 has arrived, 4.01 will do me just fine for the next four or five years.

Update: Jeff Allen points out in the comments that UX London does in fact use the HTML5 DOCTYPE. So, to clarify the above point: I may start writing pseudo-HTML5 markup using classes like Clear Left does, however I'm not quite ready to use the actual DOCTYPE as they did.

Keep in mind this is really just one opinion in the fray. I'm not necessarily right, I'm just offering my personal response to what I see as the trend.

I donated when he first put up the page, but noticed that things have tapered off a little since then. They're getting much closer to the adoption date and he's still only a third of the way to his original goal.

So I decided to help more:

For the next two weeks, every dollar that comes in from any Chalkwork icon purchase will go to the Snook Adoption Fund. I think what Jon and Michelle are doing is great, and I hope by deciding to donate the full amount to their fund you might consider helping us get the word out too, be it by blog, tweet, Facebook, or anything else. I've got banners on the explanation page, or you can just link there.

(And I was almost going to leave this post till tomorrow owing to the annual Internet Annoyance Day, but let's just agree to overlook the date, okay?)

Update: Jon's got the details, but the adoption has unfortunately been cancelled, so the fund drive is now over.

I stumbled over one of these on Amazon and posted an image here last week, but the comments quickly pointed out that this was far from a unique case. Google, Yahoo, and Apple are also doing similar, and those are just the ones I've found so far. Yahoo even documents the practice on their Developer Network and the Flickr code blog.

The problem is making a site with multiple UI elements load quickly. There's a lot of overhead if your design requires dozens of UI images and icons and the like. File size isn't the only factor, each image is called with a separate HTTP request, and the more of those you have the longer your site takes to load. At Yahoo and Google traffic levels, it's vitally important to think about how many million users a day a site is losing to long load times.

The solution? Cram as many UI images as possible into a single image, then use selective CSS to clip and only show the relevant part of the image:

Yahoo Google MobileMe

Andy King has written up a great how-to guide on implementing sprites this way. He does warn that the method isn't without its issues — some devices (the iPhone being the most notable) apply the sprites in a memory-intensive way that slows the device to a crawl.

I also wonder about the pop-in effect; when your entire UI is in one or two larger images that take a second or so to load, the site will render without images for that brief time then pop in all the images at once. This reminds me a bit of the FOUC of old, but in a slightly less jarring way. Probably a necessary evil in this case.

But the question I've had on my mind is whether I should start doing this myself. Should all the sites I build use Sprites this way from now on?

I've started playing around with this all-in-one approach for UI images, and I'm finding it quick going and fairly simple to do. From Photoshop, I crop my source images and prepare to save, but rather than export to a JPG / GIF / PNG I'll instead take a flattened version of each image and place it in a new document that becomes the master, saving out the entire thing to an optimized image. (And if I go with PNG, it's worth also running a non-Adobe PNG compression tool against it, something like Pngcrush or PngThing.)

Planning for repeating images is a bit trickier, but I think the MobileMe example serves as a guide. Have one image per row, leave room between each, and have the repeating bits span the entire master image width rather than the smaller 1 pixel strip you might traditionally have saved out. The extra overhead will compress fairly well, and it seems fairly certain that the fewer HTTP requests will more than make up for it.

So, back to the question at hand, should I be building sites this way? I think the answer is: sort of, yes.

It does require more work. Applying the section of the master sprite image you want to show up takes time. And you really need to carefully plan out that master sprite image to ensure the wrong slice doesn't show through on text-resize or in unplanned text wrapping situations. I don't see every site benefitting enough to justify the time overhead.

Of course, the maintenance is also easier; need to change the colour of a UI element? Just edit the master and re-save one image. Done. Need to add more images? Make the master a little larger and drop 'em in. Done.

Web applications where a quick-loading and responsive UI are essential seem like the perfect fit. Sites with a common set of design elements that are used globally across the site might also benefit.

But I doubt most sites will require you to go as far as the every-image-in-one like the MobileMe example; a lighter approach of, say, combining all the icons into one image file like Yahoo is likely good enough most of the time. And simple wins like taking a box with rounded corners which traditionally would have been three separate images (one for the top, repeating middle, and bottom) and combining those three into one is fairly trivial to pull off.

The main change I expect is that I'll likely look for ways of reducing the overall number of images I save out for each site in the future. If I can see a quick way of combining a half dozen into one, I'll do it. If I can't, oh well. If I end up with 12 images instead of 20, that's probably optimized enough for the majority of sites I'll build.

If it hasn't yet, this will happen to you. Many times. My favourite advice ever on the subject came from Jeffrey Zeldman:

"Don't worry about people stealing your design work. Worry about the day they stop."

But you'll probably still want to let the person know they're in the wrong. This is how I handle it.

First, I wait until I've cooled off some. Acting immediately is a bad idea, no matter how tempting.

Second, I send a non-accusatory email. Sometimes I'm polite, sometimes I'm terse, but I avoid appearing angry. I tell them I've noticed some similarities. I ask for an explanation. I sometimes provide reference screenshots or URLs of the original material.

There are two sides to every story, and they want a chance to tell theirs. It was probably an honest mistake. A shady contractor did it. An intern didn't know any better. They used my design or copy or code on a mockup that was never meant to see production.

I may not believe that. In most cases the story probably isn't true, but it doesn't matter. What does is their next action.

Nobody likes to be accused of doing something wrong, but I started the dialogue by giving them the benefit of doubt so we avoided that. Chances are they'll be willing to own up to their guilt, then take any action necessary to remedy the situation. In most cases, this is exactly how it happens.

And when it does play out like that, I thank them for handling it properly. It was a learning experience, and I'm willing to bet they won't be caught doing it again.

(Of course when it doesn't, then it may be time to call in the lawyers. Or internet mob justice squad. Linking, Twittering, serving notice, public shaming etc. should only be a last resort.)

I've come to realize that my content-creating has become a lot more distributed, which means the long-form post format of this site has been seeing less and less love in recent years. Much has been written about Twitter killing the urge to write longer blog posts, and I won't dispute that as a cause. I liked Andy Budd's take on why his site has been suffering, I can relate to a lot of those reasons.

So for the past month I've been working on a way of piecing together content I produce on other sites and funnel relevant bits into a stream that I could present on this site.

You're now seeing the result. I'm merging my traditional posts with links from Delicious and Google Reader (which is what I was up to when I wrote about the latter's API), photos from Flickr, and Twitter posts (or tweets, if you prefer). The home page, archives, and primary Atom feed all work on this new system.

Totally nuts, right? The volume will be too high, and nobody wants to see every photo I upload or hear every inane thought I come up with while out for dinner. So that's why I'm exercising editorial control and only bringing over the bits and pieces I've hash- or machine-tagged.

Photos on Flickr, for example, can be tagged as either mezzoblue:post=description or mezzoblue:post=photo. Both tags will show the photos here, in slightly different configurations (see the bottom of the August 2008 archive for both).

On Twitter I'm using a hash tag (#mb) which shows up in the original, but I'm stripping from the on-site version. Google Reader pulls in shared items tagged with mezzoblue. And I'm just throwing in everything from Delicious for now, since I got into the habit of using it for the now-deprecated mezzoblue Dailies.

I'm still not sure if I'm going to write up the scripts I built to make this happen, or package it up into some kind of actual open source release. I think the latter way would be more interesting, but there's a lot of work that would have to happen to get to something even slightly worthy of putting out there for public consumption.

Now I do realize that not everyone will want this of course, so the way this site used to work isn't gone. You can follow the clutter free post-only feed, or browse just my original posts on the traditional archive pages. Both are accessible from the main archives page, and will continue to exist. It's just the defaults that have changed, but you can go ahead and ignore all the new stuff if you want.

Expect a few bugs as I stress-test my scripts live over the next few weeks, and let me know if you find anything horribly wrong.

Update: and first major bug has been found: the full Atom feeds weren't ready for prime time at all. For now I've backed out and made the default feed post-only again until I can figure out what's causing old items to duplicate. Sorry about the collateral damage to your feed reader.

Aside from a nice iPhone-optimized version, one of the new toys I picked up in the switch is an unofficial Google Reader API. It's been in an unofficial state for a whole three years now, with no sign of an actual release, so documentation is sparse at best. This wiki seems to be the definitive source, and for non-programmers like myself, it's mind-bendingly vague.

One of the speculative reasons for the lack of an official release is the authentication currently necessary to log in and start using the API, and that proved to be exactly what I've spent the past few days banging my head against. Unless my Google-fu has weakened, there doesn't appear to be much publicly-available code for using the API, and virtually nothing in PHP. So I figured I'd share what I came up with.

This is a script for logging in with your own account and pulling out your latest unread items in the form of an Atom feed. Drop the script on your server, change the login id and password, and it should work as intended. I haven't explored much yet, and probably will never do anything beyond read-only, so you're on your own past this point. But hopefully it'll save someone a few hours anyway.

// ----------------------------------------
// Google Reader Authentication in PHP
// a basic script to get you in the door of 
// Google's unofficial Reader API
// by Dave Shea, mezzoblue.com
// ----------------------------------------

// cobbled together from notes on:
// http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

// these are the urls we'll need to access various services
$urlAuth = "https://www.google.com/accounts/ClientLogin";
$urlAtom = "http://www.google.com/reader/atom";

// our array of login data
$login = array(
  "service" => "reader",
  "continue" => "http://www.google.com/",

  // Google id-only of the account holder
  // ie. for example@gmail.com, just use example
  "Email" => "google-id", 

  // the account's password in plaintext
  "Passwd" => "password",

  // an identifying name for your script, can be anything
  "source" => "my reader script",
);


// first step is to authenticae
// let's build a POST request using the login data array
$postRequest = "";
foreach($login as $field => $value) {
  $postRequest .= $field . "=" . $value . "&";
}

// start buffering what we get back
ob_start();
$ch = curl_init($urlAuth);
curl_setopt ($ch, CURLOPT_POST, true);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $postRequest);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, true);
curl_exec ($ch);
curl_close ($ch);
// throw the buffer into a variable
$loginResult = ob_get_contents(); 
ob_end_clean();

// we just received three lines of ugliness to contend with.
// each line is a huge string preceded with an ID
// the IDs are: SID, LSID, and Auth; we only want SID
// let's use some string parsing to weed it out
if ($i = strstr($loginResult, "LSID")) {
  $SID = substr($loginResult, 0, 
    (strlen($loginResult) - strlen($i)));
  $SID = rtrim(substr($SID, 4, (strlen($SID) - 4)));
}
// so we've found the SID
// now we can build the cookie that gets us in the door
$cookie = "SID=" . $SID . 
  "; domain=.google.com; path=/; expires=1600000000";


// this builds the action we'd like the API to perform
// in this case, it's getting our list of unread items
$action = $urlAtom . 
  "/user/-/state/com.google/reading-list";
  // note that the hyphen above is a shortcut
  // for "the currently logged-in user"


// start buffering what we get back
ob_start(); 
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $action);
curl_setopt ($ch, CURLOPT_HTTPGET, true);
curl_setopt ($ch, CURLOPT_COOKIE, $cookie);
curl_exec ($ch);
curl_close ($ch);
// throw the buffer into a variable
$xml = ob_get_contents();
ob_end_clean();

// and finally, let's take a look.
echo $xml;

Of course these days it's becoming more common to check in for a flight from a browser window and print out your own boarding pass before leaving for the airport, but I've been wondering why the printing part is necessary. I've heard reports of varying success from others who have attempted going purely electronically, so I made sure to have a paper backup in my bag for this one. Just in case.

At Home

There's an iPhone application called AirSharing that acts as a basic file server as well as a document viewer for a lot of common file formats, all on your phone. I managed to grab a free copy during a promo months back and though I hadn't yet put it to use, this seemed like the best way to get a nicely-formatted boarding pass onto my phone's large screen.

At the end of the web check-in you're asked to print your boarding pass, which I did, but I also "printed" a second time to PDF. For those not familiar, OS X has a built-in PDF generator that acts as a virtual printer; anything that you can print to a piece paper, you can also save to an identically-formatted PDF straight from the operating system's standard print dialogue.

Connecting to my phone was a simple matter of hitting a button in AirSharing to find out my phone's IP address, opening it as a server from my Mac (Cmd + K in the Finder), and there is no step three. Once I had my phone's shared folders showing up in Finder just like any other computer on the network, I dragged my boarding pass PDF into one of them and verified it would render properly on the phone's screen. The text and scanner codes were legible, if a little small, but it otherwise looked exactly like my print-out.

Update: why didn't I just mail the PDF to myself and open it in Mail? That question was posed in the comments, and the answer is because I just didn't think of it, not being a regular Mail user myself. So that's another way of having a local copy of the PDF on your iPhone.

Giving myself an extra hour just in case, off to the airport I went.

At the Airport

Upon reaching the web check-in counter I presented my ID and flashed my screen-based pass at the gate agent, asking whether this was going to work or not. She didn't have a clue, no one had tried it before (that she knew of). Since I'd already checked in online it didn't need to be verified at this stage, but she helpfully offered to try running the scanner over the bar code and see if it registered. It didn't. I suspect it wasn't the screen that was the problem here, it was the software. I couldn't zoom the code up to full life size, so the resolution was definitely less than optimal. Possible feature request for the next version of AirSharing: a higher zoom level.

Anyway, one checkpoint down, a bunch to go. Most major Canadian airports — Vancouver included — have on-site US immigration and customs booths you're required to clear since many flights between the two countries are treated as domestic flights on the US side. So this means more places I need to show my boarding pass.

Before customs a fairly redundant document parser stopped us all to check documentation, just to make sure we've got everything we need to make it through the next few steps. I showed my phone, and hit my first speed bump. A confused stare and a moment's hesitant pause, and I was asked if I had a paper pass? This is the paper pass, I countered with. Exactly the same as what would have printed out, just on a screen. Well, he wasn't at all sure about that, and as soon as I helpfully mentioned I had my paper pass in my bag if it was absolutely necessary, he decided it was, indeed, absolutely necessary. After fishing out my printed pass, I showed him paper and screen side by side to prove the point, and continued on.

The next step was US immigration control. I presented my passport and customs form, and was asked to produce my boarding pass. Handing over the phone, the only comment I got was "boy, I'm getting old" as he squinted to make out the tiny font. A bit of banter about the difference between Canadian and US thanksgiving later, and I'm on to customs, which is a freebie for the purposes of this experiment since they only needed my customs form.

Security was up next. The first checkpoint happens as I enter the line, where a women with a highlighter walks through the line to verify everyone standing there actually has a flight to catch. When she got to me I once again handed over the phone. A bit of a pause, an exclamation of interested surprise that this was possible, and a bit of confusion over the next step ("You may not want to circle this one with your marker" I jokingly cautioned), and she let me through.

As I reached the front of the security line and started the disembarking process of my personal effects for screening, the guy on the other side of the conveyor belt started asking for my boarding pass, halted, and grabbed a folded up piece of paper I had set down. That was the paper backup I had pulled out earlier, so I started to explain that I had... oh forget it, I thought, this one was a miss. But then he noticed that it hadn't been circled back in line, so I pulled out my phone and continued the explanation. He seemed to get it, but thought maybe it was more common on the domestic side since he hadn't seen anyone do this on his watch. Either way, I was let through, and that got me to the gate.

A few hours of delays and inedible airport food later, and it was finally time to board. I decided to be at the front of the line, in the "may need extra time boarding" group since I was worried that the too-small-to-scan barcode would end up holding up the line. Instead, as I handed over my phone to the ticketing agent, I got an amused "this is so cool!", a verification of my seat number, and a wave on through.

So I made my flight, and finished this post in a Starbucks in LA.

Conclusions

Out of the six checkpoints I encountered on my way through the airport, the only one who forced me to fish out my paper pass was a relatively inessential precursory check. And now that I have some actual experience to back me up, I expect that's one I can talk my way through by showing a bit of confidence in my electronic pass next time.

Still, though I have no doubt we'll all regularly use electronic passes in the fairly near future, this feels like the early days. I decided to play my experiment as a light-hearted attempt at something new, rather than insisting this was a legitimate method. If it doesn't work, no big deal, I have paper in my bag I can also show. This attitude likely helped, and will help in the future until this is more common and those working the various checkpoints have encountered screen-based passes a few times, checked with their supervisor, and made sure they're not doing something wrong by letting the holders through.

Before each checkpoint I made sure I had AirSharing loaded and the pass up on screen and shown in the right orientation (landscape worked better than portrait since the type was larger). Wasting time by messing around with a screen after being asked to produce documentation feels like a great way to stack the odds against acceptance of the electronic pass, so I jumped out of line a few times to ensure it was ready to go.

Though I didn't really think of it at the time, it may be that I dove into the deep end by testing this on an international flight. Domestic flights have fewer checkpoints, and presumably there's a little more leniency for new methods of ID and boarding. At the very least you're only dealing with a single country's regulations. I probably would have tried domestically a few times before attempting an international flight, were I in the habit of regularly flying within my own country. Which I'm sadly not.

I also think a more capable zoom function in AirSharing (or some other PDF viewer) would make things a bit easier. Not being able to read what's on screen likely doesn't help sell the electronic boarding pass. I flew Alaska, whose web-printed passes have tiny type to begin with.

Will I attempt it again? Sure, but I'll keep covering my bases for now by having a paper boarding pass on hand and only trying this in airports where I speak the predominant language.

Chalkwork Flags

First up, a set that was quietly launched back in September but not really announced at the time, Chalkwork Flags. Just prior to this summer's Olympics I was working on a project that required a small set of flag icons, so I spent the rest of the games cranking out my own set of every sovereign nation on the planet.

I'll admit, these flag icons were the most fun I've had creating icons so far. Having existing source material with many common elements and a pre-defined style and palette made the design decision-making a lot easier, so they came together awfully quickly, which was a nice change of pace.

Chalkwork Editing Controls

Next, just finished last week is Chalkwork Editing Controls, a set of WYSIWYG-like icons for text and graphical editing. I trolled the toolbars of popular design and word processing software to put together a list of the most commonly-used controls.

The first pass seemed awfully grey; a lot of the icons didn't have an inherent colour, so I stuck with a common palette to make sure they'd sit well next to each other within a toolbar. But the result ended up a little too monochromatic for my liking so I went insane and produced 11 different colour variations for most of them, making this the largest set I've produced by a long shot. I don't recommend doing this.

(A special thanks to Anton, Juliette, John and Sam for responding to my Twitter request for a bit of critiquing, your input definitely made for a better set.)

Chalkwork HTML

And finally, to show my appreciation for your putting up with this purely commercial post, I have an entirely free set that you can download right now. Chalkwork HTML might even be useful, too. It contains 31 icons that cover common markup elements and actions. Plug 'em into your wireframes, use them on your web sites, or anything else you can think of. They're yours for the taking, and available in all sizes and file formats that the rest of the Chalkwork family comes in.

There are colour variations of this one too, but you only get those if you buy Editing Controls or the Collection. Freemium, baby.

Chalkwork Collection

As always, you can get every single Chalkwork icon I've produced thus far (almost 1,800 in total at 3 different sizes) in the Collection, which at a revised price of $249 is still a lot cheaper than buying them individually.