UKTeX V88 #2

			     Pictures in LaTeX
			archived TeXhax submissions
			     IdxTeX and GloTeX
			 Public Domain TeX for PCs
			 Line numbering for prose.
			  Information on Drivers
				  TeX/PC
			       Gaelic fonts
		    Comments on Nelson Beebe's Drivers
			      IPA Fonts etc.

---------------------------------
Editor Peter Abbott

My apologies for the delay in this issue. We have been having `hacking' 
problems and are increasing security. As a result the files from Laurie 
Benfield for an IBM PC previewer are still locked in the directory he was 
given. As yet I do not have access to that directory to move them into the 
archive.

Also some sites are now experiencing problems in accessing the archive, 
these are being investigated and the users will be notified as soon as 
possible.

I have been asked what is the best place to get a tape from for the UNIX 
version of TeX (in the States). I have suggested Washington as being the 
distribution site. Can someone please confirm or suggest a suitable 
alternative (with address) please.

I have a tape with amsfonts, tib etc still to be loaded into the archive.

---------------------------------

Date: Fri, 15 Jan 88 13:13:28 GMT
From: CMI011@UK.AC.SOUTHAMPTON.IBM
To: info-tex@UK.AC.ASTON.MAIL
Message-ID: <15 Jan 88 13:13:51 GMT #3707@UK.AC.SOTON.IBM>

I recently asked on TeXhax for thoughts about picture drawing in LaTeX;
this note from Micah Beck is sufficiently interesting that I though
I would rebroadcast it here:

sebastian rahtz
--------------------------------------------------------------
Subject:    Pictures in LaTeX

I have recently given some thought to Pictures in LaTeX.  Here are some notes:

1) LaTeX pictures & PicTeX

        are both picture drawing environments which use no facilities outside
of TeX.  LaTeX pictures are drawn with special fonts, but these fonts are
part of the stardard LaTeX distribution.  PicTeX draws all figures by
\put-tin the period character (.) repeatedly, and so needs no extra fonts.

The big benefit of these environments is that they do not require extra
programs and fonts, and so documents written using them are portable
across computer systems running TeX and across printers.  They are also very
easy to install, since they consist only of macros and fonts.

The LaTeX picture environment is limited in the set of objects it can draw
with its special fonts.  PicTeX is more general, but is slow and requires
a version of TeX with a huge internal memory (Common TeX is often used, since
standard TeX has inherent limitations on memory size).

PicTeX has special facilities for drawing graphs with labeled axes etc.

2) TeXtyl

        is another environment for describing pictures, but it uses a
special postprocessor which produces DVI code directly.  A \special is
inserted into the DVI file prodcued by TeX, which indicates to the TeXtyl
postprocessor where to place the code for the figure.  The output of the
postprocessor is a DVI file which can be sent to any printer which supports
the special TeXtyl fonts.

Unfortunately, the TeXtyle fonts are not a standard part of LaTeX.
Indeed, the only MF source for these fonts seems to be for the old MF.
The fonts are distributed in pk form for a 300 BPI printer, but not everyone
can use this format.  For instance, we at Cornell can't.

Since TeXtyle is postprocessor, installing and using it is not as simple as
PicTeX.  Sending documents away from your installation becomes a problem.
However, if it weren't for the problem of not being able to use its fonts
easily, I would consider this a good engineering solution, because the work
of generating the DVI code is done by a program (as opposed to making TeX
macros do everything), yet the result is not printer-specific.

3) tpic

        is a reimplementation of the PIC graphics preprocessor used by troff.
The TeX it produces consist of \special-s which are recognized by some
DVI drivers and previewers. However, many installations cannot handle the
output of tpic.  For instance, we at Cornell can't.

4) epic - I'm not familiar with it.

5) Postscript

        Including PS files produced by graphics editor or other preprocessor
obviously works only in a PostScript environment.  However, like TeXtyl
it has the benefit of offloading the graphics work away from TeX, and by
using built-in PS features it can probably get better peformance than
results from encoding the graphics in a DVI file.  If one really believed in
PS as a standard, this would be a good solution.  However, the reality is that
many installations cannot print PS.

-----

So, what's a mother to do?  I've been recently working with a graphics editor
called Fig, which runs under Suntools.  It produces intermediate code which
can be translated into PS.  I have written a converter to translate the output
of Fig into PicTeX.  If you were to use Fig at your installation, you could
translate into PS for use locally, but translate into PicTeX for distribution.
PicTeX is also good for producing graphs directly.

PicTeX is, for now, the most portable and general solution.  The macros are
available for free on the network.  Using an intermediate form which can
be translated into PS as well (or perhaps using a PicTeX-to-PS translator)
allows PS to be used when it is available.

My philosophy: the only standard in TeX right now is DVI, so use it when
possible.  The emerging standard in graphics is PS, so use it when DVI won't
do.  Eventually, PS will become a true standard, and DVI drivers will have to
understand it.  Eventually.

Well, I hope this info is useful.  If you care to repost any of it to the net
in combination with other info you recieve, feel free.

Micah Beck
Dept of CS
Cornell Univ.

beck@svax.cs.cornell.edu
---------------------------------

From:    Dave Love <FX@UK.AC.DARESBURY.NNGA>
To:      info-TeX@aston
Date:    Fri, 15 Jan 88 16:33 GMT
Subject: archived TeXhax submissions
Message-Id: <15 JAN 1988 16:33:54 FX@UK.AC.DARESBURY.NNGA>

TeXhax  contains frequent long submissions which are advertised as being
archived at SCORE and sent to TEX-L.  How should one get hold  of  these
in  the UK?  TEX-L appears not to have much on it other than back issues
of TeXhax and I had no response to a query to the man  in  charge.   The
[public.score]  directory  at  Aston  also  doesn't contain this sort of
thing, apparently.
 
  David Love,   SERC Daresbury Lab.

---------------------------------

Date:		15-JAN-1988 18:24:20 GMT
From:		AFC@UK.AC.KCL.PH.IPG
To:		TEX-INFO-REQUEST@UK.AC.ASTON.MAIL
Subject:	IdxTeX and GloTeX


I have acquired IdxTeX and GloTeX, which can be used with LaTeX for
producing indices and glossaries respectively. Since the stuff is
public domain (I got it from DECUS), perhaps you'd like to include it
in the archive.

The programs are written in C, but are specific to VMS.

+++ Editor - Yes by all means if you send it to me +++
---------------------------------

Message-id: <18 Jan 88 10:27:43 GMT WWCOMPS@UK.AC.UMRCC.CMS>
Date:     Mon, 18 Jan 88 10:27:43 GMT
From:     "Mike Glendinning" <WWCOMPS@UK.AC.UMRCC.CMS>
To:       abbottp @ uk.ac.aston
Subject:  UKTeX

 
I've been having a look around your PUBLIC TeX files.  You have quite
a collection!   What I'm really looking for is a HP Laserjet+ driver
that we can run under VM/CMS here.  You have several HP drivers around:
 
   The Beebe drivers, written in C
   Crudetype, with it's HP changefile
   DVIPLUS from the Pavel collection
 
The Beebe driver is out as, unfortunately, we have no C compiler (yet)
for VM.  I've looked at Crudetype, which seems OK, although I wonder
whether a driver written especially for the LJ+ would be better.
 
I have tried to get the DVIPLUS files (from [PUBLIC.PAVEL.TEXDIST.TEX82
UNSUPPORTED.LASERJET]) but they appear to be in some weird (packed?)
format.  Could you possibly arrange to unpack the two files, so I can
FTP them?
 
Alternatively, could you recommend a public domain HP Laserjet+
driver?  Would I be wasting my time with DVIPLUS?  Is the Beebe
driver the best bet?  Is the HP version of Crudetype really crude?
 
    Mike Glendinning,
       University of Manchester Regional Computer Centre.
 
P.S.
  We are getting a VAX machine some time in the next few months,
so it may be better to run all our TeX stuff on that (at least
there is a good collection of TeXware available for the VAX!).
The advantage of running TeX under VM/CMS is that we can take
advantage of the speed of our Amdahl 5890-300E!

---------------------------------

Date:		15-JAN-1988 14:23:22 GMT
From:		S050@UK.AC.UEA.CPC865
To:		INFO-TEX@UK.AC.ASTON

Peter,

I've found a mistake in my setup description for the PC Previewer. 
Its a case of describing what youve done before testing it 
properly.

The directories on the PC for holding the .GF files should in the 
example given (TEX.DOC I think) be TFM190, TFM208, TFM250 rather 
than TFM 191/209/251 - due to rounding differences between metafont 
and dviherc. My apologies about that.

In UKTEX 88/1 did you intend to include the PC previewer heading 
without a corresponding message ?

Laurie Benfield.


+++Editor - Soory about the missing message. I am having problems moving 
the software into the archive as described above. It will be completed as 
soon as possible. +++

---------------------------------

Date:     Tue, 19 Jan 88 14:03:15 GMT
From:     Ian Gladwell (Manchester) <igladwel@uk.ac.ucl.cs.nss>
To:       abbottp@uk.ac.aston
Subject:  Response to your note

Peter,
 
In the Maths dept. at Manchester we use TeX on IBM PC compatibles (only).  
I'd be interested to get hold of the public domain TeX for PCs that was 
announced on TeXhax recently.  Do you know of anyone who's ordered it and 
would be prepared to make copies available in the UK?
 
Nick Higham
Math Dept.
Univ Manchester

---------------------------------

Via:  uk.co.npl.psg; 18 Jan 88 9:11 GMT
Received: from snow by snow.psg.npl.co.uk; Fri, 15 Jan 88 21:02:09 GMT
To: ABBOTTP@uk.ac.aston.mail
Subject: Common TeX updated to TeX 2.7
Date: Fri, 15 Jan 88 21:02:05 GMT
Message-Id: <8494.569278925@psg.npl.co.uk>
From: John Pavel <jrp@uk.co.npl.psg>

John Pavel

------- Forwarded Message

Date:    Fri, 15 Jan 88 09:24:38 -0100 
Subject: C-tex update 
From:    Piet van Oostrum <piet@ruuinfvax.uucp>
To:      jrp@psg.npl.co.uk

Here are the C-tex patches. Note: they apply to version 2.1!!

RCS file: RCS/align.c,v
retrieving revision 1.1
diff -c -r1.1 align.c

+++Editor - The whole message is in

	aston.kirk::[public.c_tex_2_1]update.txt
+++
---------------------------------
 
Date:       Fri, 22 Jan 88 09:52:20 BST
To:         INFO-TEX@UK.AC.ASTON.MAIL
From:       BOOTH.CM@UK.AC.EXETER
Subject:    Line numbering for prose.
Message-ID: <BOOTH.CM.KCWQ@UK.AC.EXETER>

Has anyone managed to discover a way of producing line numbers for
PROSE in TeX?   I can handle numbering of lines of verse, no problem,
but the only solutions for prose I have seen so far involve things
like counting the end of each sentence as a line, which ain't necessarily
so, once TeX has worked its wizardry on the line breaks.   Basically, I
need to get at some sort of internal counter that is updated as each line
is created by TeX.

Any ideas???

Cathy Booth

---------------------------------
 
Date:       Thu 28 January 1988 GMT
To:         INFO-TEX@UK.AC.ASTON.MAIL
From:       Peter Abbott
Subject:    Information on Drivers

Copy of the file

Aston.kirk::[public.texdvi210]drivers.readme


The files DRIVERS.* contain lists of known DVI drivers compiled by Don Hosek
<DHOSEK@YMIR.BITNET>. The file DRIVERS.LASER lists Laser printer drivers;
DRIVERS.LOWRES lists dot matrix and plotter drivers, DRIVERS.TYPESET lists
typesetter drivers, and DRIVERS.SOURCES lists the addresses and availability of
drivers. The LASER, LOWRES, and TYPESET files are listed by output device. The
drivers available for each device are then subdivided into "Big Computers"
(consisting of Amdahl (MTS), CDC Cyber, Cray, Data General MV, DEC-10, DEC-20,
HP9000/500, IBM MVS, IBM VM/CMS, IBM VM/UTS, Prime, Unix, and VAX/VMS), and
"Little Computers" (consisting of Apollo, Atari ST, Cadmus 9200, HP1000,
HP3000, IBM PC, Integrated Solutions, SUN, TI PC, VAXstation/Unix, and
VAXstation/VMS). Under each individual computer is listed each driver known,
and as much information about it as is available. The PREVIEW file has a
slightly different hierarchy: The top level is the computer type (since screen
previewers tend to be less portable), then each driver is listed with the
terminals supported listed below it. When a driver is available from more than
one source, all sources are listed. The program name and author are listed for
additional identification.
 
Additions and corrections are welcome. Send them to Don Hosek, Bitnet:
<DHOSEK@YMIR.BITNET>, Postal Address: Platt Campus Center, Harvey Mudd College,
Claremont, CA 91711


---------------------------------

From: Luke Whitaker <luke@uk.ac.city.cs>
Date:  Tue, 26 Jan 88 15:42:10 GMT 
Message-Id: <8801261542.AA07182@uk.ac.city.cs>
To: info-tex@uk.ac.aston.mail
Subject: TeX/PC

I want to get hold of TeX for an IBM PC/XT. I notice that the Aston C-TeX
distribution contains make.bat and such like for DOS but it appears that all
the DOS conditional code has allready been stripped out. Is this because
someone wants real money for it?

	Luke Whitaker, Dept of Computer Science, City University,
		Northampton Square, London, EC1V OHB.
	Phone: 01-253-4399 x3719
	JANET: l.whitaker@uk.ac.city.cs

---------------------------------

From:    Jack Levy (on GEC 4190 Rim-A at UCL) <CCAAJRL@UK.AC.UCL.EUCLID>
To:      info-tex@UK.AC.ASTON.MAIL
Date:    Fri, 29 Jan 88 10:09
Subject: Gaelic fonts
Message-Id: <29 JAN 1988 10:09:14 CCAAJRL@UK.AC.UCL.EUCLID>
Authentic-sender:   CCAAJRL@UCL.EUCLID

Does anyone know if a TeX font for the old Irish alphabet has been designed?
(I don't know if it has a more technically correct name). One of our users
enquired about this.

Jack Levy,
UCL Computer Centre.

---------------------------------

Date: Fri, 29 Jan 88 17:46:41 GMT
Message-Id: <811.8801291746@latlog.co.uk>
From: IAN@uucp.latlog
To: AbbottP@uk.ac.aston.mail

Here are a couple of comments about my experiences with Nelson Beebe's
DVI->xxx driver suite, which I have been using quite intensively over
the last couple of months.  There are some comments about the TEXIDX
indexing utility as well, which is included on the Beebe distribution.
 
It's hardly necessary to add that the comments here are only representative
of the problems I have had with the software!  In general, I have
had very few of these and I doubt if we would be using TeX today if
this kind of package were not available and readily accessable.

I am actually using a very old distribution of this stuff (2.07 or
thereabouts) but I have checked that everything still applies to the
latest (2.10) as well.  I will be sending a copy of this to him directly
for his comments as well. 
 
Just in passing, I am running all this software now on an MS-DOS machine
with a transputer plug-in card and an HP LaserJet II; do you know of
anyone similar out there with whom I could swap notes?
 
 
1) DVIJEP driver vertical positioning.
 
   I have been using LaTeX heavily with this driver, and for some reason
the heads of horizontal arrows made with, e.g., \vector(1,0){10} never
seemed to line up correctly with the central rule, although heads of
vectors in other directions seemed to be OK (or at least much better).
 
   I believe that this is due to a problem in DVIJEP in the macros RULE
and RULE2 (defined near the top of DCVIJEP.C) whereby the vertical
position of a rule is miscalculated by 1 pixel.  This may not sound like
much, but the arrowhead is only a few pixels across at this resolution
and the error is quite noticeable.
 
   The problem seems to derive from the fact that TeX's reference point
is at one corner of the left-hand-side of the rule, while the LaserJet
uses the other left-hand corner.  The RULE macros compute one from the
other by adding the height of the rule (i.e., the number of pixels in
its height).  I believe that this misplaces the rule by one pixel, and
the fix I have been using is for both of these macros to include an
explicit -1 for the y co-ordinate, thus:
 
   #define RULE(x,y,width,height) {\
	MOVETO(x,(y)+height-1);\
	(void)fprintf(plotfp,"\033*c%da%dbP",width,height);\
   }
 
   #define RULE2(x,y) {\
	MOVETO(x,(y)+rule_height-1);\
	OUTS("\033*cP");\
   }
 
   This fix appears to clear up the problem almost entirely; there is a
half-pixel error anyway which comes from the fact that the standard
LaTeX rule is 2 pixels high (i.e., symmetric around the boundary between
two pixels) while the arrowhead is an odd number of pixels high (i.e.,
symmetric around the middle of a pixel).  This is still visible, but not
nearly so much.
 
 
2) DVIJEP driver horizontal positioning.
 
   This is really just a warning to other users of 300dpi printers that
the default MAXDRIFT of 2 pixels (the amount by which characters can
drift out of horizontal alignment before the driver is forced to
reposition explicitly) may be fine for 1200dpi phototypesetters but not
for us poor laser printer users. 
 
   I had initially ignored this parameter; output looks fairly good in
most cases.  However, this amount of drift can amount to a very visible
error perhaps once every couple of pages.  The problem is particularly
noticeable for some reason in fixed-pitch fonts like \tt, probably
because one is accustomed to thinking of them as being completely
regular.  The 1/150th or 1/75th of an inch error which can come out of a
worst-case character drift of 2 pixels (latter for both characters
shifted in opposite directions) can be quite jarring (it is after all
0.5--1pt). 
 
   I have now resorted to a MAXDRIFT of 0, which appears to sort this
out.  The output file obviously gets a bit bigger, but I am glad to say
that this is not by very much.
 
 
3) TEXIDX portability
 
There is what I believe to be a typo in TEXIDX.C which, although it will
not change the meaning of the program on MOST machines, will prevent
TEXIDX from working properly on machines which pass union value
arguments in odd ways (e.g., as a pointer to the actual value).
 
Before: (around line 580)
 
   tem = compare_field (keyfields, line1->key.keytext, line1->keylen, 0,
                                   line2->key, line2->keylen, 0);
 
After:
 
   tem = compare_field (keyfields, line1->key.keytext, line1->keylen, 0,
                                   line2->key.keytext, line2->keylen, 0);
 
 
4) TEXIDX functionality
 
TEXIDX attempts to cover the case of the initial letter of an index
entry being an odd character like `\' by creating an \initial containing
a \verb|\| command.  There are several reasons why this won't work, one
of the more interesting being that the `\' is not escaped and a funny
character is inserted instead of `\v'.  I change this to set the
character explicitly in \tt.  Note that I also add the characters `<'
and `>' to the list of characters for this treatment as they do not
exist in the roman fonts, instead you get Spanish upside-down `!' and `?'. 
 
Before: (around line 1260)
 
   if (strchr("^~\\",*initial) != (char*)NULL)
      fprintf(ostream,"\verb|%c|",*initial);
 
After:
 
   if (strchr("^~\\<>",*initial) != (char*)NULL)
      fprintf(ostream,"\\tt\\char%d",*initial);
 

5) GNUINDEX, TEXINDEX Styles
 
   The GNUINDEX.STY and TEXINDEX.STY style option files are included to
allow inclusion of proper 2-level indexing in a LaTeX source file.  In
these, there is a \SUBINDEX{primary sort-code}{real primary}{secondary}
command defined, in which the sort code for the whole entry is supposed
to be derived from the given primary sort-code and the secondary entry
information.  Unfortunately, the actual definition of the \@WRSUBINDEX
command which is used to implement this completely ignores the primary
sort-code parameter.  The result is that subindex entries in which the
real primary starts with a control sequence get sorted under `\' rather
than under the provided sort code.  The fix goes as follows; simply
change one character in the \@WRSUBINDEX macro
(both TEXINDEX and GNUINDEX require this):
 
  \def\@WRSUBINDEX#1#2#3#4{\let\thepage\relax
     \xdef\@gtempa{\write#1{\string
% NB: #2<tab>#4, NOT #3<space>#4 in the next line
      \entry{#2	#4}{\thepage}{#3}{#4}}}\endgroup\@gtempa
     \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}

*--------------
        Ian Young, 3L Ltd
post:   3L Ltd, Peel House, Ladywell, Livingston EH54 6AG, Scotland
e-mail: ian@latlog.uucp

---------------------------------

Date: 31 Jan 88  02:48:20 gmt
From: G.Toal @ uk.ac.edinburgh
Subject: IPA Fonts etc.
To: info-tex@uk.ac.aston.mail
Message-ID: <31 Jan 88  02:48:20 gmt  050745@EMAS-A>

I recently had a request from someone at RSRE about IPA fonts and
TeX :- if the person who mailed me is reading, sorry I didn't reply directly,
but I lost your original mail.  After a month of hectic home-moving
I've at last founmd time to reply...   I'll post this through UKTEX
as it may be of interest to others.  The info was sent to TeXhax in
early December, but I think it went down a transatlantic black hole!

   Back in early December, Helmut Feldweg wrote to TeXhax noting that
there was no longer an IPA font.  At that time, I had just been looking
into IPA, so here is some of what I found to tell him:

Christina Thiele of Carleton is a phoneticist, and in mail to me once
offered to keep track of any IPA activity.  If she is still doing so,
her address is wsscat@bitnet.carleton 
[Actually, I have a feeling there is a typo on the piece of paper
I'm copying this from - it might be "wscat@bitnet.carleton ???]

Christina & Carleton have an IPA font similar in style to CMBX10.

Dean Guenther has an IPA font for sale; his address is GUENTHER@EARN.WSUVM1

Tibor Tscheke's company, Sturtze AG, also has an IPA font for sale;
the address is:
Tibor Tscheke / Head, Computer Science Department / Universitaetsdruckerei /
H. Sturtze AG / Beethovenstr. 5 / D-8700 Wurzburg / West Germany.
(Sorry, I don't know the e-mail address)

+----------------------+

The people above all use TeX \control \sequences to enter the IPA
characters - e.g. \schwa.  My interest was in finding a byte-coding
for single-character representation of the IPA glyphs.  It turns out
that computer-phoneticists don't really have such a thing.  I was
thinking of something akin to the ISO latin1 through latin4 8-bit
alphabets.

   There is an excellent paper on computer representations for
phonetics by J C Wells of the Dept of Phonetics and Linguistics,
University College London, published in June 1987, which contrasts
several machine-representations.  The concensus of opinion is that
transcription systems using 7-bit simple ASCII are preferred.
Only IBM uses an 8-bit code and it is apparently not popular.

This is not a significant problem for TeX as it does not accept
8-bit input anyway, but I cannot help feeling that ALL the transcription
systems listed in the publication above are quite inappropriate
for machine manipulation.

   The publication is internal to an Alvey-funded Speech group,
so I don't think I would be allowed to copy it for distribution,
so I suggest that anyone who wants a copy writes directly to
Dr Wells at UCL.  The title is "COMPUTER-CODED PHONETIC REPRESENTATIONS"
and I doubt it will be available by electronic mail, as it is liberally
scattered with phonetic symbols produced (I think) on a down-loadable
Epson.

Graham Toal.

---------------------------------

Via:  uk.co.npl.psg; 30 Jan 88 20:58 GMT
Received: from snow by snow.psg.npl.co.uk; Sat, 30 Jan 88 20:25:25 GMT
To: morgan@edu.uci.ics
Cc: PABBOTT@uk.ac.aston
Subject: Self-Dumping C-TeX
Date: Sat, 30 Jan 88 20:25:21 GMT
Message-Id: <7922.570572721@psg.npl.co.uk>
From: John Pavel <jrp@uk.co.npl.psg>


The patches following the article below will result in a self-dumping C-TeX.

John Pavel

+++Editor - The file to fetch is

	aston.kirk::[public.ctex_2_1]selfdumpc_tex.txt

+++
---------------------------------
!!
!!  Replies/submissions to            info-tex@uk.ac.aston   please
!!  distribution changes to   info-tex-request@uk.ac.aston   please 
!! 
!!   end of issue