HP3000-L Archives

March 1999, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Wed, 24 Mar 1999 14:44:32 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (122 lines)
John Pickering writes:

> I grabbed a copy of QCterm yesterday for a new pc for which I haven't yet
>  purchased Reflection. Installed quickly and easily. Such a pleasure to
>  find install instructions which actually match the dialogue boxes and
>  prompts of the system :-) Am now debating the need for WRQ stuff!
>
>  Worked fine first time over public x.25 but doesn't display accented
>  french characters correctly. For example, a lower case a with an accent
>  grave is displayed as an upper case H. Is this your font set or x.25? Any
>  suggestions?

I looked at the character codes and, in this case, it's clear that your X.25
connection (or some cohort of the connection) is stripping off the uppermost
bit (the 8th bit). When you do that, a lower case "a" with a accent grave
becomes an "H", exactly as you say. In this instance, it's not QCTerm's fault.

However, I was willing to blame us for a mistranslation of the character. One
of the decisions we made early on was to not support diacriticals. In that, I
spoke to Rene Woc of Adager two years ago, when we first started this project.
Rene was raised in a culture that heavily uses diacritical markings, including
even his name. More than that, Rene thinks critically about key issues and no
one would better than he would understand the inevitable criticisms that would
arise from elminating diacriticals, a feature some people might consider well
critical for cultural reasons.

The problem is that under Windows 3.x, we only have 256 characters available
to us -- and we found that font switching to be very slow. For performance
reasons, it was much better to put the line drawing set into the QCTerm's
fonts than it was to support diacriticals, so that we wouldn't have to waste
time switching between distinct fonts. Thus that basically became the choice:
speed or diacritically marked characters. Rene agreed strongly enough that
speed overrode diacriticals that that's what we did. I told him at the time he
would have to accept a portion of the blame :-).

If your X.25 connection was not stripping the upper bit off, what you would
have seen on your screen in place of the lower case "a" with an accent grave
is just a lower case "a." We have an internal table that translates HP's Roman
8 extended alphabetic character set into plain ASCII, although we did program
up and support all of the additional symbolic characters of Roman 8.

You can see the fonts' character distributions for yourself using Windows'
Character Map function.



>  Thanks mightily for an impressive gift to the 3k community.

I believe it's going to get significantly better in the near-term future (this
year, in the Atmarian calendar). I was planning on keeping much of this a
secret until just before HP World, but what the heck. If you've already
downloaded a copy of QCTerm and installed the fonts, download this small
program too:

     http://www.aics-research.com/test.html

unzip it, and then run the resulting program, "c:\aics\demoscreen.exe", using
Windows Explorer.

What you're going to see is a mockup of the way that forms mode will look in a
future version of QCTerm. Everyone wants a bright, colorful, GUI-based
interface, and clearly people are going about this in a variety of ways, but a
simple terminal interface should never have been dismissed so readily. A
terminal-based connection has some extraordinary advantages: it's extremely
simple to program up on an HP3000, it's very fast and responsive, it's a
persistent ("stateful") connection (from anywhere in the world now, via
telnet), and the forms mode interaction with the HP3000 has a 25-year proven
track record of absolutely rock-solid reliability.

The problem has been that it just that it hasn't been very colorful.

What you're going to see in this mockup is what a future QCTerm screen might
look like, using a very simple form. The coming version of QCTerm will have a
three-plane screen: the background screen will be a bitmap that can be as
bright and colorful as you wish to make it (and you will have total control
over how you want it to appear); the second layer will be the terminal text
layer that you're used to (including, of course, standard forms mode); and the
third and top layer will be a mobile cursor/text entry box that will support
picklists, etc.

In the mockup, all of the variously colored boxes and logos are on the
background plane. The text you type in lies in the middle (terminal) plane,
and the current cursor box is clearly in the foreground plane.

If you download the mockup (and remember, it doesn't do anything; it was put
together only as an internal process so that everyone here could see where
we're going), size your screen to 600 x 800 to get the full psychological
effect. In the final result, everything will scale to your screen resolution,
but this version doesn't.

This mockup does require that you download and install QCTerm's fonts and
DLLs, so please be sure to do that first, even if you don't intend on using
QCTerm. The URL to do that is:

     http://aics-research.com/qcterm

It's important to remember when you look at this mockup that nothing's really
changed. QCTerm remains a full-function emulation of an HP700/92 terminal.
Because of that, it will be possible to dress up pre-existing forms such as
NMMGR for which you don't even have source code by prepending a forms file (a
flat ASCII) file to your existing jobs before the main program runs.

The intention behind all of this is to eliminate much of the complexity of
developing application interfaces for the HP3000 and make it simple enough and
pedestrian enough that it would make anyone named Gavin or Mike yawn in
boredom. What we want to do is allow a bright high school kid the capacity to
generate a very simple, very robust interface into an IMAGE database that he
can develop in his back bedroom, using very simple tools such as BASIC,
FORTRAN or COBOL, and yet have something that is "completely cool" as a
result. To use a terminal interface, all that you need to have is have the
capacity to DISPLAY/WRITE/PRINT to the screen and READ/INPUT/LINPUT from the
keyboard, the same basic capabilities we started with 30 years ago.

I'm scheduled to give a tutorial at HP World on these new graphical
characteristics of QCTerm. Unfortunately, Interex chooses to work on the
Gregorian calendar, so I'm hoping that I'll have something to say by then.

No matter when all of this gets done, full instructions on how to use these
features will be put on the web.

Wirt Atmar

ATOM RSS1 RSS2