Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!wilker
From: wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.)
Newsgroups: comp.text
Subject: Re: Suggestion for Improving Beebe's DVI Driver Package
Summary: Other problems with Beebe Drivers and
	 Turbo C
Message-ID: <7036@batcomputer.tn.cornell.edu>
Date: 20 Dec 88 20:34:01 GMT
References: <1519@helios.ee.lbl.gov>
Organization: Theory Center, Cornell U., Ithaca NY
Lines: 31


I am a fan of the Beebe drivers, but have to admit that I
stripped out the stuff irrelevant to my interests. I had
the following problems with Turbo C and the Beebe drivers:
They compiled fine with 1.5 and 2.0 but would not run
without crashing. Here most of my experience is with
DVIJEP.C. I tracked down to problems to about 4 areas
1) One routine, related to skipping specials in .pk format
   font files looked for a magic byte to find the end of
   the file. There was an off by one error somewhere so that
   the ungetc used always returned EOF, which got reported as
   a bad byte in the .pk file.

   2) The floating point constants in the table to compute
   magnifications are written with lots of precision, which
   Turbo C swallowed, except that both Turbo C 1.5 and 2.0
   will report 1.5000000000000000 ( lots of trailing zeros')

   as 1.25, whereas 1.50 is scanned correctly.

   3) Finally, one of the rountines (PRNTPAGE??)
   has lots of local data and eats up the stack space
   I ended up setting the stack to 12000 bytes instead
   of the default 2048. It did not seem sufficient to
   put "_stklen=12000;". I had to redefine MINSTACK
   in C0.ASM and remake C0C.OBJ.
   4) The font caching defines had to be redone for
   Turbo C versus MSC, but afterwards, seemed to make
   little difference anyway.

   Clarence Wilkerson (wilker@msb.cc.rochester.edu)