[comp.text] TeXhax Digest V88 #100

TeXhax@cs.washington.edu (TeXhax Digest) (11/19/88)

TeXhax Digest    Friday,  November 11, 1988  Volume 88 : Issue 100

Moderators: Tiina Modisett and Pierre MacKay

%%% The TeXhax digest is brought to you as a service of the TeX Users Group %%%
%%%       in cooperation with the UnixTeX distribution service at the       %%%
%%%                      University of Washington                           %%%

Note: This issue has been prepared and ready to go for a week, but for 
      several reasons, not all of them associated with the birth of the
      loathly worm, we could not get it through the mailer.  We hope to
      catch up very soon.  Several more issues are already awaiting
      delivery.

Today's Topics:         

                  The first Northwest issue of TeXhax
                  Short name macros (with correction)
                        Bug in VMS change files
                   Macintosh illustrations and psfig
                       New PostScript driver
                          Online viewing
               Waterloo SCRIPT conversion to LaTeX or TeX
                              TeX 2.0
                           TeX on VM/CMS
                11pt. fonts query (TeXhax Digest V88 #95)
                           TUGboat access

------------------------------------------------------------------------------
From: texhax@cs.washington.edu
Subject: The first Northwest issue of TeXhax


With this issue, the distribution of TeXhax from the University of
Washington begins.  Our chief concern in the first couple of issues
will be to come back up to the standard set by Malcolm Brown over
the past years.   We have not much experience with this sort of thing
yet, and we ask your indulgence.  

As we gain that experience, we will try to add some features to the
editing of TeXhax.  One will appear in this first issue.  Wherever the
subject is clear enough, we intend to introduce a line containing
keywords, in the form:

%%Keywords: LaTeX, footnotes, macros, etc.

We will let the range of keywords grow naturally at first, until we
feel that it covers all likely subjects, and then we will try to stop
adding new ones and stabilize the set.  

If anyone would care to help us out with a simple indexer which will
cross-reference these keywords with appropriate parts of the message
header, we will be very appreciative.  At very least, we believe that
such an indexer should retrieve the From: line and the Subject: line
from each message, together with the TeXhax issue number.  If you can
suggest any other (manageable) addition to this system of cross-reference,
please let us know.  

In addition, we intend to develop a library of macro texts, extracted
from the TeXhax submissions, and to make this available in whatever
forms we can to TeX users.  

These new efforts are made possible by the decision of the TeX Users Group
to give direct support to the TeXhax Digest.  From now on, the TeXhax
Digest will be even more closely associated with the activities of the
TeX Users Group.  If you are unfamiliar with the TeX Users Group, you
will find a form at the end of this digest on which you can request further
information.

We are open to suggestions, and will carry them out to the best of our
ability

We owe especial thanks to Malcolm Brown for his maintenance of this
digest up till now, and particularly for his patience over the past
in keeping the digest going while we got some of the essential features
in place.  

Your new moderators are:
					 Tiina Modisett 
					     and 
  					 Pierre MacKay

(To eliminate any doubts right at the start---the two ii are
correct)

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

Date: Sat, 05 Nov 88 23:42:21 ECT
From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Subject: A small idea for short name macros (with correction)

%%Keywords: macros

I got the following idea from looking at the file GERMAN.STY.  In German
Tex, this file, a number constructs of the type "', "`, "< and so on are
used.  This is implemented by letting " be an active character, whose
macro expansion is then defined by a giant \if ...  \else \if ...
construct, ending with a practically uncountable \fi\fi\fi...  string.

``Surely'', I thought, ``this must be doable in a more elegant manner?''.
vAnd so it was.  I made up a way to define "' and the like to be macros
in their own right, so the following line in german.sty

\else\if\string#1|\discretionary{-}{}{\kern.03em}%

could then be replaced with

\sdef"|{|\discretionary{-}{}{\kern.03em}}

Solving this problem also produced the additional benefit of providing a
multitude of new, short macro names.  I teach a class in mathematical
logic this term, and for my classroom notes I often need symbols like
\vdash and \models.  In order to make these easier to type and to make
the manuscript look more like the real formulas, I made | active, and
included the following definitions, so I can say |- and |= instead.

\sprefix|
\sdef|-{\vdash}
\sdef|={\models}

The macros work by making a (hopefully!) untypable control sequence so
that |-, for example is expanded into \csname!|-\endcsname.  The ! is
thrown in for good measure, since you might want to do this with @ and
then there is the potential for conflicting with plain's ``private''
control sequences.  Definitions follow:

%%% Moderator's note: To avoid confusion, we have consolidated a
%%% correction with the original submission. Here is the note
%%% that accompanied the correction.
% Ooops - in my eagerness I performed one last polishing on my macros
% before I posted them.  Unfortunately I did not test the result well
% enough - as a matter of fact, the macros as they stand will redefine
% \csname....

Here are the correct macros:

\def\sprefix#1{\def#1##1{\csname!\string#1\string##1\endcsname}}
\def\sdef#1#2{\expandafter\def\csname!\string#1\string#2\endcsname}
\def\slet#1#2{\expandafter\let\csname!\string#1\string#2\endcsname}

Yes, that's all...  If the greatness of an idea is inversely
proportional to its simplicity, this must be a great idea indeed :-)

- Harald Hanche-Olsen       Division of Mathematical Sciences
  Hanche@norunit.bitnet     The Norwegian Institute of Technology

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

Date: Fri, 04 Nov 88 15:44:30 GMT
From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: VMS(+others) TeX(+others) bug (was: 256-char TeX)

%%Keywords: VMS, TeX, bug

In Texhax #97, Dr R.M. Damerell writes

> Please may I draw your attention to a bug in the VMS change files.
> (Every VMS change file I have seen contains this). Array  xord  is
> defined as
>
> xord: array [char] of ascii-code ;
>
> and therefore it has 256 elements, but only the first 128 of them get
> initialised.

I think Dr Damerell has uncovered a can of worms. The bug is not
in the declaration, which is, prima facie, correct: it comes from the
original WEB

@!xord: array [text_char] of ASCII_code;

by the (usually correct) mapping |text_char| -> |char|. It lies in the
fact that the VMS change files (at least the ones I have seen) do not
alter the values of |first_text_char| and |last_text_char| from their
distribution defaults of 0 and 127 respectively. These usually *do*
need altering, *even* for ASCII-based systems: as the comments say, they
are supposed to represent the minimum and maximum value of the |ord| of
a |text_char|. A |text_char| is anything that might be read from an
|alpha_file|, thus usually a |char|.

For VMS Pascal, these limits should certainly be 0 and 255. The effect
of failing to alter |last_text_char| is that characters in input files
from the "extended character set" will be translated unpredictably into
|ASCII_code| values in |input_ln|. (With the correction, they will
translate to |invalid_code| (i.e. 127). In due course, this generates
a "Text line contains an invalid character" error. Usually, anyway. At
least predictably.)

Cursory inspection of change files for Unix systems as well as VMS
ones seem to reveal that this oversight is very common, and applies
not only to TeX, but to METAFONT, and other programs that have borrowed
TeX's "character set" section (BibTeX, for example).

Some of these systems may used signed characters, and need the range
-128..127 rather than 0..255. I suppose that for some systems it may
even be correct to set up the two halves of |xord| identically, so as
to ignore the "parity bit". But it's never correct to have a range of
only 128, *unless* a |text_char|, as delivered by |read| (or whatever
you have replaced it by in |input_ln|) is so restricted.

Chris Thompson
JANET: cet1@uk.ac.cam.phx
ARPA:  cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk
-------------------------------------------------------------------------------

Date: Fri, 4 Nov 88 17:31:18 PST
From: munson@renoir.Berkeley.EDU (Ethan V. Munson)
Subject: Macintosh illustrations and psfig

%%Keywords: Macintosh, macros, PostScript

I am trying to create documents which include figures generated by
drawing programs on a Macintosh.  I have the psfig macros and am able to
use them successfully with hand generated PostScript and with PostScript
generated by a program called "PS from Mac".  The latter solution is
the most useful, but the PostScript files created by "PS from Mac" do
not have a perfect correspondence with the normal Mac output.  I
would like to do better.

I have tried Ed Moy's prepfix, but while it permits me to print the
MacDraw files using the UNIX lpr command, it doesn't solve the problem
with psfig.  I have also tried Encapsulated PostScript files generated
by Cricket Draw.  I can't get these to print anything other than a blank
page.

Has anyone had more success than this?  I think the secret has something
to do with the bounding box comment.  There are no PostScript errors
generated, but the figure is always blank.  I have tried a number of
creative values for the bounding box, because I know that the Mac
places the origin at the upper left corner of the page,
but nothing seems to work.

Ethan Munson
munson@renoir.Berkeley.EDU
...!ucbvax!renoir!edu
munson@UCBRENOI  (this is supposed to work for BITNET)
-------------------------------------------------------------------------------

Date: Fri, 4 Nov 88 12:39:20 GMT
From: jclark!jjc@uunet.UU.NET (James Clark)
Subject: A new PostScript driver

%%Keywords: PostScript, dviware

Over the last year or so I've written a new PostScript driver,
somewhat unimaginatively called dvitops, which I have placed in the
public domain. There are quite a few PostScript drivers already
available but most of them have been adapted from drivers for other
printers and thus fail to take advantage of the unique features of
PostScript. Dvitops has been developed from scratch especially for
PostScript.

The most important feature of dvitops is that when used with
PostScript fonts it produces completely device-independent output. A
fairly common misconception about PostScript is that any PostScript
program is automatically device-independent. This is no more the case
for PostScript than it is for, say, C. One has to work really quite
hard if one is completely to avoid device-dependencies: one has to
avoid making any assumptions about resolution, fonts, memory or
operators that are not part of the language definition. The trickiest
area is rounding: most drivers do this themselves; true
device-independence requires this to be done in PostScript.

Producing rules with the correct dimensions turns out to be quite
complicated. Those of you with PostScript printers may have noticed
that ruled tables or characters containing rules (such as \overbrace,
\underbrace and \sqrt) sometimes don't look quite right.  It turns out
that when PostScript fills a path, it paints a pixel just in case some
part of the pixel lies within the path. Thus a rectangle 1/2 a pixel
wide can end up 2 pixels wide on the paper. The solution is to
position the corners of rules in the middle of pixels and to subtract
one pixel from the height and width of rules. It is possible to do this
device-independently in PostScript.

Dvitops supports either ordinary PostScript fonts or Metafont
generated fonts in pk format; gf and pxl formats are not supported.
One problem with PostScript printers is that comparatively little
memory is available for downloading fonts.  A fundamental design goal
of dvitops was to support documents with arbitrarily complex font
requirements even on first generation PostScript printers having
pathetically little memory.  This has been achieved without
sacrificing page independence (pages should depend only on the prolog
and not on each other), so that it is possible to reorder the document
or to print only a subset of it, after it has been composed. Like a
number of other drivers dvitops uses a two-pass approach, gathering
information about font-usage on the first pass.  The output for each
page is sorted by font. The output in each font is bracketed by a
save/restore pair. Thus dvitops requires only enough memory to hold
one font. It can also take advantage of as much memory as you have: it
downloads as many fonts as possible in the prolog of the document so
that they do not need to be downloaded on each page that they are
used. Of course, with pk fonts it only downloads the definitions for
those characters that are actually used.  Dvitops also allows one to
use arbitrarily many downloadable PostScript fonts. It does this by
putting an %%IncludeFont comment between at each place that the font
is to be included. There is at most one such comment for each font per
page (it knows that Optima at 12pt and Optima at 10pt, say, are the
same font). For this to work you will need a spooler which understands
version 2.0 of the Adobe Document Structuring Conventions, and which
can handle font downloading. I have written a filter to do this which
can be stuck on the front of a spooler or run separately. If you want
to use many downloadable fonts, you will need a lot of patience.  A
typical Adobe font is over 100k when unpacked.  If you have say 100
pages and four fonts that have to be downloaded separately on each
page, and you talk to your printer a 9600 baud, it will take you over
9 hours!

Dvitops has a few specials including one to import PostScript graphics
and an `inline' special to include PostScript code.  There is also an
interesting set of specials that allows you to apply arbitrary linear
transformations to regions of the dvi file in a convenient fashion.
Regions of the dvi file are delimited by \special{dvitops: begin
region_name} and \special{dvitops: end} commands. You then specify an
origin for the transformations to be applied to a region using
\special{dvitops: origin region_name}, which sets the origin at the
current point. You then apply one or more transformations using
\special{dvitops: rotate region_name rotation_amount}, or
\special{dvitops: transform region_name a b c d tx ty}, which applies
the tranformation represented by the matrix
                       |a  b  0|
                       |c  d  0|
                       |tx ty 1|
to the region. These transformations work correctly with graphics
produced by the inline special, as well as with imported graphics.

Dvitops works on MS-DOS and Unix machines. It should be
easily portable to any machine with a decent C compiler and a
reasonable architecture (ASCII and 8-bit bytes are required).  It was
originally developed on a MS-DOS machine, and some care was to taken
to achieve maximum efficiency on a 16-bit architecture, by avoiding
the use of 32-bit operations wherever possible.  It consequently runs
up to 3 times faster than some other PostScript drivers on MS-DOS
machines (the relative speed depends on whether you are using floppy,
hard or RAM disk; it is relatively much faster on RAM disk). There is
much less difference on 32-bit machines.

Dvitops is unfortunately too big to fit into one mail message. If
anybody in the UK wants to get hold of it they can contact me
directly.  I will also mail a copy or two per country to anybody who
volunteers to make it available for anonymous FTP, or put it on a
info-server or archive-server, or otherwise redistribute it.  If
anybody should volunteer, I'll send details to TeXhax.

James Clark

jjc%jclark.uucp@ukc.ac.uk					               30 Peel Street
jjc@jclark.uucp								       London W8 7PD
uunet!mcvax!ukc!pyrltd!slxsys!jclark!jjc		England
-------------------------------------------------------------------------------

Date:  Sat, 5 Nov 88 10:44:34 EST
From: spooky!witr@bu-it.BU.EDU
Subject: RE: Producing simple document for online viewing....

%%Keywords: LaTeX, previewer

In TeXhax Digest V88 #99 Russell Fulton says:

What I need is a program that would take a LaTeX input file and
produce	a file suitable for viewing on a terminal with an editor. It
does not have to reproduce different type sizes, mathematical
equations etc. just the basic text and headings.
 
This is a common need for computer oriented documentation, and has
been nicely addressed with the TeXInfo documentation system used in
the GnuEMACS editor, and other Gnu code.  Run a TeXInfo through TeX
and you get typeset documents, run it through another processor and
you get an Info database accesable online.  It is available from all
the normal Gnu locations, but if you MUST use LaTeX be prepared to
hack and chop it to pieces.
-------------------------------------------------------------------------------

Date: Sat, 5 Nov 88 22:41 GMT
From: Peter Flynn UCC <CBTS8001%IRUCCVAX.UCC.IE@Forsythe.Stanford.EDU>
Subject: RE: Waterloo SCRIPT conversion to LATEX or TEX

%%Keywords: LaTeX, TeX, SGML

Ton de Hann <u639019@hnykun11.bitnet> asks if there is a utility to do this.

Yes, the DFN (Deutsche Forschungsnetz = German Research Network) in Berlin
have a product called DAPHNE which takes SGML and produces LaTeX. SGML is
not quite Waterloo SCRIPT (I should say Script is not quite SGML, because
SGML is an ISO standard), so you need some editing. I have tried it, it's
quite good, but because I don't do SCRIPT I can't say how much work would
be needed. Not much I guess. The product is non-chargeable to academic sites
and runs on VAX/VMS IBM/VM and several others. I have an address somewhere
(email I mean), I will dig it out for anyone who want to mail me for it.
It was someone @zpl.dfn.dbp.de but I can't lay my hands on it this second.

...Peter Flynn
----------------------------------------------------------------------------

Date: Fri, 4 Nov 1988 15:54:54 PST
From: Max Hailperin <mxh@ksl.stanford.edu>
Subject: TeX 2.0 -- how outdated is it?

%%Keywords: TeX

I have a system with TeX 2.0 running on it, for which updating to current
version (2.93?) would be nontrivial.  My question: how outdated is 2.0?
I looked at the change list at the top of 2.93's tex.web, and most of the
changes looked quite minor, but there were a few I couldn't be sure of.
Does anyone want to express on opinion on whether this is worth worrying
about?  Thanks.
-------------------------------------------------------------------------------

Date: Sun, 6 Nov 88 06:31:28 EST
From: zaccone - 1393 <zaccone%rigel.bucknell.edu@Forsythe.Stanford.EDU>
Subject: TeX on VM/CMS

%%Keywords: LaTeX, TeX, VM/CMS

I recently helped a friend print a LaTeX file on VM/CMS.  This was a
file that I had successfully formated on a VAX running Unix, on a Sun
3, and on a Macintosh running Textures.  However, on VM/CMS we got lots
of overfull \hbox's and other warning messages.  When I looked at the
output, it was apparent that the fonts weren't normal computer modern
fonts (although they were called that).  I asked the people in charge
of her computer center, and they claimed that this was "the CMS version
of TeX that we get via normal distribution" (whatever that means).
They have no TeX expertise and aren't willing to look into the
problem.

Can someone point me to a version of TeX/LaTeX that runs under CMS,
and which behaves in a fashion similar to other TeX implementations?
Have others experienced this problem also?

Rick Zaccone
zaccone@bknlvms.bitnet
zaccone@rigel.bucknell.edu
-------------------------------------------------------------------------------

Date: Sun, 6 Nov 88 17:49:30 EST
From: Greg McGary <gm@cs.duke.edu>
Subject: Multi-page tables with column-headings on each page?

%%Keywords: tables, headings

I would like to make a multi-page table with column-headings appearing
at the top of each page.  I suspect I have to do something ugly with
the output routine, but before I go off and re-invent the wheel, I'd
like to know if someone else has done this successfully...

Thanx in advance for all clues!
-- Greg McGary	
-- 4201 University Drive #102, Durham, NC 27707   (919) 490-6037
-- {decvax,hplabs,seismo,mcnc}!duke!gm
--				    gm@cs.duke.edu
------------------------------------------------------------------------------

Date: Sun, 6 Nov 88 21:07:59 PST
From: mackay@cs.washington.edu (Pierre MacKay)
Subject: 11pt fonts query (TeXhax Digest V88 #95)

%%Keywords: fonts

A full sequence based on cm*11, with something like the proportions
developed by Sauter's interpolations would certainly work, but it would
have to be a set running in parallel with the cm*10 set.  Once you
introduce the useful halfstep, you break, to some degree from the
convenience of consistent integer magsteps.  

In the days of 200dpi devices, this problem was somewhat masked, because
we tended to have a full set developed from a base (in old pxl notation)
of 1315, along with the set at 1000.  Effectively, that supplied the
full series in the halfsteps, and it also filled in some of the gaps
at the high end.  The real beneficiaries of this were the users of
240dpi devices, who could call on the 1315 series without even being aware
that it was meant for an entirely different device (Inking was a bit out
of line, since 200dpi Versatec fonts were usually a lot blacker than
240dpi laser printer fonts, but the definition was crude enough to hide
the anomaly.)  Since the adoption of 300dpi fonts, the interpolated
series has disappeared, because there was no specific machine that
used them.  Maybe they should return.  Magnification by 1.315
produced output that could look very creditable after reduction at
the 74% level on a copier.  A 6 X 9 page would be 7.9 X 11.84 inches,
which you couldn't produce on a laserwriter, but could produce on
a TI 2115, and it might get around some of the unsatisfactory aspects
of the write-white fonts on the TI.  (No advertisement, these just happen
to be the devices I know best.)

It all depends how many fonts you can afford to store.


Email:  mackay@june.cs.washington.edu		Pierre A. MacKay
Smail:  Northwest Computer Support Center	TUG Site Coordinator for
	Lewis Hall, Mail Stop DW10		Unix-flavored TeX
	University of Washington
	Seattle, WA 98195
	(206) 543-6259
-------------------------------------------------------------------------------


Date:     7-NOV-1988 13:10:42 GMT
From: KNEIJ%VAX.OXFORD.AC.UK@Forsythe.Stanford.EDU
Subject:  Treachery?

%%Keywords: TUGboat

Can any kind person out there tell me how to get hold of TUGboat, join
the user group and otherwise get in touch with the rest of the TeXing
world.


Ivo Kneij
kneij@uk.ac.oxford.vax

PS I still like TeXhax!!
------------------------------------------------------------------------------

From: The Moderators
Subject: The TeX Users Group

How very glad we are that you asked that question.

The form request below is provided for your convenience.  Alternatively,
you can send a request to TUG@Math.AMS.COM, containing the same information
about yourself and your site.

TeX Users Group Institutional/individual Membership Information request.

                    ----------------cut here----------------




To: The TeX Users Group
    P. O. Box 9506
    Providence, Rhode Island 02940-9506
    U.S.A


Please send me information concerning [institutional individual] Membership in
                               (cross out whichever is not applicable)
The TeX Users Group.

    Name:___________________________________________________________

    Institution:____________________________________________________

    Street Address:_________________________________________________

    Box or MS address:______________________________________________

    City and State/Province:________________________________________

    Zip or Mail code:_______________________________________________

    Country:________________________________________________________


If you would also like your name to be forwarded to the TUG site-coordinator
who distributes TeX for your operating system, fill in the following line.

    Machine and Operating System:___________________________________



                    ----------------cut here----------------

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

%%% The TeXhax digest is brought to you as a service of the TeX Users Group
%%%       in cooperation with the UnixTeX distribution service at the 
%%%                      University of Washington
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%%  BITNET: send a one-line mail message to LISTSERV@UWAVM.ACS.WASHINGTON.EDU
%%%         SUBSCRIBE TEXHAX <your name>    % to subscribe
%%%
%%%     All others: send mail to
%%%           TeXhax-request@cs.washington.edu
%%%     please send a valid internet address!!
%%%        in the form name@domain or name%routing@domain
%%%
%%%
%%% All submissions to: texhax@june.cs.washington.edu
%%%
%%% Back issues available for FTPing as:
%%%          machine:              directory:  filename:
%%%   JUNE.CS.WASHINGTON.EDU       TeXhax/TeXhaxnn.yy
%%%                       nn = issue number
%%%              yy = last two digits of current year
%%%\bye
%%%

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

End of TeXhax Digest
**************************
-------------------------------------------------------------------------------