I recently read a father/daughter book written by a prominent, radical Christian psychologist. Though I certainly did not agree with all of her views, I did see a lot of common sense to her philosophy, and the book brought to light many issues that I may face in the future as my daughter matures. After reading the book I was motivated to write 156 little letters and put them in an Afghani toy jingle-truck for her to receive as a Christmas gift. I thought that would be just enough for her to read one letter a month every month until she is 18. Each letter contained a little tidbit explaining why I think the world of her etc, and I hoped that she would refer to them whenever she disagreed with one of my decisions, or when she was upset at me.
I really enjoyed writing each letter as it led to me reminiscing of nostalgic times or experiences I shared with my adoring daughter. I came to the conclusion that there is still a descent chance that she will spend a substantial portion of her growing up in my absence (I am presently halfway across the world for work). I figured I could easily create a digital “Letters to Doogle” that would allow her to view a random letter whenever she felt the urge to. The best part is that the digital version would bridge the present and possible future distance gap between us, as she would be able to read my thoughts or praises in pseudo real-time.
So this was where the idea derived. Piece of cake right? Not so much. This was one of those projects that humbled me from beginning to end. If I was in the position where I was required to submit time constraints for this project I would have missed it by a long shot.
I decided to use the back end of a WordPress random quote plug-in called quotes-collection. This allowed me to utilize the existing plug-in management console of WordPress without requiring me to write my own upload page or remember yet another password.
After tweaking the quotes-collection plug-in I began searching for web-safe fonts that resembled human handwriting. That did not return any solutions that I felt were aesthetically pleasing enough to accompany the project. It was time to do some research.
I should first backtrack and preface this paragraph by saying that it had been a good 2-3 years since I did any design-intensive work. I made the wrong assumption in assuming that technology and web standardization had since improved to reduce or possibly eliminate many of the issues we as developers were once faced with. I began searching for solutions to embed non web-safe fonts. I immediately got a glimpse of what would become my K2 Black Diamond Route. It seems that we still do not have a viable, cross-platform, cross-browser, dynamic font embedding solution. Microsoft introduced us to WEFT, (Web Embedded Fonts Tool) back when IE4 was released. Apparently people didn’t really see the usefulness of it, and since it was a proprietary solution it never really would have extended past IE support. Microsoft later introduced the EOT, (Embedded Open Type). Meanwhile developers around the world settled for fundamentally shady techniques that centered on replacing text with their associated images. Finally in 2006 there was yet another push for dynamic fonts, and the subject matter was once again debated hotly a year later at a W3C conference. By then Apple had implemented a non embedded font solution for their Safari browser. Windows decided to release EOT to W3C with the help of Monotype, who was part owner of the technology. The brightest minds the web had to offer deliberated on the subject matter hotly and eventually came to a conclusion: EOT was not the definite solution as many were a bit skeptical of potential Digital Rights Expression conflicts. So where are we today? Again the W3C organization is deliberating (September 2008) and aiming to standardize WG (Working Group) as the quid-pro-quo of EOT solutions. (If you are interested in obtaining the latest gouge, refer to this link. Presently there is no answer, other than turning to cleverly implemented scripting hacks….
Which leads me to Shaun Inman’s sIFR (Scalable Inman Flash Replacement). Shaun, along with a good number of web developers, was sick and tired of being forced to use web-safe fonts to allow for cross-browser aesthetic consistency. He decided to implement an Open Source idea utilizing a JavaScript and Adobe Flash based technology that enables the replacement of text elements on HTML web pages with Flash equivalents. Now, any browser with JavaScript and Flash capabilities can see any font that the developer chooses to use. The best part about this was actually the downside. The worst case scenario occurs when a user either does not have flash installed, or when they have JavaScript turned off. In those instances the person viewing the page would simply see the web-safe font they would otherwise be seeing if sIFR was never implemented.
Armed with knowledge that I had the capability to use any font I wanted to for the project, I ventured out to find a quick and dirty solution to creating a TTF (TrueType Font) based on my handwriting. Somewhere in between I decided that the project should be as low-fi as possible, and even opted to scan in pictures and pieces of notebook paper which would later be used as backdrops as opposed to downloading or creating my own photoshopped versions. Using my own font would further increase the authentic feel of the project as my daughter would then be literally looking at my own handwriting, on a real sheet of paper (which I really ended up using for many of the letters).
Eventually, I stumbled across yourfonts.com. Throughout this project I faced barrier after barrier and complication after complication. This site was one exception to that. In short, if you want to create your own font, go here….period. I even opted to use my font as my system font. (*is that pretentious*?)
sIFR requires users to generate a flash movie from a .ttf file. Now I did not have a flash editor, and was dismayed that the editor suggested by sIFR, Adobe Flash Editor 8, was no longer available. Again, I set out to explore the jungles of the interweb to find a solution. I eventually stumbled across sifrgenerator.com, yet another bright spot in an otherwise storm of difficulty. They allow users to upload a TTF and auto-generate a sIFR flash file specific to a nightly sIFR build. At first I decided to go with the stable release, sIFR 2.
After creating my font and moving everything over to my domain, I began implementing stumps to learn the ins and outs of sIFR. For some reason or another I could not get my font to show up at all, no matter how many forums I read and no matter how hard I tried. I began to backtrack and eventually decided to attempt the most recent sifrgenerator supported build which would of course require me to re-generate my flash movie. This time I saw my font was used on my test page, however it only informed me that the flash movie parameters did not satisfy the sIFR 4.19 requirements. So I was stuck there for a while until I noticed, very recently, that sifrgenerator.com added support for v 4.36. I again generated my movie, and installed the sIFR package and finally, whalla!
The styling took a good deal of tweaking, and I am still searching for a solution to a line-height problem I am having. None-the-less, the technology is cool, and it is nice to break free from the boring web-safe prison that we as developers have been bound by for over a decade. I will post updates to the project when I figure out the specifics of my line-height style handling failures. Until then, take a look: Letters to Doogle.