LevelsOfDetail

Microsoft has a pretty strong reputation for maintaining backwards compatibility for applications that run on their platform. They have to, since the continued operation of many thousands of critical applications depends on them doing so. Microsoft understands this special position and responsibility, and has put an amazing amount of work into keeping old program working. Just study up on the base Win32 C API to see what I'm talking about.

What's surprising, then, is the debacle of the Internet Explorer 7 release. Surely, with IE 6 having such a large market share, it would not be difficult to realize that there many web apps out there that depend on the platform provided by the IE6 HTML and Javascript runtime. Yet, even under such obvious circumstances, Microsoft released IE 7 which broke many a website, even forcing some organizations to avoid it all together.

This blunder seems to indicate a few things. Microsoft still doesn't really understand the significance of web apps, nor their existing presence in this area of technology. They could have released a significantly enhanced IE7 that didn't break IE6 sites, at least maintaining their market share, and perhaps allowing websites and organizations to jump on new IE7 features without hesitance. Instead, they made everyone realize the importance of web standards and probably also made a few people take a good look at Firefox (both are good things).

For a company that had historically done pretty well at releasing mostly strict improvements to their previous products and, most importantly, maintaining backwards compatibility for applications, IE 7 (and Vista, to also to a large extent) seem like a great departure from their winning strategy. Maybe this is on purpose, but it's hard to see how this has worked to their benefit. It seems counter to the strategy of taking advantage of their market dominance and installed base.

Then again, it is also very technically difficult to keep winning the backwards compatibility game. I'd say this is especially true for things like Javascript, where MS doesn't have complete platform control (they define Win32, where as Javascript grows more organically). Maybe their engineers finally gave up and decided to work on something new. Maybe IE7 and Vista are the results of this. But it'll be interesting to see what happens as these products arrive when there are already comparable market equivalents (Firefox and OS X). Breaking their support for legacy apps puts their competitors on a much more level playing field.

As much as I dislike IE7, Firefox go ing her ky jer ky on me eve ry hour I use it, re qui ring me to re sta rt it drives me even more nuts (and at least 4 of my colleagues have verified that I'm not the only one who hits this bug). So it's back to IE7, which may freeze horribly every so often, but I'l take short bursts of pain over continuous agony stretched out over many hours.

I finally got around to teaching myself a little Macromedia Flash. Here is my first result.

The more flash I learn, the more I find it is a superior platform for doing graphic design on the web. It has much more precise layout mechanism, and it appears to completely solve the font problem.

I haven't gotten into the scripting at all yet, but so far I like what I see.

I wrote a previous tip about how to use Monaco while running an xterm on OSX's X server. Here's a similar tip, except running on Linux this time.

I like Monaco for it's legibility at small screen sizes, so I wanted to use it in my gvim session.

The first step is to copy the font file over to your ~/.fonts directory. On a Mac system, you can find it under /System/Library/Fonts, called Monaco.dfont. The, run fc-cache to reload the fontconfig cache.

At this point, the font should already show up for any newly started GTK2/fontconfig-based program. You should also be able to say xterm -fa 'Monaco' to launch an xterm with the new font.

In gvim, you should also be able to select the font if you run the command :set guifont=* and select it from the menu.

Now here's the more complicated part. If you're fine with the antialiased version of the font, then stop here. If you want the pretty pixel-size based fonts, read on.

Modern linux systems, like Ubuntu, try to be really clever about your screen DPI. They know how big your monitor is, and what your resolution is set to, so they set calculate and store a DPI setting in the X server. The fontconfig and friends uses this information to map point sizes (what your apps ask for) to pixel sizes (what most hinted and bitmap fonts care about).

During this Process, if your DPI value is not one of the standard ones (i.e. 72), then trying to guess the point size that maps to a particular pixel size can be difficult. It could be 8.333333 or 8.3344 or some other very precise value (though fontconfig appears to be somewhat lenient)

Some programs let you control very precisely what parameters are asked of fontconfig. For example, for xterm, you can say xterm -fa 'Monaco:pixelsize=10' to get exactly the size that you want (change the value of pixelsize to see the different sizes). You can also say xterm -fa 'Monaco:pixelsize=10:antialias=off' to get exactly what I was looking for.

Ok, great, so how do we make gvim ask for this exact font. Well it turns out that gvim seems to hide the details of the font system from you, so only lets you specify things like :set guifont=Monaco\ 9 where the numeric value is the size of the font in point size. There's no way (as far as I could tell) to tell it to ask for a particular pixel size.

So what now? It's .fonts.conf to the rescue.

Here's the code I added:

  <match target="pattern">
    <test name="family">
      <string>Monaco10px</string>
    </test>
    <edit name="family">
      <string>Monaco</string>
    </edit>
    <edit name="antialias">
      <bool>false</bool>
    </edit>
    <edit name="pixelsize">
      <int>10</int>
    </edit>
  </match>

What does it mean? Well it looks for an application to request a font pattern with family 'Monaco10px' (which actually doesn't exist). When that pattern comes along, it secretly munges the pattern so that the "family" is now "Monaco", and it explicitly sets the pixelsize value to 10. So now an application just needs to ask for the "Monaco10px" font, and it will always get this exact font.

Back in gvim, now I can finish up by adding the line set guifont=Monaco10px to my .vimrc

And one final perfectionist touch. In the mac terminal, each line is spaced by one pixel. This is not done by default in gvim, but you can add this by adding set linespace=1. The end result is something that looks very close to what you get in a Mac Terminal.App.

One final caveat: Unfortunately, this trick only works when you can tell an application exactly what font family to request (usually by typing it in somehow). On apps that only give you access to the font picker dialog, Monaco10px will not show up as a candidiate, because it's not a real font.

Normally, I don't write stuff like this, but Qian asked me for a reference of basic shell commands and I got really depressed about what I found. This page (top 10 linux commands for newbies) has over 1000 diggs, and what's in it's top 10? vi ! are you kidding me? Yea, that's sure a sure fire way to send someone crying back to Windows or OSX.

Part of the reason why computers remain so inaccessible to the vast majority of people is that it is a extremely difficult task to write documentation from the perspective of a user who doesn't know anything about what you're trying to tell them. In another shocking example from the above linked page, the author throws out words like "wildcards" and "pipes" without giving any explanation what they mean.

Sure, people can figure things out by experimentation, but the author seems to forget that the vast majority of newbies are hesitant to issue commands they they don't understand, not just because they don't know what's going on, but out of fear that they'll somehow screw something up, because they don't know what's going on.

That's an entirely reasonable reaction. I mean, what if someone just told you to go change that thingamajiggy to a whatchamacallit in that power generator over there. Would you just go in and do it without having any idea what's going on. With no hesitation?

Anyhow, enough ranting. Here's my list of top (maybe 10) shell commands that "newbie" users should get used to.

But before I start, lets start with even more basic terminology. What is a "shell"? The term shell actually refers to something quite abstract, and most people don't even bother explaining that.

Computer scientists love metaphors. They use metaphors to describe all kinds of complex relationships of various pieces in a computer system. "Shell" is such a metaphor.

If you imagine your computer software a being composed of many layers, like an onion, the "shell" is what is on the outer most layer. It is the layer that you, as a user, interact with. So when you're typing in commands, you're typing them into a piece of software known as the "shell".

Ok, now that we have that out of the way, here we go:

1. pwd: Oh yea, computer scientists also love acronyms, and shortened forms of words and phrases. That's because they type all day, and shorter forms mean less typing.

   Anyhow, pwd is short for "print working directory". A "directory" just refers to a location on your computer. In Windows and Mac term's it's a folder. When the shell program is running, it's always running in a directory, and the directory it's running in is called the "working directory".

   On most Unix-based systems (where you're most likely to encounter a shell), a directory is identified by it's path. For example on my system, I may do something like this:

   % pwd
   /home/ken
   

   In this example /home/ken is what identifies my current working directory. The slashes in the path denote different levels of the hierarchy. Directories can contain other directories (just like folders contain folders)

2. cd: This command is again, shorthand for "change directory". It let's you change the shell's current working directory to something else. You use it by specifying the directory you want to change to after you type the command name. For example:

   % pwd
   /home/ken
   % cd /home
   % pwd
   /home  
   

   You can see in this example that I first print my working directory, then I use "cd" to move to the /home directory, and then I print it out again to show that it has changed.

   You can also use cd to move to a directory that's located relatively to your current working directory. Let's say my directory /home/ken contained a directory called "foo" ("foo" is the favorite example name used by computer scientists). I could do something like:

   % pwd
   /home/ken
   % cd foo
   % pwd
   /home/ken/foo
   

   You can see that in this case, I moved to the "foo" directory inside the /home/ken directory, but I didn't have to specify /home/ken/foo in it's entirety. In this case "foo" is called a "relative path", because it is interpreted relative to my current working directory.

   Now there is a special relative path .. that refers to the directory containing the current working directory. With this, you can move up the hierarchy without knowing the name of the directory above you.

   % pwd
   /home/ken
   % cd ..
   % pwd
   /home
   % cd ..
   % pwd
   /
   

   In this example, I move up one directory level at a time, using the special .. pattern. Incidentally, the path with just "/" is called the 'root directory', and it is the highest point of the hierarchy. Issuing a "cd .." at this point would result in nothing, since you can't go any higher.

3. ls: Ok, so this one isn't quite an acronym, but it's pretty close. "ls" stands for "list". Get it? No? Ok, whatever, doesn't matter.

   ls is used to view the contents of a directory. A directory, just like folders, can contain files, as well as other directories. Since your computer has many thousands of directories, it's not likely that you'll know how to get around without being able to inspect each directory. That's where ls comes in. It's usage is pretty simple. Just type 'ls' and return:

   % pwd
   /home/ken
   % ls
   foo
   myfile.txt
   

   That's it. You can now see that the /home/ken directory contains "foo" and "myfile.txt". Hurray!

Ok, that's all for now. Why you ask? well because this took longer that I thought, and also because these are the three basic commands that you can use to your hearts content without fear of screwing anything up. So try anything you want to and experiment. As long as you don't mis-type the command, it's impossible to do any damage.

There'll be more in following posts, but if you're really impatient, you can look at something like this reference, which is somewhat better than what I linked to at the top of this post, but still pretty terse.

As you can see, I've loaded a new stylesheet for this blog. Partially because I just wanted a change, but also partially because this page looks funny on a Mac.

Why, you ask? Well, for some reason Safari likes to do bad things to the text when it's rendering light text on dark backgrounds. This post actually claims that OSX applies a gamma correction to text before it renders it, which supposedly makes it good for black on white, but not the other way around. Don't know how true that is, but there is certainly a difference.

Also, it seems that it's much easier to spot bold text with dark text on a light background.

Why do I care how the page looks on a mac? I'm experimenting with using my mac mini at work as my primary work GUI. I've spent a lot of time over the past few days trying to tweak Ubuntu to look exactly how I want (and I've realized significant font rendering gains, more coming on that later) but, in the end, things still aren't quite right, and I don't want to spend any more time tweaking things. It just feels more and more pointless when you know that there are other platforms that just get it right from the start.

Anyways, it's not like I've moved completely to OSX (I tried that at work before, but gave up). I've just switched to it as my GUI machine, meaning that all my actual editing happens on a Linux machine through ssh, and I still use Outlook in a VMware Fusion virtual machine.