Tibetan Font Rendering on Android, iPad, and iPhone 4

June 14th, 2010 § 3

Thanks to Chris Fynn and the Dzongkha Development Commission, there is now a Tibetan font that can display correctly on Android, iPad, and iPhone 4, with some conversion and munging of the Unicode data.

In a previous post, I described how to render Tibetan on a rooted Android phone, through replacing the built-in fallback font with one (Jomolhari ) that supported the Chinese Tibetan Unicode standard GB/T20524-2006, which resides in the 0xF300 to 0xF8FF space.  This technique had a severe limitation, in that it wouldn’t work on an unrooted phone, and also removed support for Japanese, Chinese, and Korean (quite important languages in their own right).

I mentioned in that previous post that it would be possible to render Tibetan without having to root your Android phone, if you could use the technique described here, which embeds the fonts in the application and sets it on TextView objects. Unfortunately, it didn’t work with Jomolhari when I tried it, showing lots of beautiful boxes instead of Tibetan letters.  Evidently, some fonts just “don’t work” with this technique, and it was unclear why that happened; additionally this technique would have required a 2.3MB font to be contained in every Tibetan-supporting Android app.  It was large because this font was optimized for printing, so was specified in a lot more detail than cell phone screens needed.

A while back, Chris Fynn sent me his new font, “DDC Uchen,” which was designed to be used for web sites, and is only 860k, distributed under the Open Font License.   This font and Jomolhari are the only two fonts I’m aware of that have support for the Precomposed Tibetan standard.  I’ve placed it for download here.  (The DDC stands for Dzongkha Development Commission, which paid for Chris Fynn to develop the font, and is making it freely available to everyone. Dzongkha is the language spoken in the country of Bhutan.  It is very closely related to Tibetan and uses an identical alphabet.)  Just for grins, I thought I’d try it out by placing the font in my Android project under assets/fonts/DDC_Uchen.ttf, with this fairly simple code:

        TextView tv=(TextView)findViewById(R.id.output);
        Typeface face=Typeface.createFromAsset(getAssets(), "fonts/DDC_Uchen.ttf");
        // Precomposed Tibetan version of a supplication to Tara
        String tibetanText = "\u0F04\u0F05\u0F0D \u0F0D\u0F60\u0F55\u0F42\u0F66\u0F0B\u0F58\u0F0B" +
        "\uF397\u0F63\u0F0B\u0F58\u0F0B\u0F63\u0F0B\u0F56\uF43A\u0F51\u0F0B\u0F54\u0F0B\n" +
        "\uF4BA\u0F42\u0F0B\u0F60\u0F5A\u0F63\u0F0B\u0F56\u0F0B" +
        "\uF3ED\u0F0B\uF5BE\u0F0B\uF53F\u0F0B\u0F42\uF3B7\u0F42\u0F0B\u0F54" +

It rendered perfectly on my Android phone:


To convert text from Tibetan Unicode, you either have to use the libraries I’ve uploaded at the GyutrulDrawa project, hosted on Google Code, or use Andrew West’s BabelPad (Windows only).  To convert it using BabelPad, use the menu option Convert -> Tibetan -> Unicode to Precomposed Tibetan (Set A).  For these program examples, to paste it into Java code, I then used “Convert to Universal Character Name”, which generated Hex codes in \u format, and pasted it into the Android Java code.

This technique will only work with widgets which are derived from TextView, which means that this can’t be used to easily create a Tibetan Web browser.  However, other widgets such as EditText, Button, CheckedTextView, CheckBox, CompoundButton, RadioButton, and ToggleButton, as well as Chronometer, DigitalClock, AutoCompleteTextView, ExtractEditText, and MultiAutoCompleteTextView, all inherit from TextView, and so should work with this technique (though I haven’t tried it out with them).

Getting it to work on iPad 3.2 and iPhone 4

Now that we have working Tibetan font support on Android, what about the Other Phone, the iPhone?  Well, it turns out that 3G and earlier iPhones don’t support setting embedded fonts easily, but 3.2 for the iPad supports it, as described in this post.  As on Android, the iPhone doesn’t have the complex script support necessary to render Tibetan properly (in fact, the default rendering mode looks worse than on Android), but the exact same technique we used on Android works on iOS as well.

I’d worked through some basic tutorials on iPhone development, but this was my first excursion into writing my own program in Objective C, so it took me a while to get everything set right.  There are a few steps to this:

  1. Put the DDC_Uchen.ttf font in the Resources directory of your Xcode project.
  2. In your projects plist file, you have to add a Key named “UIAppFonts”, change the Value Type to Array, and then set the first (only) value to “DDC_Uchen.ttf”.
  3. Make sure you refer to the font by its actual name, not the file name, in this case “DDC Uchen,” when you use it.

Here’s some code to get it to work:

	textView = [ [ UITextView alloc] initWithFrame: rect ];
	UIFont* tibFont = [UIFont fontWithName: @"DDC Uchen" size: 22];

	if (tibFont != nil) {

		[ textView setFont:tibFont];

		textView.text = @"\u0F04\u0F05\u0F0D \u0F0D\u0F60\u0F55\u0F42\u0F66\u0F0B\u0F58\u0F0B\uF397\u0F63\u0F0B\u0F58\u0F0B\u0F63\u0F0B\u0F56\uF43A\u0F51\u0F0B\u0F54\u0F0B\n\uF4BA\u0F42\u0F0B\u0F60\u0F5A\u0F63\u0F0B\u0F56\u0F0B\uF3ED\u0F0B\uF5BE\u0F0B\uF53F\u0F0B\u0F42\uF3B7\u0F42\u0F0B\u0F54\uF591\u0F0B\uF5AA\u0F58\u0F0B\u0F54\u0F0B\uF473\u0F0D\u0F0D";

	} else {

		textView.text = @"Failed.";


This results in the following screen shot, which I took from the 3.2 simulator:


This will definitely not work on any iPhone 3GS or earlier, but I presume that it will work with the iPhone 4 (though I haven’t tested it).

The conversion routines which Andrew West offered to this project are written in C++ (here and here).  I haven’t yet ported them to Objective C, so if anyone is inspired to do this, it should allow for dynamic display of any Unicode Tibetan text by converting it into Precomposed Tibetan.  Otherwise, you’ll have to use the Windows-based BabelPad to convert each of your strings into Precomposed Tibetan, or use the C++ code and convert the strings between CString and NSString.

The next steps will be to firm this code up.  There are a few Tibetan projects (TBRC, the Trace Foundation, and Sonam Rinchen‘s iPhone apps) that are looking to use this code, so it would be best if everyone involved can keep this in the Open Source spirit by building on this bare foundation to create a common display, text entry, and reading environment for Mobile Tibetan.  Enjoy.  Gelek Pel and  Sarva Mangalam!

New Tibetan Phone Project on Google Code

January 29th, 2010 Comments Off

I just started an open-source project, “Gyutrul Drawa” for a Tibetan phone environment, seeding it with the code to render Tibetan properly on Android, at:



“Gyutrul Drawa” is Tibetan for the “Magical Net,” which is one of the core texts of the Nyingma tradition, translated into Tibetan in the 8th century from Indian sources.  Since our own modern Magical Net has appeared in the last 20 or so years, it felt appropriate to bring the name forward and use it again.

It doesn’t do much yet, but at least it renders a Tibetan web page properly in Android once you’ve unlocked your phone and installed the Jomolhari font, following the instructions at Nathan Freitas’s blog. (Note that the Tibetan Machine Uni font he suggests installing will NOT work with this, you must use Jomolhari.)

Future plans are to write a Tibetan landing page, improve the browser, and add the following applications:

  • Connections to the various IM systems that support Unicode
  • E-mail client
  • Tibetan-English dictionary
  • PDF reader with Tibetan-language buttons (to support reading scanned texts such as those from TBRC)

It may be possible to perform a similar technique to render Tibetan properly on the iPhone (and iPod Touch and iPad, of course).  I hope to test that out when I get a chance.

Feel free to contact me if you’d like to help out with this project.

Proper Rendering of Tibetan in Android

January 18th, 2010 § 12

Summary: I managed to get Tibetan script rendering accurately on Android, even without Complex Script support, thanks to a Tibetan Unicode font with support for the GB/T20524-2006 standard.

Since I’ve been studying Tibetan, and have started programming on Android, I thought I’d try out Nathan Freitas’ instructions on enabling Tibetan font support in Android.  I’m not going to duplicate his instructions here, but they involve rooting your phone and installing a Tibetan Unicode font to replace the built-in DroidSansFallback font, used to display Chinese, Japanese, and Korean.

However, once I got it working, I realized that, though the characters were indeed Tibetan, they weren’t properly laid out.  Tibetan is a fairly complex language to render properly, since it allows for quite complex vertical stacks of characters with idiosyncratic joining rules.  Here is an example, taken from a supplication to Tara, showing how it was originally rendered on my cell phone:


OM JE TSUN MA PAK MA DROL MA (Om, the Revered Lady Noble Tara)

If you don’t know Tibetan, that could look decent (and certainly mysteriously beautiful), so let me show the end result, how it’s supposed to look:


OM JE TSUN MA PAK MA DROL MA (Om, the Revered Lady Noble Tara)

Note that the letters don’t overlap anymore, and some of them have changed shape to accommodate their companions.  For example, the first syllable, an OM, has had its accents adjusted so they don’t overlap, and the shape of the NA-RO, the seagull-like accent, has been changed to anchor it off of the middle line.  The second syllable has more drastic changes, where the RA is simplified to blend in with the JA below it properly.  In the third syllable, the SHAB-KYU, the hook accent underneath, has been moved up snug to its letter.  The last major change is toward the end, where a RA subscript has been moved down to join up properly with the bottom of its stack.

Though the individual glyphs were being rendered perfectly, they were not being combined properly.  It turns out the need for better language support is a long-standing complaint about Android, and is in the Issues list as #5925.   Comment 15 is a very good description by an unidentified Google engineer of the core problems with Complex Script Support.  (If you’d like to encourage Android to support this properly, please add a comment to that issue.)  The main problem is that, though FreeType (used in Android for font rendering) renders fonts perfectly, there is no support for the ligatures necessary to render complex writing systems such as Arabic, Thai, Devanagiri, and Tibetan.

Chris Fynn is one of the main people who’s been working on Tibetan Unicode standards, and his font, Jomolhari, is my favorite Tibetan font (you can see it in the above pictures, and it’s available under the Open Font License).  He helped with Tibetan rendering in Pango, HarfBuzz, and ICU, any of which would render Tibetan properly, but none of these have yet been integrated into Android.  He lives in Bhutan, and I met him when I visited there.

Chris mentioned that there is a less-well-known Tibetan text encoding named GB/T20524-2006, which resides in the 0xF300 to 0xF8FF space. The “right way” to handle Tibetan has always been to combine glyphs on the fly.  However, since the Chinese are used to having a separate encoding of each unique combination of characters, they created a Chinese National Standard using the Unicode Private Use Area (PUA) to encode each combination of Tibetan glyphs as a single precomposed ligature.  Chris implemented support for this in Jomolhari partly in an effort to get Tibetan fonts working properly in some products (such as Adobe InDesign and Photoshop) that didn’t fully support Tibetan at the time.

He suggested using Andrew West’s BabelPad, which is a Unicode text editor that also supports all sorts of interesting conversions (including rewriting various Tibetan, Mongolian, Manchu, and Vietnamese encodings as Unicode), to re-encode whatever I wanted to display in Tibetan.  This worked once I installed Jomolhari on the handset as the DroidSansFallback.tff font.

I realized that, using Android’s WebView and WebViewClient classes, I could build a Tibetan web browser that intercepted url requests, downloaded the HTML, and rewrote any Tibetan Unicode as precomposed characters.  I would just have to implement a massive conversion table to do it.  Fortunately, Andrew West gave me a code sample in C++ that implemented this 1500-line table, and I was able to quickly port it to Java.  (BTW, for future reference, don’t cut-and-paste large C++ code files directly into Eclipse’s java editor.  It grinds away for a long time, patiently highlighting all the syntax errors for you, before it lets you fix any of them.)  It worked the first time I got it to compile, resulting in a beautiful, properly rendered web page.

A screenshot of the Tibetan WebView app.

A screenshot of the Tibetan WebView app.

I’m planning to clean up the rough edges on the browser, and release that code soon as the seed of a Tibetan open-source Android suite.  I thought that I’d make the Java code implementing the conversion available right away, even though it could also use some optimizing & clean-up, so that others can work with it.  It’s available at:


It’s very easy to use:

composedData = TibConvert.convertUnicodeToPrecomposedTibetan(data);

I look forward to being able to help out with other useful Tibetan apps, such as a custom keyboard, IM and e-mail apps, and a dictionary.  Please contact me if you’re interested in working together on these types of things.

I’ve really been enjoying the Android development process.   Running code and debugging code directly on the handset is working well, and I like how the libraries are structured.  This might be what it takes for me to get back into having fun with developing client-side Java.

May there be a great flourishing of Tibetan apps on the Android!  Ge-lek pel!

BTW, I spent some time trying to get Tibetan font support working on a stock Android phone, without having to root it, using the font embedding technique described here.  I couldn’t get it to work (just lots of beautiful boxes showing up instead of Tibetan), but they say that some fonts just don’t work to embed.  Of course, embedding a 2.2MB font inside an app might be pushing the envelope a bit, but it would be great if someone could get this to work.  Though it appears that the only widgets you can set the font for are TextView widgets, so you wouldn’t get a web browser that way, and you’d also have to re-implement a new widget set derived from TextView to get it to show up properly.

Google Nexus and Android Development

January 14th, 2010 Comments Off

Now that lots of Android-based devices have come out, and especially now that it’s moving past being used “just” for phones, but also for tablets & netbooks, I’ve decided to buckle down and really get involved in developing for the platform.  I was at CES last week, and there were several e-readers and other devices being shown there running Android, so it’s obviously getting ready to go big time. I wouldn’t be surprised if there will be Android-based TVs, microwaves, and even washing machines next year.

I’ve been working my way through the substantial platform documentation, and am quite impressed with the programming model.  Though it’s Java, it feels much more like working with ActionScript, in that it uses a lot of the more modern approaches to getting things working.  And the platform gives you a LOT more control over what kinds of apps you can develop that the iPhone platform, since you can easily create background processes and services that other apps can use, run multiple apps at the same time, etc.  This is getting me excited about developing in Java again, after having left it behind for ActionScript and Python.

I started working with Java back in the days when it was called Oak, and was a Sun research project, and spent a lot of time developing interactive client-side applications in the Java 1.0 and 1.1 days (mostly interactive e-commerce and advertising applications).  Though, at the time, the libraries were fairly simple, that was also one of the beauties of Java.  As it started being used for more server-side development, and the libraries started growing, I felt that Java had lost a lot of that purity of design.  In fact, I started calling it the “COBOL of the Internet,” since it seemed that developing in Java had become one of the most verbose ways possible to get anything done.  In my opinion, the committees extending it had massively overused design patterns to the point where you had to write a dozen lines of code to get the simplest things working.

I know a lot of people complained that Google had broken compatibility with J2ME and other mobile platforms by creating their own Java libraries, but I feel it was a necessary step to get things back to a more sane development environment.

I ordered a Nook and a Nexus, so I could work with two completely different Android form factors.  The Nook’s back-ordered for a month, so my review of that will have to wait, but the Nexus is quite a nice phone.  I love the animated boot-up screen and the animated home-screen background, but the apps I’ve downloaded and played with so far don’t feel as polished as the iPhone apps.  There’s a bit of a lack of polish, but that could be due to the relative newness of the platform, and due to the different developer culture that Android attracts (not as focused on beautiful interactions as the iPhone community).  One thing that I really dislike about the default Android skin is that it’s difficult to tell what’s a button, since the regular buttons are just bits of text with no border.  If you know you’re supposed to press them, that’s great, but without some indication that something’s able to be pressed, it’s pretty confusing.  In general, though, it shows a lot of promise.

If I were a  device manufacturer, Android would be my first choice to look at as the basis for developing  a hardware product.

CES “Butterflies”

January 8th, 2010 Comments Off

I’m at CES, but since there’s plenty of coverage of all the big announcements, I thought I’d feature some of the more beautiful yet seemingly impractical products out there on the show floor.  For some reason, these seem to be coming from Korea.  Perhaps they even have a word for something strikingly beautiful yet impractical in Korean; let me know if someone knows the word for such a thing.  They feel as if they are relics from the future, where technology is so deeply integrated into stuff that it just becomes part of the background of the object.

Unfortunately, I took these photos without keeping track of the names of the companies that produced them, so you may have to treat this as a bit of a treasure hunt.  Please let me know if you know who produced them, and I’ll give them proper credit.  Or, if I have time, I’ll track them down again today before I leave.

The first set is from a small booth in the North Hall, in the Korean section of the International Gateway.  Each of these pieces has small, iPhone-size video screens embedded in them, with animated versions of the types of traditional paintings you would find on a folding multi-panel rice-paper screen.

Video Folding Screen

Video Folding Screen

This first one is the most straightforward; it’s just over a foot high, and has eight animated videos playing on it.

Video Boat

Video Boat

This uses the same technology with six animated screens to make something reminiscent of a sailboat.  This is the first one I saw, and is quite beautifully finished with lacquer and gold leaf.

Video Fan

Video Fan

This is my favorite one, and resembles a folding fan with twelve video screens forming a continuous series of animated panels.  Due to the electronics involved that appear to be hidden in the base, I don’t believe it could be used as a fan (though it’s believable that it could fold and unfold), but in a few years, I wouldn’t be surprised if something like this becomes an actual portable product.

"Music Baggie"

"Music Baggie"

The “Music Baggie” is from another Korean company showing in South Hall 2, that has used flat, bendable Electrostatic speakers to create audio devices that can be part of textiles.  Electrostatic speakers aren’t as commonly seen now, but they used to be targeted at audiophiles.  They were also showing electrostatic headphones, but those  didn’t look as interesting, so I didn’t photograph them.  This seems like a semi-reasonable product, perhaps for high-end shopping bags.

Music Roll

Music Roll

This is by the same company and uses the same technology to create a speaker consisting of a cylindrical roll.  They claim that you can vary the audio characteristics to suit your tastes by rolling it tighter or looser.  This sounded pretty decent, actually.

Music Boat

Music Boat

My final photo is from a different Korean company also located in the South Hall, using similar electrostatic speaker technology.  Their main product appears to be transparent speaker films that you can place over displays, so you don’t have to have separate speakers from the displays.  However, I really liked this example, where they made boat sails out of the speaker film, and integrated it with a sailboat design.  Perhaps next year, we’ll see a combination of the boat-sail video screen with the boat-sail speaker to make a perfect multimedia model boat.

What happened to Perl?

May 6th, 2009 Comments Off

I dug out some Perl code I wrote a few years ago, fixing a bit of code rot, where some of the language’s syntactic sugar had changed (see, syntactic sugar rots your code), and I realized  that I hadn’t worked on anything written in Perl in a long time.  Perl used to be what Hassan Schroeder, Sun’s first webmaster called “The Duct Tape of the Internet,” but now it’s declined in importance, to something more like the Masking Tape of the Internet.  It’s still something you might want to use from time to time, but in a much more limited way, and if you’re given a choice, you’d probably want to use something else.

If you look at O’Reilly’s State of the Computer Book Market, you get a sense of what languages people are buying dead-tree books for.  Perl comes in last among the list of “Major Programming Languages”, with a 1.64% market share, behind .Net, SQL, Visual Basic, Ruby, Python, VBA, and Objective-C. Of these languages, there are only three that a Unix-oriented programmer would choose to build a web site in: Ruby, Python, and Perl.

Fifteen years ago, the choice was between Tcl (“Everything is a String”) and Perl (“There’s more than one way to do it”).  Python existed then, but wasn’t yet used heavily in web sites (the first major application I heard of was Alice, and Randy Pausch was for a while one of Python’s biggest evangelists).  In 1994 or so, when Nathaniel Borenstein (one of the original designers of MIME), and Marshall Rose (POP, SNMP, BEEP) at First Virtual decided to write the first Internet e-commerce system, they told me that they downloaded the source code for both Tcl and Perl, and decided which was better by comparing the size and complexity of the source code.  Tcl won, according to their criteria, by a landslide. (Of course, it’s a whole ‘nother post on why Tcl failed, and is an “Immaterial Programming Language” on that same O’Reilly list, but it’s probably due to the fact that it’s  pretty slow to use strings as your main data type.  But Tk has gone on to be split off and widely used all over the place.)

By the late 1990′s, Perl had become the easiest language to build stuff with on the Internet.  It did the best job of integrating regular expressions, it was reasonably fast for an interpreted language, it was installed by default on most machines, and it was relatively easy to get interesting things working.  At the time, I would evangelize Perl as well.  In fact in 1999, when I came into a horribly behind schedule project, writing a 3-layer VOIP conferencing programming using XML to interface with Java to interface to an Oracle database, where the programmers were spending months writing boilerplate code to handle marshaling data in and out of XML/Java/SQL, I wrote a fairly short Perl program in a day or two that simply queried the database and created big chunks of templated Java code to do all the layers of marshaling.  This probably saved a full programmer-year, and made it trivial to regenerate the code whenever the database changed.

However, Perl 5, the last major revision of the language, happened in 1994, just as the web started to take off.  Perl 6 has been in the works for nine years so far.  Why has it taken so long?  You can read about Larry Wall’s take on what Perl is in his fabulous essay, “Perl, the first postmodern computer language.” What I get from this essay is that Larry Wall is utterly brilliant, and put all of his genius into Perl.  But a maxim of computer programming from Brian Kernighan states that, “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”  A corollary of that would be that if you design a language or a framework as cleverly as possible, you are not smart enough to extend it.  Examples of what I view as things that may be “too smart” are things like dynamically working out whether a function is being called in a scalar or a list context, and what it will do in each case (“Again, the general rule is: There is no general rule for deducing a function’s behavior in scalar context from its behavior in list context“); as well as the massive amount  of syntactic sugar, which makes parsing a very tricky proposition, subject to a lot of heuristics and ill-defined behavior.

Here’s a good post on Bugzilla’s problems with Perl.  I won’t rehash them here, but they mostly boil down to it being very easy to write unreadable code, and it being difficult to debug (as well as some performance issues).  In particular, it’s easy to create write-only code in Perl, so easy in fact, that the “Obfuscated Perl Contest“, almost seems redundant, though not quite as bad as the Obfuscated PostScript Contest.  The famous quote from Larry Wall on this is, “I’m reminded of the day my daughter came in, looked over my shoulder at some Perl 4 code, and said, ‘What is that, swearing?’”

But probably the biggest death knell for Perl has been the rise of other languages that fit their ecosystem niches better, such as PHP, Ruby, and Python.  PHP is great for knocking together quick web sites; Ruby cleans up and simplifies a lot of the Perl  syntax and adds more modern features (more flexibility and cleanliness at some speed cost); and Python is a good, fast, general-purpose scripting language (the fact that Google uses it massively internally and has hired Guido can’t hurt either.  If it’s good enough for Google…)

Update, May 12:  It turns out, according to some Twitter-mining, that Perl actually has the happiest users of any major programming language.  I’m all in favor of happiness, so sincerely hope that Perl starts to take off again.

Why HTML and WWW Were So Successful

April 24th, 2009 § 1

Here’s a story from the early days of the web in 1993, when Mosaic had only recently come out, there were only a couple hundred web sites (most of them run by and about computer science grad students) and before it was apparent just how big the web would eventually become.

I was working in a computer graphics research lab at Brown University run by Andries van Dam, who in 1967 began one of the very first hypertext systems with Ted Nelson, and went on to work on four successive generations of hypertext systems over 25 years, all beautifully designed, eventually integrating text, images, audio, timelines, movies, and 3-D graphics, dealing with collaborative authoring, referential integrity, versioning, etc.  Even at the time Mosaic came out, there were many hypertext systems out there all of which were quite rich and complex: DynaText, Trellis, HyperCard, Hyper-G, Intermedia, StorySpace, etc.

I set Mosaic up on one of our workstations, and gave Andy a quick demo.  Besides the C.S. students’ web pages, pretty much all there was to show at the time was the Cambridge coffee pot and an interactive Tarot card page, so it went quite quickly.  At the end of it, all Andy had to say was, “So?  What’s interesting about that?”  I had been pretty fired up about the possibilities of the web, so was a bit taken aback until I realized that Andy had been building systems to do this for 25 years, so none of it was new to him.  The only thing I could think to answer was that you could follow a link from one machine to another.

In fact, the world-wide web didn’t do any of the stuff that they’d been so concerned about for all those years.  It didn’t take care of dead links, it didn’t let multiple people easily edit the same document, it had no semantic extensibility and almost no semantic markup, it didn’t handle linking to old versions, it didn’t let you mark up a text in multiple different ways, it didn’t enforce copyright, it didn’t handle payments, and so on.  It’s really interesting to take a look at Tim Berners-Lee’s original spec for the web to see what a simple system it really was.  His particular genius was that his idea duct-taped the existing systems (ftp, gopher, wais, mail, news, databases, etc.) together, so that you could easily access a remote machine by clicking on a link.  Every prior hypertext system had really been an island, requiring people to write stuff and spend time integrating it into the system, not making an effort to bridge the gap with what was already out there.  Instead, the web was useful right from the start.

And you could learn all of HTML in about 20 minutes.  There were a grand total of 18 or so tags that were actually used (even counting tags that died out like NEXTID, HP1, and PLAINTEXT).    Of course, the web really took off once Marc Andreesen added the IMG tag and released Mosaic.  What’s really funny about this is, from a system architecture perspective, the solution Berners-Lee presents in response, is cleaner and more general, and would have allowed for plugins, embedded text, 3D graphics, etc.  But Marc’s solution broke HTML in a way that let other people realize you could do something cool by breaking HTML further, and paved the way for this glorious, wonderful, multi-billion dollar mess we call today’s web.

That, I think, is why the web was so successful.  Compared with the other systems that had been around for years and decades, it was like a backyard dragster beating a Porsche.  But the early web did just enough to work, and was usable, while still exposing enough ragged edges that people got excited about hacking on it and making it do cool new stuff.  I’m sure it’s for similar reasons that more people use PCs than Macs, Python than LISP, and Unix than MULTICS.  And I try to remember this lesson when I sit down to design some new system.

Where Am I?

You are currently browsing the technology category at tom at tom dot to.