hedrick@athos.rutgers.edu (Charles Hedrick) (09/10/89)
I have just started playing with TeX on a PC myself. I also FTP'ed
all the stuff from Simtel. I was unable to get DosTeX to survive even
a simple \begin{verbatim} in latex. Probably you can get DosTeX to
work if you modify lfonts.tex so that it doesn't load as many fonts.
Also, it seems to have slightly more memory if you load lplain into
tex each time, rather than using the dumped latex.exe. But I
recommend a different approach.
In the same Simtel directory, you'll find a file sbtex.arc. It
contains a different version of TeX for the PC. It is smaller and
noticably faster than DosTeX. You can use sbtex with the macro files
that come in the DosTeX .arc files. All you really need to replace
is the pool file and tex itself. Also, I don't see any obvious way to
produced dumped .exe files such as latex.exe in sbtex. However doing
initex lplain \dump
will give you lplain.fmt. You can then invoke latex as
tex &lplain
The process of reading in the .fmt file is fairly fast. (Indeed on my
system starting sbtex and reading lplain.fmt is faster than starting
the DosTeX version of latex.exe. However this may due to something
that you won't see: my DOS is running under System V, and my file
system is badly fragemented.) I've run substantial LaTeX stuff
through it without running out of memory.
One other difference: DosTeX will read files whose lines are
terminated by LF only, as in Unix. (Of course it will also handle
CRLF.) sbtex requires lines to be terminated by CRLF, as in DOS.
One other comment about the stuff on Simtel: There is a previewer
called dvivga. If you don't have a VGA, you may have decided not to
bother looking at it. In fact it works on VGA, EGA, or MCGA. I am
using it with an EGA on a 10MHz AT clone (Leading Edge D2). It is
acceptably fast, though no speed demon. Make sure you use the arrow
keys for moving around on the screen, not the letter commands "u" and
"d". The arrow keys are much faster.
There is a dvi2herc for Hercules. So about the only monitor that
there didn't seem to be a driver for was CGA.
Unfortunately, things aren't as good with printer output. There's a
dvieps for the Epson, and as far as I can tell it works. However it
produces enormous output files, and it is incredibly slow. It may be
that with a floating point chip things would be better. There is no
option to get it to write directly to the printer, which would avoid
needing a huge disk for the intermediate file.
I have ported dvidoc to the PC. dvidoc is a combination of a special
LaTeX style option and a post-processor. It can be used to produce
straight ASCII files intended for reading on dumb terminals or
printing on conventional terminals. It seems to work OK as long as
you don't try using math mode or graphics, as you'd expect. Things
look much better if you insert
\parskip 12pt
somewhere in dvidoc.sty. I'm still working on fixing up a couple of
details, such as itemize (where the bullets print as ?) and tables of
contents (where the dots print as colons).
Anyway, you won't be able to use my port of dvidoc directly. I'm
running it under Unix. But it doesn't use any fancy Unix facilities,
so the code would probably compile nearly without change on a DOS C
compiler. What I have done is changed "int" to "long" in the right
places for a 16 bit compiler, and made it run acceptably fast. I also
fixed a bug in the C version (apparently most people use the Pascal
version) that caused it to get file names wrong.
It turns out that dvidoc -- like every other dvi processor I've seen
-- uses floating point in a number of places where it doesn't need to.
If your PC doesn't have a floating point chip, this can really slow
things down. They use it in converting from "dvi units", which are
fairly large integers, to "pixels", which in the case of dvidoc are
simply character positions on the line. This conversion is done by
using code like Round(horizconv * x), wherre horizconv is the
conversion factor from dvi units to pixels. horizconv is actually a
number on the order of 1e-6. What I did was to define two new
integers, horizdiv and horizdiv2:
horizdiv = Round((double)1.0 / horizconv);
horizdiv2 = horizdiv / 2;
Then the conversion of x becomes (x + horizdiv2) / horizdiv. The
addition of horizdiv2 does the rounding. This speeds up the program
by about an order of magnitude. I do something analogous for
vertconv, of course. I've never seen quite as much speedup from so
little investment of time.
It looks like dvivga uses floating point as well. It would be
interesting to see whether a similar speedup could be done to it.
However with the vga, character widths are somewhat larger, so the
simple strategy I used may not give enough accuracy. It might be
necessary to do some scaling.beihl@sunspot.cad.mcc.com (Gary Beihl) (09/11/89)
In article <Sep.9.17.01.54.1989.9080@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >Unfortunately, things aren't as good with printer output. There's a >dvieps for the Epson, and as far as I can tell it works. However it >produces enormous output files, and it is incredibly slow. It may be >that with a floating point chip things would be better. There is no It's worse than that. Unless someone has uploaded a newer version of dvieps to Simtel20, the version that is out there contains a rather nasty bug (besides producing enormous output files and being incredibly slow :-) which bites whenever text lies partially in the first output strip and partially in the second. (The output bitmap is divided into two strips in this version). Typical symptoms consists of a hung machine. Do yourself a favor and don't use this version. If you don't want to register and receive the current, supported and correct version of the package, get a copy from Jon Radel (jonradel@icecream.Princeton.EDU) who maintains up-to-date versions. -Gary Beihl (beihl@mcc.com)