9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jim Choate <ravage@ssz.com>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: Plan 9 (in)security
Date: Mon,  2 Jul 2001 08:20:57 -0500	[thread overview]
Message-ID: <Pine.LNX.3.96.1010702080737.24279i-100000@einstein.ssz.com> (raw)
In-Reply-To: <0a0a01c102ee$135823e0$41734e81@oemcomputer>


On Mon, 2 Jul 2001, rob pike wrote:

> Why stop at 64 bits per character? Why not go for 256, a 16x16
> dot matrix of the ISO image for the character.  Perhaps with a
> 16-byte header with special information such as case, dialect,
> diacritical marks, etc.

I'll assume you're being snide.

That's easy, it would be incompatible with systems that didn't use a 16x16
representation, say a vector processor. In other words it's restrictive
not enhancing.

What one wants is a mechanism to code the desired character to the
display, not restrict the individual system designer on how to impliment
that display. Which brings up the point that the mechanism needs to have a
inherent 'font change vector' attributed to the display as well. This
would allow you to not only mix language char's but also fonts (without
getting stuck in the mire of what fonts go on what system). It could be
two 'runes' long. The first is a warning rune that says "Hey, new font
coming up" and the second rune says "Look this far into the font table and
start using that font".

It's completely feasible that in the future some bright person might
create a display that takes images of individual characters at some high
resolution (say to imitate a true paper like look) and uses that. Clearly
an array coding the specific char/font would inherently be incompatible.
Whereas if it was only a vector into a table of some sort the only thing
that would have to change would be the actual display driver mechanism and
not the entire windowing system. Consider e-paper for example.

I'm using a 64-bit processor, a 64 bit rune representation (especially
when a 1GHz clock and half a Gig of RAM along with 120G of drive space
isn't exception - what I have hooked to my home stereo to play CD's,
DVD's, and video games) would not represent a significant system load.


 --
    ____________________________________________________________________

            Whereof one cannot speak, thereof one must be silent.

                                      Ludwig Wittgenstein

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------




  reply	other threads:[~2001-07-02 13:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-02  1:38 [9fans] " okamoto
2001-07-02  2:03 ` Jim Choate
2001-07-02 11:56   ` rob pike
2001-07-02 13:20     ` Jim Choate [this message]
2001-07-02 13:28 [9fans] " forsyth
2001-07-02 13:52 ` Jim Choate
2001-07-02 14:16   ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.1010702080737.24279i-100000@einstein.ssz.com \
    --to=ravage@ssz.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).