From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v612)
In-Reply-To: <20040224150553.1dbff498.martin@parvat.com>
References: <20040224101119.0136e11b.martin@parvat.com> <61c1795ccdc6a56ed9d2287088ba4980@plan9.ucalgary.ca> <20040224150553.1dbff498.martin@parvat.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <21148210-66E3-11D8-A0FF-000A95B984D8@mightycheese.com>
Content-Transfer-Encoding: 7bit
From: Rob Pike <rob@mightycheese.com>
Subject: Re: [9fans] Re: Thai Chicken
To: 9fans@cse.psu.edu
Date: Tue, 24 Feb 2004 08:04:30 -0800
Topicbox-Message-UUID: f3bab1e8-eacc-11e9-9e20-41e7f4b1d025

> Surely it would be better if every font contained a full Unicode set
> (without
> any bloat/duplication)?

without any bloat?  no chance.  unicode has gotten bloated lately.
linear B, anyone?

there are several reasons why the fonts aren't all full:

1) unicode keeps growing, so they can only be full temporarily.
2) it's easy to forget, but there were no unicode fonts when plan 9
adopted
    unicode.  bigelow and holmes made lucida sans unicode for us, and
that
    was the first - still partial, even today - unicode font.  in other
words, font
    coverage is spotty.
3) for many applications, you don't want the full set of fonts and
there is no
    need to pay the full memory footprint for them.
4) on slow lines, it can be very painful to cat a file by mistake that
has a lot
    of unusual characters, such as a binary file or a japanese file when
working
    in ascii.  try a drawterm across the country and run unicode
8000-B000 or
    something like that.

number 4 may be mitigated by improving networks, but in the early days
of plan 9 only the diehards ran with a relatively full font set.

-rob