UKTeX V87 #6
Blunders
IdxTeX and GloTeX
Rank Xerox Drivers
DVI family Update #12
Missing files in DVITOVDU
CMR fonts on IBM PC (from UNITeX)
VAX/VMS and IBM PC differences
---------------------------------
From the Editor
Sorry for the delay but term approaches with its attendant problems. I have
received notice that DVI family 2.10 will be despatched to me in the near
future. I have a copy of CTeX 2.1 to load plus other files. I am still
unable to set up TAR and SHAR files to reduce the labour of extracting
information but have obtained the code for the Rochester mail type service.
From the mail I see that TeXhax V87 #75 to #78 have gone missing. I have
obtained copies and they are available in the archive. I suspect that other
mail is also going astray as I have not received other items the first time
round and only when the sequence numbers betray the fact can I then request
copies. What is more disturbing is that no error messages appear to be sent
to the originator.
Peter
---------------------------------
Date: 22 Sep 87 19:52:06 bst
From: G.Toal @ uk.ac.edinburgh
Subject: Blunders!
To: info-tex@uk.ac.aston.mail
Message-ID: <22 Sep 87 19:52:06 bst 050138@EMAS-A>
Some of our more awake readers may have noticed that the last UKTeX
mailing had a couple of old letters appearing again... They got in
there by accident as a result of a programming error while setting up
a UKTeX bulletin-board at Edinburgh. Apologies to anyone who found it
confusing.
Apropos bundled/individual mailshots (an earlier topic of discussion,
but all the old mail is new to us up here!) - the system we have
installed is the best of both worlds: we accept Aston's bundled
text file and split it up into the original mail messages, which
are then posted to the bulletin board. This lets people use MAIL
to REPLY to letters individually, and makes it easier to scan through
the headers for interesting topics.
Our system also sets up the 'Reply-To:' address such that both the
original sender, AND info-tex@aston get a copy of the reply. I think
this solution solves all the problems raised by earlier correspondents.
Graham.
---------------------------------
Date: 23-SEP-1987 10:24:49 GMT
From: AFC@UK.AC.KCL.PH.IPG
To: INFO-TEX@UK.AC.ASTON.MAIL
Subject: IdxTeX and GloTeX
Does anyone have IdxTeX and GloTeX, as described in the most recent TUGboat and
DECUS News #59 (program VAX--261)? (IdxTeX is a LaTeX index preparation tool;
GloTeX is a sort of BibTeX for glossaries.) I'd like to cut out the 6-to-8 week
wait I always seem to suffer when ordering things through DECUS.
Thanks.
------------------------------------------------------------------------
Adrian F. Clark (``Alien'')
British Aerospace, Manor Road, Hatfield, Herts, AL10 9LL, U.K.
Tel: Hatfield (070-72) 62300 x8216
JANET: UK.AC.KCL.PH.IPG::ALIEN (c/o Kings College London)
------------------------------------------------------------------------
---------------------------------
Date: 28-SEP-1987 09:13:34 GMT
From: RHEAD@UK.AC.NOTT.VAXA
To: INFO-TEX@UK.AC.ASTON.MAIL
Further to my entry in issue 3 and Edmund Sutcliffe's in issue 4, anyone
interested in getting TeX output on Xerox 4045, 2700 or 3700 may be interested
in the following:
DECUS tapes 86.
Nigel Arnott of King's College Physics Dept kindly looked through
his top-level *README*.* files from the 1986 DECUS tapes. A VMS SEARCH for
Xerox didn't reveal any occurence of Xerox except when associated with 8700
or 9700 in a non-TeX context.
DECUS tapes 87.
We have received a "DECUS program library status report, July 20 1987",
which I think represents advanced notification of the contents of the DECUS
1987 tapes. I can't see any reference to Xerox, but plan to SEARCH the
*README*.* files when we get the tapes.
Xerox US.
Following an entry by John Gourlay in TeXhax, I wrote to Margot Nelligan
(somewhere in California) for details of the software that she distributes.
(John Gourlay has since given more details in his article in the most
recent TUGboat.) There was no response from this until last Friday,
when I happened to be away in London. One of my colleagues received a
phone call from Heathrow, saying that there was a freight packet for me,
that it would cost 50 to 60 pounds for an "agent" to shepherd it through
customs, and that they had to decide that day. My colleagues didn't think
that they could accept being put in this position, so refused the package.
So I suggest that any Xerox owners encouraged by John Gourlay's article
should tread carefully. I plan to suggest that Margot Nelligan tries again
either by post or via Xerox UK.
David Rhead
---------------------------------
DVI Driver Family Update #12
[28-Sep-87]
This issue announces Version 2.09, some minor editorial changes,
and fixes to three serious bugs, one of which affects only
dvijep, another only dvialw, and the third, most of the
dot-matrix printer drivers. The fixes are extracted from the
00REVHST.TXT file, and I record below everything posted to it
since Version 2.08 (20-Aug-87)
I am pleased to announce that the Free Software Foundation GNU
Project C compiler, gcc, now successfully compiles the entire DVI
driver family, both with and without optimization, on the Sun
workstation. gcc can be built to produce code for Motorola
68000, 68010, and 68020 CPU's, and for the DEC VAX architecture.
I have installed version 1.11 here, and applied two bug fixes
supplied by Richard Stallman to correct problems in gcc that
showed up during the installation and testing of gcc on the DVI
driver family. This testing also revealed a bug in the driver
family itself; the fix is documented below.
gcc currently runs with the host (Sun or VAX) C library, and
consequently produces code which is calling-sequence compatible
with the native Unix cc compilers. Presumably a later release of
gcc will include complete run-time libraries, since the goal of
the GNU project is to produce a complete free-standing operating
system that runs on multiple architectures, and is freely
available in source form.
gcc's command-line switches are a superset of cc's. An important
virtue is that specification of the debug switch (-g) does not
nullify the optimization switch (-O), which is one of the great
flaws with the Sun compilers. Optimization is likely to exhibit
compiler bugs, and it is convenient to be able to track these
down with a source-level debugger that can still find variables
and line numbers, instead of an assembly-level debugger that only
knows about machine addresses. gcc also is current with the
October 1986 draft of the ANSI C standard, including string
concatenation ("foo" "bar" becomes "foobar"), preprocessor token
squashing ('#define X(n) X##n' results in X(abc) expanding to
Xabc), and function prototype declarations.
SRI has just released Version 4 of the TOPS-20 KCC compiler.
Like gcc, this too conforms to the draft ANSI standard, and to
the second edition of S. Harbison and G. Steele, ``C -- A
Reference Manual'', Prentice-Hall (1987). This version also
finally implements ioctl.h and signal.h, and fills in
miscellaneous other routines from the 4.2BSD Unix library that
were missing in earlier KCC releases
The value of early availability of ANSI conformant compilers is
significant, in that it permits more extensive testing of
software portability, and also exposes the code to the more
rigorous cross-checking available via function argument prototype
declarations, a new feature introduced by the ANSI C committee.
Function prototypes were actually borrowed from B. Stroustrup's
C++ language, which is currently implemented as a preprocessor
whose output is fed to the C compiler.
C's readiness to automatically coerce values in expressions,
assignments, and function calls is sometimes convenient, but more
often introduces subtle machine dependencies. The approach I
have rigorously adhered to in the DVI family is to use typecasts
to specify explicit coercion, but such rigor requires automated
tools which can check for compliance.
ANSI extensions to VAX VMS C have been reported by at least one
site; we do not yet have the upgrade locally. Microsoft C
Version 5.0 is due out in October 1987, and should be similarly
enhanced (it already had function prototypes declarations in
Version 4.0).
Here now are the recent change log entries:
[28-Sep-87] Updated all makefiles to include a generic target
dvi$(PGM) and an extra compilation flag value
XCFLAGS, so test versions can be constructed by a
command like "make PGM=foo XCFLAGS=-g dvifoo".
[28-Sep-87] {Thanks to Ian Young (ian@latlog.uucp)}
At the end of readgf.h, newfont() is called
before the loop which retrieves character metrics
via chargf(). This is incorrect for HPJETPLUS,
where the newfont() code in dvijep.c uses some of
the metrics. For the other devices, newfont()
only sets values in the font character tables.
Therefore, move the newfont() call to AFTER the
loop, so that the code reads in readgf.H:
for (the_char = FIRSTPXLCHAR; the_char <= LASTPXLCHAR; the_char++)
{ /* Get remaining character metrics, and ignore error returns for now. */
tcharptr = &(fontptr->ch[the_char]);
if (tcharptr->fontrp >= 0L)
(void)chargf(the_char,(void(*)())NULL);
}
#if (BBNBITGRAPH | HPJETPLUS | POSTSCRIPT | IMPRESS | CANON_A2)
(void)newfont();
#endif
[28-Sep-87] On Unix systems, getlogin() returns (char*)NULL
if the process is not attached to a terminal, in
particular, if the process is attached to a
pseudo-terminal (pty), such as a window or an
editor shell buffer. The way to get the real
login name in these circumstances is to use
cuserid((char*)NULL) in place of getlogin(), and
I have according made that change in dvialw.c and
lptops.c, and added appropriate function
declarations in gblprocs.h.
This change affects only text output in a
PostScript comment. Both cuserid and getlogin
are defined in 4.2BSD Unix, AT&T SYS V Unix,
HPUX, KCC (version 4), and IEEE Posix (which
draft ANSI C follows). PCC and V7 Unix had only
getlogin. VAX VMS C has only cuserid. KCC
(version 3), Microsoft C, Lattice C, and Wizard C
have neither.
[23-Sep-87] {Version 2.09 announcement}
Testing of the Free Software Foundation gcc
compiler has uncovered two bugs so far in the
compiler (they are being fixed rapidly). gcc
produces code for both VAX and Motorola
architectures, and is being used to develop the
GNU operating system. The testing also found a
serious bug in my code which unfortunately
impacts most of the DVI drivers, and can be the
cause of core dumps or other failures.
The value of XSIZE in dvi*.c is currently
computed as XDPI*XPSIZE, that is, the number of
dots across the page. Unfortunately, one or more
local arrays are later allocated and used with
the assumption that XSIZE is a multiple of the
machine word size, HOST_WORD_SIZE, and in dvijet,
it was assumed to be a multiple of
2*HOST_WORD_SIZE.
This bug was never caught on the DEC-20, because
there stacks grow upward, so beyond-bounds
references to stack arrays may just be writing
into unused memory. However, on the VAX, Intel
iAPX, and Motorola architectures, stacks grow
downward, and such references can wipe out the
call history, precipitating at best an address
exception or illegal instruction violation when
the return instruction is executed. This would
only happen if text was set against the
right-hand side of the page, and since TeX
documents usually produce wide margins, this may
be unlikely to happen.
To avoid complex dimension computations, and
preserve uniformity of definition among the
family, XSIZE is now increased to a multiple of
2*HOST_WORD_SIZE throughout. The fix is to
change
#define XSIZE (XDPI*XPSIZE) /* number of horizontal dots */
to
#define XSIZE (((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\
(2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))
/* number of horizontal dots; */
/* MUST BE multiple of */
/* 2*HOST_WORD_SIZE */
in all the dvi*.c files. I view this bug fix to
be important enough to warrant a version number
change, so the family is now at version 2.09.
The following Unix script can be used on Unix
systems to automate the patch:
#!/bin/csh
foreach f (dvi*.c)
echo $f
mv $f $f-old
sed -f bugfix.sed <$f-old >$f
end
Here is bugfix.sed:
s|"2.08|"2.09|
s|(XDPI\*XPSIZE)[ ]*/\* number of horizontal dots \*/|(((XDPI*XPSIZE+2*HOST_WORD_SIZE-1)/\\\
(2*HOST_WORD_SIZE))*(2*HOST_WORD_SIZE))\
/* number of horizontal dots; */\
/* MUST BE multiple of */\
/* 2*HOST_WORD_SIZE */|
[23-Sep-87] In openfont.h, nopen is incremented when the
requested font is not found in the list of
currently open files, but the code forgets to
decrement it if the request font never gets
successfully opened, when can happen if the font
file cannot be found, and no substitution font is
provided. Change the code about line 185 to
decrement nopen on open failure, so that it now
reads:
if (fontfp == (FILE*)NULL)
{
--nopen; /* don't count this failed open */
(void)sprintf(message,"Font file [%s [mag %d]] could not be \
[18-Sep-87] {Thanks to Mic Kaczmarczik (CC.KCACMARCZIK@A20.CC.UTEXAS.EDU)}
When dvialw.ps is modified to select LANDSCAPE
mode instead of NOTE (portrait), the output is
positioned incorrectly, and character bitmaps
look somewhat raggged. The former is due to a
missing translation command, and the latter to
tiny non-zero transformation matrix elements
which introduce computed coordinates which are in
error by one pixel. I have also taken the
liberty of installing a fix for the fact that
NOTE is not defined on non-Apple PostScript
printers. It should no longer be necessary to
edit dvialw.ps for Texas Instruments, QMS, et al
PostScript printers.
There is one problem with this change, and that
is that the SNAP call in the CharBuilder routine
must now be executed for each character set on
the page, so the output may prove to be somewhat
slower. To check this, I downloaded dvialw.ps to
our new Apple LaserWriter Plus, then executed
TeXdict begin
usertime 10000 {0 0 SNAP pop pop} repeat usertime
exch sub pstack
which results in a time of 70844 msec for 10000
calls, or an extra overhead of 7 msec per
character. Repeating the experiment using an
empty procedure body gives a loop overhead time
of 0.2 msec. With an average of 3000 characters
set per page, this amounts to 21 sec per page,
which is definitely not negligible. You may
therefore wish to leave the SNAP call out of a
version of dvialw.ps that is used only for
portrait orientation output.
Similar timing loops can be used to reveal an
average execution time of 1 msec for any
arithmetic operation (+-/*); PostScript
interpreters badly need hardware floating-point
support! There is a repeatable difference of
about 10% increase in speed when operands are
floating-point instead of integer values. dvialw
could be changed to write floating-point values
instead of integer ones, with a tradeoff of
slightly increased output file size to be
balanced against slightly faster arithmetic.
At the same time, I increased XPSIZE to 14 in
dvialw.c so that landscape mode output is not
clipped. Future work should introduce a general
flexible solution to the problem of paper size
specification for all of the drivers.
Here is a context difference which records the
changes. Additions are flagged with a "+" in the
first column, and changes with a "!", with the
old code first, and the new second.
*** dvialw.ps-old Wed Jul 29 14:35:41 1987
--- dvialw.ps Fri Sep 18 17:48:10 1987
***************
*** 1,3 ****
--- 1,10 ----
+ % <BEEBE.TEX.DVI>DVIALW.PS.17, 18-Sep-87 17:48:04, Edit by BEEBE
+ % Add test for note paper and if unknown, use letter paper instead.
+ % Non-Apple PostScript implementations do not know about note paper
+ % but its use on the Apple LaserWriter gains 92K of virtual memory
+ % <BEEBE.TEX.DVI>DVIALW.PS.16, 18-Sep-87 15:50:52, Edit by BEEBE
+ % Modify coordinate computations to remove round-off errors
+ % in landscape mode, and correct landscape page origin
% <BEEBE.TEX.DVI>DVIALW.PS.14, 22-Jun-87 09:55:05, Edit by BEEBE
% Add missing "0 900 translate Mtrx currentmatrix pop" to /LEGAL
% <BEEBE.TEX.DVI>DVIALW.PS.13, 7-Jan-87 17:38:51, Edit by BEEBE
***************
*** 110,116 ****
/BOJ
{
72 Resolution div 72 Resolution div scale
! NOTE % default page format
} bdf
% BOP -- beginning of page
--- 117,126 ----
/BOJ
{
72 Resolution div 72 Resolution div scale
! userdict /note known
! {NOTE} % default page format for ALW
! {LETTER} % default page format for others
! ifelse
} bdf
% BOP -- beginning of page
***************
*** 146,151 ****
--- 156,162 ----
ch-xoff neg ch-yoff ch-height sub
ch-width ch-xoff sub ch-yoff
setcachedevice
+ 0 0 SNAP translate
ch-width ch-height true [ 1 0 0 -1 ch-xoff ch-yoff ]
{ch-image} imagemask
} if
***************
*** 185,190 ****
--- 196,202 ----
72 Resolution div dup scale
0 3300 translate
-90 rotate
+ 0 -750 translate
Mtrx currentmatrix pop
} bdf
***************
*** 271,276 ****
--- 283,292 ----
% SF -- set new font at scale nnn (nnn = 1 normally; 2 gives double size chars)
% Usage -- nnn /fontname SF
/SF {findfont exch scalefont setfont} bdf() pop
+
+ % SNAP -- convert coordinates to integer device coordinates and back again
+ % Usage -- xxx yyy SNAP (leave xxx' yyy' on stack)
+ /SNAP {transform 2 {floor 0.5 add exch} repeat itransform} bdf
% T -- move absolute horizontally and show string, updating horizontal position
% to new endpt
[08-Sep-87]
In lptops.c, change
OUTSTR(getlogin());
to
if (getlogin() != (char*)NULL)
OUTSTR(getlogin());
because getlogin() can sometimes return a null
pointer, instead of a null string.
[31-Aug-87] {Thanks to HUXTABLE@UKANVAX.BITNET}
In gblprocs.h in the ANSI type declarations for
dvifile and main, change "char *[0]" to "char
*[]". The "[0]" is an odd production of
Microsoft C which was used to prepare the type
declarations at compile time. It sneaked through
the editing (it is not needed for Microsoft C to
compile these). VAX VMS C version 2.3-024 now
supports ANSI function declaration prototypes; I
don't have it up yet.
-------
---------------------------------
Date: 2-OCT-1987 10:58:55 GMT
From: QPFA1@UK.AC.SUSSEX.VAX2
To: abbottp@UK.AC.ASTON.MAIL
Thanks for making the DVITOVDU and PSPRINT software available over JANET -
its a great service to mankind! However, various bits of it seem to be
missing, unless, as is quite possible, I'm being very silly. For example
in DVITOVDU all the .MOD files, except for DVITOVDU.MOD, are missing. At
least, there not on 000FETCH.LIST. Sorry to be a nuisance, but I need the
full sources so I can change things around a bit.
Graham King,
Chief Programmer,
Brighton Polytechnic
+++Editor I am making enquires for the missing items+++
---------------------------------
Date: 2-Oct-1987 12:46 BST
Subject: CMR fonts on the IBM PC
From: Peter Abbott <ABBOTTP@uk.ac.aston>
Dept: Computing Service
Tel No: 021 359 5492 -direct
TO: Peter Abbott ( ABBOTTP )
To cater for those users who edit UKTeX for Bulletin Board systems etc I am
constrained to send myself a message to ensure the correct header is
attached.
I have recently received the CMR fonts from UNITeX in Sheffield for the IBM
PC and have now completed the process of installing them.
The instructions provided are clear and unambiguous and the software is
loaded into different directories from previous versions to ease the
changeover.
I had one problem with a faulty diskette but since I also received the
PREVIEW update at the same time I did not have to wait for a replacement.
I am using the CMR fonts and have also built HELPLAIN (LaTeX's LPLAIN but
calling Helvetica in place of CMR, which is the house preferred font). The
facilities of PREVIEW have been considerably enhanced and it is much more
useful than previously.
I am very pleased and can recommend the latest offering of DVIPS and
PREVIEW from UNITeX.
Peter
---------------------------------
Date: 2-Oct-1987 12:54 BST
Subject: Discrepancies in DVIPS
From: Peter Abbott <ABBOTTP@uk.ac.aston>
Dept: Computing Service
Tel No: 021 359 5492 -direct
TO: Peter Abbott ( ABBOTTP )
Running DVIPS on a VAX/VMS system (from Arbortex) the paper required is
quoted as
width 7.34
height 10.91
Running DVIPS on the IBM PC (again Arbortex via UNITex) gives
width 7.24
height 11.16
I have checked the dvips.opt files and the settings are identical. We wish
to develop documentation using both the VAX and PC's but the discrepancies
give rise to page layout problems.
Can anyone suggest a cure or identify the cause of the problem.
Peter
---------------------------------
!!
!! Replies/submissions to info-tex@uk.ac.aston.mail please
!! distribution changes to info-tex-request@uk.ac.aston.mail please
!!
!! end of issue