TeXhax@Score.Stanford.EDU (TeXhax Digest) (10/18/88)
TeXhax Digest Monday, October 17, 1988 Volume 88 : Issue 91
Moderator: Malcolm Brown
Today's Topics:
Re: Question (UNIX, typesetter)
TeX dumps core!
Further on TeX dumps core
Re: Problems with journals that accept TeX
Re: TeXhax Digest V88 #88
Diffs to dvips
Re: TeXhax Digest V88 #88 (LaTeX notes)
Re: Bug in ctex.ch (web2c 2.2)?
computer modern for aps typesetter
TP4 Version of TeX
Laserprinter Query
Re: BibTeX sorting
Extending TeX's alphabet from 128 to 256 characters
Full page bitmap of dvi file
----------------------------------------------------------------------
Date: Mon, 10 Oct 88 16:23:13 CDT
From: William LeFebvre <phil@rice.edu>
Subject: Re: Question (UNIX, typesetter)
> Apparently the order of the bytes is different in a VMS and a UNIX
> system.
What matters is the hardware, not the operating system. Nonetheless, a
machine's byte ordering has NO BEARING on a dvi file. The dvi format
specifically defines the byte ordering of binary numbers. Thus, a dvi
file is portable between any two machines.
What may be tripping you up in this case is different block sizes.
Unix doesn't care about blocking, but VMS usually does. You might want
to try the following: before putting the dvi file on tape, make sure
that its length is a multiple of 1024. If it is not, pad it out to the
nearest multiple of 1024. Do this by adding a sufficient number of
bytes to the file and make each byte equal to the octal value "337"
(hex "DF"). This is the dvi padding-byte value. You will probably
need to write a C program to do this, but it's an easy program to
write. It might help if the typesetter people would tell you EXACTLY
what format tape they need (record size and number of records in a
block---or just block size would be helpful). If they say something
like "block size N, unformatted records", then pad the file to a
multiple of N (as described above) and make the tape with "dd bs=N".
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
From: munnari!goanna.oz.au!isaac@uunet.UU.NET (Isaac Balbin)
Subject: TeX dumps core!
Date: Tue, 11 Oct 88 17:59:37 +1000
The unspeakable? --- or is this just another example of the balbin triangle?
Using LaTeX 2.09 (Apr 88), and TeX , C version 2.93, I get a floating
point exception & core dump (from vlistout(),3 of them preceded by a zshipout)
on a particular file.
Interestingly, if I tex this file (as \input) _after_ another file (also
\input) there is no core dump. The core dump occurs whilst processing
pap.bbl although I don't think that has much to do with it? I use
bibtex 0.99c (the C version).
Of even more interest? is that it dumps core using CommonTeX as well!
Whatsmore, in the same routine (suprise) (vlistout).
Of even more interest? it doesn't dump core on an old version of TeX
in pascal on a Sun 3. I think the operative thing here is the Sun 3
as distinct from the architecture I am running it on which is an
Encore under System V (although the latter is irrelevant).
So, who is interested in such manifestations? Is there anyone out
there who would like to try latexing the file on their architecture
and seeing if the same occurs? Has this occured to anyone else?
What hidden gottcha's should I check for?
Thanks, in advance, for any help
Isaac Balbin
Department of Computer Science, ACSnet: isaac@goanna.oz
RMIT,
GPO BOX 2476 V, ARPA:isaac%goanna.oz.au@uunet.uu.net
Melbourne, 3001 CSNET: isaac%goanna.oz.au@australia
AUSTRALIA UUCP: ...!uunet!goanna.oz.au!isaac
%%% Part Two of this tale follows immediately....
------------------------------
From: munnari!goanna.oz.au!isaac@uunet.UU.NET (Isaac Balbin)
Subject: Further on TeX dumps core
Date: Tue, 11 Oct 88 18:31:38 +1000
Further to my previous message, I think I may have discovered
a cause (it isn't a reason) for the core dump.
I was trying to cajole LaTeX, in a general way, to never break
pages whilst handling one of my many tabbing environments.
These were not figures or tables, just little bits of code.
Now, I know there are probably other ways .... I was looking for
something short and sweet which would always work. (if you have
any sure fire method you want to tell me about ... go for it!)
So, I merely did the following ...
\filbreak{
\begin{tabbing}
......
\end{tabbing}
}
Now this works fine ... however if you have two filbreaks on a
page (I am guessing) something gets screwy. I mentioned that when I
latex something before the troublesome file the core dump disappears.
True enough, but the output which is not what one would expect
indicates that the second filbreak caused a whole lot of space to
be left just before the references section even though that was
not required. Okay, it should be obvious by now that I am not TeXpert
but before you sharpen your claws, and propose a different LaTeX
based solution which you swear will always work, do you think that
a core dump is justified? Or is that just a C compiler bug in the
encore C compiler (quite possible) (I should try compiling with gcc).
Thanks for your time ...
PS. When I removed filbreaks --- no core dump.
------------------------------
Date: Mon, 10 Oct 88 16:36:09 CDT
From: William LeFebvre <phil@rice.edu>
Subject: Re: Problems with journals that accept TeX
> ... journals tend to wind up with two kinds of articles with totally
> different outlook. This is ugly....It may be acceptable (or rather, it
> is common practise) for rapid dissemination proceedings, it just won't
> do for regular scientific publication.
Agreed! Journals should take their time: quality is more important
than speed for a journal.
Clearly what must happen, and what may happen in the not-to-distant-
future, is that the old typesetters (the people, that is) must be
reeducated in the area of electronic typesetting (or make way for those
who are). This is a brand new field (newer even than computer
science)---it will require its own specialists and it will take awhile
to mature. But I see this as the way of the future. Right now we have
people who specialize in conventional typesetting. They know the right
way to place text on a page: where to put in extra space, where to
squeeze characters together, where to break lines and pages, etc. What
we need to have in the future is people with this same knowledge and
skill who use TeX (or some yet-to-be-invented successor) as their
typesetting tool rather than the current conventional typesetting
hardware. Where these journals are going wrong is in the assumption
that TeX will eliminate the need for a typesetter. It doesn't: it is
just providing a more powerful tool for the typesetter to use.
Weak analogy:
mainstream typesetting --> machine language;
TeX --> high-level (compiled) language.
The introduction of Fortran caused many negative feelings among the
die-hard assembly/machine language programmers. I see something
similar happening in typesetting with the introduction of TeX.
This will all just take time to develop.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: Mon, 10 Oct 88 18:22:50 EDT
From: zwicky@pterodactyl.cis.ohio-state.edu (Elizabeth D. Zwicky)
Subject: Re: TeXhax Digest V88 #88
About dvi2ps on a typesetter. No, it won't always work. Yes, PostScript
is a standard. No, it isn't necessarily the environment on the typesetter.
dvi2ps (in at least some of its versions) contains LaserWriter specific
code - sort of like all those C programs that dereference a null pointer
because they were written on Vaxen. In particular, one that we used to
run used the page type "note" which not all printers have. There is an
Appendix to the Red Book (in some editions) which talks about the
LaserWriter. Using any PostScript primitives mentioned therein makes
your code non-portable, which as we all know is a sin. A more modern
dvi2ps should solve the problem.
Elizabeth Zwicky
------------------------------
Date: Mon, 10 Oct 88 17:00:07 cdt
Subject: Diffs to dvips
From: grunwald@m.cs.uiuc.edu (Dirk Grunwald)
The following context diffs to the version of `dvips' that I got from the
Univ. of Washington (june.cs.washington.edu) allow you to use `dvips'
on UltraScript printers. These differences are relative to the diffs
I posted a week ago to include ``psfig'' specials in dvips.
PostScript hacking courtesy of Gorden Skorstad.
Dirk Grunwald
Univ. of Illinois
grunwald@m.cs.uiuc.edu
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# download.diff
# structures.diff
# tex.lpro.diff
# This archive created: Mon Oct 10 16:57:11 1988
export PATH; PATH=/bin:$PATH
if test -f 'download.diff'
then
echo shar: will not over-write existing file "'download.diff'"
else
cat << \SHAR_EOF > 'download.diff'
*** /tmp/,RCSt1005859 Mon Oct 10 16:54:47 1988
--- download.c Mon Oct 10 14:28:04 1988
***************
*** 177,181
cc++ ;
}
}
}
}
--- 177,182 -----
cc++ ;
}
}
+ cmdout("dfend");
}
}
SHAR_EOF
fi # end of overwriting check
if test -f 'structures.diff'
then
echo shar: will not over-write existing file "'structures.diff'"
else
cat << \SHAR_EOF > 'structures.diff'
*** /tmp/,RCSt1006792 Mon Oct 10 16:55:20 1988
--- structures.h Mon Oct 10 16:48:49 1988
***************
*** 21,26
* Constants, used to expand or decrease the capacity of this program.
*/
#define STRINGSIZE (3141) /* maximum number of strings in program */
#define SWMEM (100000) /* font memory in smartwriter */
#define RASTERCHUNK (8192) /* size of chunk of raster */
#define MINCHUNK (256) /* minimum size char to get own raster */
--- 21,30 -----
* Constants, used to expand or decrease the capacity of this program.
*/
#define STRINGSIZE (3141) /* maximum number of strings in program */
+
+ #if defined(ScriptPrinter) || defined(UltraScript)
+ #define SWMEM (409776) /* font memory in ScriptPrinter */
+ #else
#define SWMEM (100000) /* font memory in smartwriter */
#endif
***************
*** 22,27
*/
#define STRINGSIZE (3141) /* maximum number of strings in program */
#define SWMEM (100000) /* font memory in smartwriter */
#define RASTERCHUNK (8192) /* size of chunk of raster */
#define MINCHUNK (256) /* minimum size char to get own raster */
#define MAXDRIFT (3) /* maximum drift in pixels */
--- 26,33 -----
#define SWMEM (409776) /* font memory in ScriptPrinter */
#else
#define SWMEM (100000) /* font memory in smartwriter */
+ #endif
+
#define RASTERCHUNK (8192) /* size of chunk of raster */
#define MINCHUNK (256) /* minimum size char to get own raster */
#define MAXDRIFT (3) /* maximum drift in pixels */
SHAR_EOF
fi # end of overwriting check
if test -f 'tex.lpro.diff'
then
echo shar: will not over-write existing file "'tex.lpro.diff'"
else
cat << \SHAR_EOF > 'tex.lpro.diff'
*** /tmp/,RCSt1006540 Mon Oct 10 16:55:02 1988
--- tex.lpro Mon Oct 10 16:50:47 1988
***************
*** 1,3
% a start (Ha!) at a TeX mode for PostScript.
% The following defines procedures assumed and used by program "dvi2ps"
% and must be downloaded or sent as a header file for all TeX jobs.
--- 1,4 -----
+ %!
% a start (Ha!) at a TeX mode for PostScript.
% The following defines procedures assumed and used by program "dvi2ps"
% and must be downloaded or sent as a header file for all TeX jobs.
***************
*** 100,106
/Encoding 128 array def
0 1 127 {Encoding exch /.undef put} for
end
! newname newname load definefont setfont
fontname { /foo setfont } % dummy macro to be filled in
2 array copy cvx def % have to allocate a new one
fontname load % now we change it
--- 101,110 -----
/Encoding 128 array def
0 1 127 {Encoding exch /.undef put} for
end
! % DON'T "DEFINEFONT" HERE!! DEFINED FONT DICTIONARIES
! % HAVE READ-ONLY ACCESS, THUS MAKING "dc"s JOB OF
! % BITMAP LOADING ILLEGAL. - G.Skorstad, 10/88
! % newname newname load definefont setfont
fontname { /foo setfont } % dummy macro to be filled in
2 array copy cvx def % have to allocate a new one
fontname load % now we change it
***************
*** 108,113
cvn cvx put % and stick it in
} def
% the following is the only character builder we need. it looks up the
% char data in the BitMaps array, and paints the character if possible.
% char data -- a bitmap descriptor -- is an array of length 6, of
--- 112,124 -----
cvn cvx put % and stick it in
} def
+ % End one font dictionary definition. This should
+ % be called after each "df" font bitmap block.
+ % - G.Skorstad, 10/88
+ /dfend
+ {newname newname load definefont setfont}
+ def
+
% the following is the only character builder we need. it looks up the
% char data in the BitMaps array, and paints the character if possible.
% char data -- a bitmap descriptor -- is an array of length 6, of
***************
*** 130,139
}if
restore
} def
! % in the following, the font-cacheing mechanism requires that
! % a name unique in the particular font be generated
!
! /dc % char-data ch dc - -- define a new character bitmap in current font
{ /ch-code exch def
% ++oystr 12-Feb-86++
dup 0 get
--- 141,151 -----
}if
restore
} def
!
! % in the following, the font-cacheing mechanism requires that
! % a name unique in the particular font be generated
! % char-data = the long array preceding each "dc" call.
! /dc
{ /ch-code exch def
dup 0 get % ++oystr 12-Feb-86++
length 2 lt
***************
*** 135,142
/dc % char-data ch dc - -- define a new character bitmap in current font
{ /ch-code exch def
! % ++oystr 12-Feb-86++
! dup 0 get
length 2 lt
{ pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
--- 147,153 -----
% char-data = the long array preceding each "dc" call.
/dc
{ /ch-code exch def
! dup 0 get % ++oystr 12-Feb-86++
length 2 lt
{ pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
***************
*** 138,144
% ++oystr 12-Feb-86++
dup 0 get
length 2 lt
! { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
% --oystr 12-Feb-86--
/ch-data exch def
--- 149,155 -----
{ /ch-code exch def
dup 0 get % ++oystr 12-Feb-86++
length 2 lt
! { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
/ch-data exch def % --oystr 12-Feb-86--
% PUT CHAR DATA INTO WORKING FONT DICTIONARY.
***************
*** 140,150
length 2 lt
{ pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
! % --oystr 12-Feb-86--
! /ch-data exch def
! currentfont /BitMaps get ch-code ch-data put
! currentfont /Encoding get ch-code
! dup ( ) cvs cvn % generate a unique name simply from the character code
put
} def
--- 151,163 -----
length 2 lt
{ pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null
if
! /ch-data exch def % --oystr 12-Feb-86--
! % PUT CHAR DATA INTO WORKING FONT DICTIONARY.
! % -G.Skorstad, 10/88
! newname load /BitMaps get ch-code ch-data put
! newname load /Encoding get ch-code
! dup ( ) cvs cvn % generate a unique name simply
! % from the character code
put
} def
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
------------------------------
Date: Mon, 10 Oct 88 16:13:53 PDT
From: lamport@src.dec.com (Leslie Lamport)
Subject: Re: TeXhax Digest V88 #88 (LaTeX notes)
Bernie Cosell writes:
It seems to me that what LaTeX should have is four families (roman,
sanserif, typewriter and smallcaps) and two style attributes (italic
and bold). The families should _switch_ leaving the prevailing style
alone; the styles should *stack* leaving the prevailing family and any
other styles alone. If I'm italic, and I enter a \bf region, I should
expect to now be in bold-italic.
Would this be crazy? Would it be an improvement? Would it be hard to do?
What he wants is quite reasonable, but impractical. The problem is that
this would involve a large number of fonts--roughly four times as
many as now used--most of which do not exist.
G.J. Stemerdink writes
I can't find in the LaTeX manual any reference to the rule that one
should not use numbers in command names.
Since the manual says in at least three places that a command name
consists of a `\' followed by either a single nonletter or a string of
letters, I can only conclude that Mr. Stemerdink is unaware that
"letter" refers to one of the 26 characters "a"-"z" and their uppercase
counterparts, and does not include the digits "0"-"9". I suppose this
type of misunderstanding is unavoidable when a manual is read by a
non-native speaker. However, I would have thought that lines 3-6
on page 16 were sufficiently unambiguous.
Leslie Lamport
------------------------------
From: ekrell@ulysses.att.com
Date: Mon, 10 Oct 88 19:58:22 EDT
Subject: Re: Bug in ctex.ch (web2c 2.2)?
That problem was fixed a long time ago. You have an old version of web2c.
------------------------------
Date: Mon, 10 Oct 88 17:18:46 pdt
From: rusty%garnet.Berkeley.EDU@violet.berkeley.edu
Subject: computer modern for aps typesetter
On score, there is a directory <tex.aps>. We have an aps typesetter.
How can I get these fonts into/onto our typesetter?
------------------------------
Date: Tue, 11 Oct 88 10:07:51 GMT
From: Wayne Sullivan <WSULIVAN%IRLEARN.BITNET@Forsythe.Stanford.EDU>
Subject: TP4 Version of TeX
Progress report on a version of TeX for MSDOS PC's using Turbo Pascal 4.0:
Test versions of this program are now being used locally and by some people
who offered to help with the work. The INITEX EXE file is about 195k, while
the TEX EXE is about 178k. On a 640k PC, this leaves about 75k 4 byte memory
words for mem and font_info, minus the memory used by resident utilities. In an
effort to match the speed of commercial programs, considerable use of inline
code has been made, so that there are probably numerous sneaky bugs remaining,
but the TRIP.LOG correesponds exactly to what it should except for memory
allocation, which has been slightly modified in the TP4 version.
The program will not be available for general release until the NEW TRIP test
has been checked, the output files for which are not yet to hand (hint to BB).
The idea is to make the TeX and INITEX exe files generally available gratis. It
is planned to make the documentation into a book, which would come with the
change file and the special version of TANGLE which breaks the Pascal file into
units suitable for TP4.
It is possible to be able to release the test version now because of very
considerable help from Peter Breitenlohner. Also Peter Sawatzki contributed
some useful ideas.
Wayne Sullivan
------------------------------
Date: Tue, 11 Oct 88 08:55:35 ADT
From: "Steven Osborne - Computer Science UNB" <OSBORNE%UNBMVS1.BITNET>
Subject: Laserprinter Query
Does anyone out there know the whereabouts of any 600 dpi Laserprinters?
I would like to know the manufacturer and the model number if you know
of any. Thanks.
Sincerely Yours
Steven Osborne
Hardware Systems Specialist
School of Computer Science
University of New Brunswick
P.O. Box 4400 Fredericton, NB
Canada E3B 5A3
<OSBORNE@UNB.CA> (Bitnet)
------------------------------
Date: Tue 11 Oct 88 07:55:54-PDT
From: Oren Patashnik <PATASHNIK@Score.Stanford.EDU>
Subject: Re: BibTeX sorting
> Subject: BibTeX Sorting
> From: Rodney Topor <munnari!munmurra.mu.oz.au!rwt@uunet.UU.NET>
> I have just started using BibTeX. With styles plain and abbrv, it
> seems to sort entries alphabetically by author. Entries for the same
> author seem to be sorted randomly. Is there any way to sort entries
> with the same author by year (without editing the bbl file)?
Yes. The old `plain' and `abbrv' styles (version 0.98) sorted by
author then title. The new versions sort by author, then year,
then title. So the answer is: Use the new versions (you'll need
the new version (0.99) of BibTeX, too). Ask your system's LaTeX
installer to get the new versions, and be sure that documentation
is included. (The "BibTeXing" document is the most important.)
> Similarly, with style alpha, entries are sorted by the generated label.
> This can separate entries for the same author, which looks wrong.
I agree that it's wrong, but it's even worse to not sort by label first.
Here's an argument from an earlier TeXhax message I sent:
This label-first alphabetizing scheme is best (for `alpha') for two
reasons. First, it's the label that a reader uses to find the
reference in the reference list, so the entries should be alphabetized
first by label. (Otherwise, for example, a reader might have to
search all the `A' entries to find [AB87] (if, for instance, the `AB'
comes from authors Fred Aza and Joe Bloe); this wouldn't be so hard
for a 7-entry reference list, but it would be quite annoying for a
50-page bibliography that has three pages of `A' listings.) And
second, if you have entries for [AB87a] and [AB87b], you'd like them
to appear together; but by the author-first scheme, they might be
separated (and perhaps by several pages) in the 50-page bibliography.
The problem you bring up is one of the reasons I prefer the `plain'
style to the `alpha' (or any other author-date) style. There are
other, more important reasons that I won't address here.
> Is there any way to sort entries by author and year with style alpha?
Yes, but without modifying `alpha' it's somewhat messy. If you really
don't want to sort label first, you should, instead, modify `alpha'
(it's a fairly easy change if you're familiar with the .BST language),
but be sure to call it something other than `alpha'.
--Oren Patashnik (BibTeX implementor)
------------------------------
Date: 11 Oct 88 17:00:59 EDT
From: "STEFANOS MANGANARIS" <SMANG%GRPATVX1.BITNET@Forsythe.Stanford.EDU>
Subject: Extending TeX's alphabet from 128 to 256 characters
Hello TeX friends !
Here in Greece we'd like to have a TeX system that can handle mixed greek
and latin text. Besides greek fonts (that we hope to build via MF) and the
problem of hyphenation in greek text (that we have almost solved), we
need a modified version of TeX that can handle easily not just 128 characters
but 256 instead. (We don't want to use the \char feature since we want to
keep TeX interactive, with HELPFUL error messages)
I can imagine that what we want implies major modifications not just in the
TeX program but also in others, like tangle and patgen. For example we have
to shift integers that represent strings from the pool up by 128, to make room
for the new characters...
Has anybody ever tried extending TeX's alphabet? Could you suggest any other
problems that have to be considered ?
I would very much apreciate any help!
Bye bye,
> Stefanos Manganaris BITNET: SMANG@GRPATVX1 <
> Computer Technology Institute UUCP: ...!mcvax!ermhs!stefanos <
> Patras Greece <
------------------------------
Date: Tue, 11 Oct 88 13:43:43 EDT
From: ajb%cornea.mitre.org@gateway.mitre.org
Subject: Full page bitmap of dvi file
In response to my question regarding how to produce a full page bitmap
image of a dvi file, I received several very useful responses. Thank
you to everyone who responded. Following are extracts from the responses.
Alan J Broder
ajb@mitre.arpa
Image Processing Technology Center
> From: "DOUG MCDONALD" <mcdonald@b.scs.uiuc.edu>
>
> Your job is essentially trivial. There are public domain programs
> that almost do that. The Nelson Beebe dvi drivers and my derivative,
> a screen driver, generate bitmaps in memory. A 300 dpi bitmap of
> a normal sized page is only 1 megabyte. You should look at my DVIVGA
> driver and Beebe's okidata printer driver (which has a serious bug
> in the actual drawing routine - use mine). Starting from mine,
> you must change the defines for size and then hack out the interactive
> user input and write out the bitmap - then put back in the input
> for which page you want. ftp my stuff from b.scs.uiuc.edu (but you
> need an IBM-PC to unpack it) (default anon ftp directory) and
> Beebe's from science.utah.edu directory aps:<tex.dvi>.
> Doug McDonald (mcdonald@uiucuxe or mcdonald@uxe.cso.uiuc.edu
> not the b.scs.uiuc.edu)
>
>
> From: Ken Yap <ken@cs.rochester.edu>
>
> Sure, no reason why not. A couple of Nelson Beebe's drivers generate
> bitmaps. However a back of the envelope calculation will show you that
> a 300 dpi page will take: 7.5x10x300x300/8 bits which is roughly 1 Mb
> per page. I hope you have a lot of free disk space for a document.
>
> Secondly why not do the antialiasing on a per-character basis? Save the
> pixmaps for each character. This should speed things up a lot for no
> loss in quality. One previewer I know of, dvipage, does grey scale
> bitmaps. I think it was posted to comp.sources.unix.
>
> Ken
>
>
> From: rcb@rti.rti.org (Randy Buckland)
>
> If you can't find exactly what you are looking for, you might
> want to take the code for my DVI previewer for VMS vaxstations and modify
> it. It generates a bitmap of the current page and then displays it on the
> screen. It can also generate for any resolution you have the fonts generated
> for. It would be relatively easy to remove the UIS display code and just
> dump the bitmap to a file or hand it off to your display device.
>
> It can be gotten by anonymous ftp from argon.rti.org [128.109.139.64]
>
>
> From: aslam@p.cs.uiuc.edu (Sohail Aslam)
>
> You may want to check out the Utah Raster kit. One of the filters is
> `dvi2rle'. Once in the RLE format, your can apply numerous other
> filters. Here is the blurb. ...
>
>
> From: spencer@crim.eecs.umich.edu (Spencer W. Thomas)
>
> I have a program (part of the Utah Raster Toolkit) that converts DVI
> output into RLE (the URT file format). The output resolution is any
> integer divisor of 300DPI (e.g., 300, 150, 100, 75, ...), with
> anti-aliasing at the lower resolutions.
>
> The URT is available from cs.utah.edu (in pub/toolkit-2.0.tar.Z, or
> pub/toolkit-2.0.tar.[123].Z) by anonymous FTP (be sure to select BINARY
> mode). If you get the [123] files, the third file just has test
> images in it.
>
------------------------------
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET:
%%% SUBSCRIBE TEX-L <your name> % to subscribe
%%%
%%% All others: send mail to
%%% texhax-request@score.stanford.edu
%%% please send a valid arpanet address!!
%%%
%%%
%%% All submissions to: texhax@score.stanford.edu
%%%
%%% Back issues available for FTPing as:
%%% machine: directory: filename:
%%% [SCORE.STANFORD.EDU]<TEX.TEXHAX>TEXHAXnn.yy
%%% nn = issue number
%%% yy = last two digits of current year
%%%\bye
%%%
------------------------------
End of TeXhax Digest
**************************
-------