From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: BUSES and other things
Date: 26 Jul 92 20:31:46 GMT
Organization: Auspex Systems, Santa Clara

>>...because the hardware doesn't know beans about characters; the
>>software can turn pixels on and off as it chooses.  It's the *software*
>>that's responsible for having the characters available.
>
>At what speeds,

Fast enough for my purposes; dunno how fast you require them to be.  For
example, when I fired up the Andrew Toolkit "eq" editor, and asked it to
insert an integral sign, the sign popped up quite quickly.

It took some time to tell it to do so, as I just selected the "Insert
Symbol" item from the menu, and typed "int" to its prompt.  There may
well be faster ways of getting it to do so - but, even if there aren't,
that has nothing whatsoever to do with the desktop bus; it has to do
with the user interface design of the editor.

>and with how large a source file?

The only effect that the size of the source file has on how fast the
display can turn a "this is an integral sign" entry in the document into
an integral sign on the screen is that a larger source file *might*
increase the working set size of the editor, and thus *might* cause
pages containing e.g. code to paint the integral sign to be paged out. 
Both of those are "might"s; the editor might well keep only enough of
the file to paint the current screen in memory at any given time, for
example.

>>(And if you're going to argue that "bitmapped displays are the wrong
>>answer", you'll have to explain why your favorite solution is better;
>>I'm sure not going to simply take your word for it....)
>
>Now I am not quite sure how much is software and how much is hardware;
>I suspect that it varies considerably between machines.

I suspect that the most that modern machines have in the way of
"hardware assist" for that is hardware to copy bit-mapped images of
characters from one place in memory to another.  I believe some
hardware "PostScript accelerators" of some sort have been cooked up for
laser printers; they may show up as window system accelerators, and if
they transform scalable representations of characters into bitmaps, that
form of "hardware assist" may show up in future machines.

>But I would
>prefer a dumb terminal with a downloadable character set of size 2^10,
>and which is easily user-modifiable, to the clumsiness of something
>like TeX.

What if the only software you have that supports the creation of papers
with mathematical formulae in them, and that uses that dumb terminal,
*IS* TeX?

If it's truly a "dumb terminal", it will not, by itself, allow you to
edit documents; you'll need host software to do that.  And even if it
*does* have a 1024-character character set, that doesn't *necessarily*
mean that you'll get any software for it other than, say, a TeX
previewer.

A conceivable - although not necessarily likely - scenario is that you
get an editor that you find less clumsy than a plain-text editor + TeX
running on a machine with a bitmapped display, and naught but a TeX
previewer on your terminal....

I.e., you're confusing the issue of the capabilities of your display
hardware with the capabilities of the editing software.  To confuse them
in that fashion is unwise; it can lead to conclusions that may not be
valid, e.g. that a dumb terminal with a large downloadable character set
is more likely to give you a document preparation facility for
mathematical papers that you will find preferable to TeX than is a
system with a bitmapped display.

>And I want an easily readable source file, not like those
>clumsy messes on the Macs.

I rather doubt that the display hardware will have much, if any, effect
on the source file format.  If you wish to complain about the current
state of software for the preparation of mathematical papers, you will
probably find it much more productive to do so in, say, "comp.editors",
or one of the "comp.doc" groups, than here, unless you can demonstrate a
way in which computer system architecture is directly responsible for
that state.

(Or, to put it another way, the fact that the Mac has a bitmapped
display has, as yet, not been demonstrated to have had any effect
whatsoever on the format of the source file used by the
document-preparation software you've used, so if your reasoning is
"well, all these systems with bitmapped displays do not meet with my
approval, therefore bitmapped displays are bad", then, unless you have
some data you haven't shown us all yet, your reasoning is bogus....)
Newsgroups: comp.arch