You need to install the Universal Font Library (UFL). See http://www.engr.uvic.ca/~aschoorl/ufl/ to download the library and installation instructions.
Java is meant to be a general purpose stack, whereas EQStk
is designed for math users. As such it is generally not
appropriate to always display lists with AGROB
. You
can use the scroller to display lists and other objects
with AGROB
. The Frappuccino and Cappuccino flavours
of Java will display objects like EQStk does, and are intended
for math users.
Java runs 'AUTOEXEC' on warm starts only. If you want to
run something at every power on, it is trivial to assign
a small program to your OFF key that first runs OFF and then
the program you want to run. For example, if you want to
go to the VAR menu every power on, you could do
<< OFF 1 MENU >> 91.3 ASN
As mentioned earlier, Java is intended to be a general purpose stack. For most users, the status area is more useful than another two lines of stack display. Since the status area is not updated in the interactive stack, it is a full seven lines.
The reason Java does not show memory in the status area is because in order to provide an accurate reading for available memory, a garbage collection must be forced. This is inherently slow. Java is meant to improve stack performance, so we were unwilling to include a garbage collection every status update. The HPSauce library is still maintained separately for those who prefer it.
You are using an old version of Java on a Rom R machine. There are known problems with the old dynamic port lock/unlock routine (GetKeyOb). Either use the "light" version of Java 2.9a, or upgrade to the latest version of Java.
The problem with this has to do with how to redraw the stack
before and after invocation of the scroller. Do you get rid
of the status area, forcing a full stack redraw? Seems slow.
What about tiny objects that don't even reach the status area?
Do you provide two versions of the scroller for such cases?
Seems bloated. If you require a full screen scroller, you
can use AGROB
to convert an object to a grob, then use an
external scroller like VV
to view it.
The main reason for not adding more configuration options is
because of the STK
configuration program. The current
configuration flags occupy the entire screen - so to add more
we would either have to use multiple screens or make STK
scrollable. Both ways would make STK
much larger. So
unless there is significant reason to do so, we have been
reluctant to add additional configuration flags.
Java routines have been rewritten to use FNT1 for the menus, path display, and string to grob conversion. There are several advantages to this:
The slight disadvantage is that FNT1 may not seem as attractive, especially in the menus. Although FNT1 does take some getting used to, we believe the benefits outweigh the drawbacks. Providing sets of libraries in both FNT1 and the original smallfont was not feasible, especially considering the number of flavours already in existence.
However, the option for the original smallfont still exists in the source code, so if anyone wants to compile their own custom version, they can still do so.
Java 2.9a had a problem in that it made a copy of the Jazz tables if they were in a covered port even if you did not have the SysRPL mode flag set. This version no longer makes a copy if you do not set the SysRPL mode flag. However, it still has to make a copy if you use SysRPL mode because of the bank switching inherent with covered ports.
The PostScript provided with Java is formatted for letter size paper. SGML source for all the documentation is included with Java's source code, so if you download a copy of that you can use the sgml-tools package to make any format you like. An easier way is just to print the HTML version.