works (08/02/82)
>From PLEASANT@RUTGERS Sun Aug 1 16:50:43 1982
Works Digest Sunday, 1 August 1982 Volume 2 : Issue 68
Today's Topics:
Administrivia
More on Command Completion
Menu Systems
Display Resolution (6 msgs)
----------------------------------------------------------------------
Date: 1 Aug 1982 1918-EDT
From: Mel <Pleasant at RUTGERS>
Subject: Administrivia
Hi folks,
In the past few digests, there has been some discussion on
command completion. I have also gotten some submissions concerning
bandwidth, encoding, abbreviations and Command Language Design in
general. All of these areas are relevant to the world of work
stations, however our discussions have tended to be in the more
general realm of computers at large. Since the Human-Nets digest is
alive again, I'd like to suggest that we move the more general
discussions over to it and keep our discussions more closely related
to the work stations.
-Mel
------------------------------
Date: 28 July 1982 04:39-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: More on command completion
To: SEILER at MIT-XX
Especially since we're talking about workstations here, there's no
reason in the world for command completion to be slowed down by a
"heavy load". There's only one user on each workstation (or there's
enough cpu power on a shared system to support simultaneous command
completion by all users). In a distributed system where real jobs are
done by a shared mainframe but user interfacing is done by individual
workstation micro-computers, the command completion should be done in
the micro, not in the mainframe. If possible the user interface should
do as much for the user as the DFTP program did (Those who didn't use
the Datacomputer FTP program may ignore that.), and more. The protocol
for talking between workstation and mainframe should be terse and
logical, not English; it should use short numbers (8 bits for example)
instead of strings of text to identify commands and arguments. This
reduces the load on the mainframe cpu to the bare minimum. In essence
the mainframe should execute UUOs/JSYSs/SVCs instead of
monitor/EXEC/shell commands. The user interface should translate
between text-string commands and binary UUOs. I.e. the workstation
should include all the shell. The workstation should also provide all
the user customization.
With most cpu-intensive tasks done by the single-user workstation,
i.e. there's no mainframe used normally, user-services should be the
highest priority, so that any cpu-intensive task yields to command
completion and the load presents no problem.
<Above my opinion>
------------------------------
Date: 28 July 1982 10:00-EDT (Wednesday)
From: Sam Hsu <FHsu at BBNG>
To: Robert Elton Maas <REM at MIT-MC>
Subject: Menu systems
Since this was brought up as a suggestion, what sort of experience do
people have with menu systems? Were they effective? Are they really
easier to use? I've used a Wang system (for playing games, though) and
found the menu system somewhat restrictive, slow, and tedious after a
short time, although it was helpful at first. Suppose the menu system
kept track of command usage, and displayed only a subset of commands,
say, the useful ones but not yet used a lot (assuming the often used
ones were already mastered), or the appropriate ones in a certain
context.
comments?
------------------------------
Date: 30 Jul 1982 1418-EDT
From: Ron <FISCHER at RUTGERS>
Subject: Display resolution
Here are the responses I've gathered to my "lowest possible
resolution" query. Some of the stuff was pretty interesting.
[The first two messages have been duplicated from previous digests.
This was done so that the readers could read the entire discussion in
one sitting - Mel]
------------------------------
Date: 23 Jul 1982 0934-PDT
From: Jeff La Coss <JLACOSS at USC-ISIB>
Subject: Display resolution To: Fischer at RUTGERS
Ron,
Your question about display resolution is one that has been
investigated for quite a long time. Basically, there are two ways to
approach the problem.
One is to have a very high resolution display. The Bitgraph
and the D0 have about 80 dots/inch resolution. The displays look ok,
right? Well, how would you feel about a book printed with EXACTLY
those fonts. Pretty crummy now, isn't it?
If you have access to a PERQ or a SYMBOLICS LISP machine, take
a look. The displays on those machines is about 100 dots/inch. Still
better, but not perfect.
The best resolution on a raster display machine that I've seen
(but not directly) is on our Xerox penguin, which has about 300
dots/inch resolution. Looks pretty good, but it has been determined by
a bit of quickie measurement that the minimum resolution required for
"book quality" output of whatever medium is about 400 dots/inch.
The trouble with all of this is that the video bandwidth
required to do any of this is cosmic. No problem generating it (well,
maybe no problem) but displaying it is quite another matter. Building
a monitor that can swing the beam fast enough to do 1000 lines/frame
is a trick only a few vendors have managed. 300 lines/inch resolution
will require 3000 lines/frame. Ouch. In addition, the beam is going to
have to be modulated at about 250 MHz. The only way to do this will be
to up voltages/currents in the amp circuit and increase the anode
voltage- don't sit in front of this tube if you ever want to
procreate.
The other method is to do gray-scaling of the video. This
allows good apparent resolution without hairy requirements for actual
output resolution. The final product of a 512x512 display doesn't look
as good as a high-res single-layer bitmap due to the inherent
defocusing of the character edges, but it still compares favorably to
a D0 or Bitgraph.
Gray scaling does have some drawbacks- you've got to have n
bits of gray value for every displayed bit and you have to do =>
considerable <= munching to get your gray values right. "Right" is
something that is probably determined empirically. You also need a
good high-speed (relatively) D-A converter and a linear video amp in
you monitor unit to minimize tweaking of your fonts.
Further curiosity can be sated by a scanning of INTERACTIVE
RASTER GRAPHICS by Newman and Sproull- it is still the definitive text
on the subject.
Jeff
------------------------------
Date: 27 Jul 1982 12:51:15 EDT (Tuesday)
From: Carl D. Howe <cdh at BBN-UNIX>
Subject: Display resolution
In reply to Jeff La Coss' message concerning the resolutions
of various displays, I would like to clarify a misunderstanding that
he had. He claims that a BBN BitGraph is comparable to a D0 with a
display resolution of about 80 dots/inch. In fact, the BitGraph
resolution is almost identical to that of the PERQ and the Symbolics
machine at around 100 points/inch. The BitGraph I am typing this on
has a usable display area of 7.75"x10.75" and is 768 points x 1024
points, yielding a resolution of 99 points/inch horizontally and 95
points/inch vertically.
Carl Howe
------------------------------
Date: 28 July 1982 12:47-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
I am building text editor/formatters for personal workstations and
have also run into the problem you have mentioned.
A 1024 line 15" monitor will give you a resolution of about 100/in.
This is about right for text processing applications, though it will
be nice if someday we go to higher resolutions. At this resolutions,
most characters (even tiny ones as in super and subscripts) are
identifiable by their type face. However, strainless reading of such
text is another matter. On hardcopy, 10 point size text is easily
readable. This is not so, even on a 100/in monitor because of glare,
flicker, scintillation, discreteness of dots, light-emitting property
of CRT's and a host of other problems. My approach has been to
provide for a slightly larger than real life page size and character
size. I think most people do prefer larger characters on CRTs.
With 17" monitors your resolution is lowered to 75/in. It is still
possible to show full page text, though type face will have to be
sacrificed. Again, my approach here will be to blow up the document
even more than a 15" monitor (hence less info on page, but who cares
since there is larger screen area and a proper editor MUST have
windowing capability.
I would appreciate to share in other responses.
Bern
------------------------------
Date: 28 July 1982 12:49-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
I have not answered you question directly. I believe that 72/in
resolution is lowest minimum acceptable (Hence an 800 horizontal lines
display is the minimum). Anything less than this is really not worth
the effort.
Bern
------------------------------
Date: 30 July 1982 12:41-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Re: Lowest possible resolution full page displays
To: FISCHER at RUTGERS
Date: 29 Jul 1982 0026-EDT
From: Ron <FISCHER at RUTGERS>
In-Reply-To: Your message of 28-Jul-82 1247-EDT
Ben,
Thanks for the reply. Sounds like a reasonable approach. I
will summarize all the replies I get to the original question and
notify the WorkS digest. Yours is the second reply. The first one
mentioned "book quality" resolution (about 300dpi) and why that is
difficult to achieve in a CRT display.
Once again, thanks very much.
(ron)
-------
I think I made a mistake in my calculations of screen resolutions.
The 19" monitor with 800 x 1024 should have a resolution of 77/in.
The 17" monitor with 800 x 1024 should have a resolution of 89/in.
The conclusions still hold though. 75/in is the absolute minimum
required for medium-quality output of typographic information. For
high-quality output, you will need either 2 bit/pixel at 75/in, or
about 140/in resolution. For book quality, I would think 200/in at
2 bit/pixel would be minimally sufficient.
------------------------------
End of WorkS Digest
*******************
-------