iau@eagle.ukc.ac.uk (I.A.Utting) (03/02/88)
I have Version 1.1 (dated March 1987) of this very promising piece of software by Tyler Ivanco and Avy Moise, but it appears to have a number of problems. It seems to me that I remember talk of a later version, but I can find no trace of it. Does anyone have a copy I could get hold of? Please mail me first, so I can select one copy (we in the UK pay for incoming mail as well as outgoing). Ian Utting. iau@ukc.uucp or iau@ukc.ac.uk
mrd@sun.mcs.clarkson.edu (Michael R. DeCorte) (05/03/88)
I just downloaded dvist which was posted to comp.sources.atari.st Well... I can't get it to work. There are two programs dvistdl and dvistnd and I haven't the faintest idea what the differences are between the two (they aren't documented). When I try to run either one it says that /fonts/cmbx10/157pk can't be found. This is very reasonable as I don't have it, but I shouldn't have to have it. You see it should be loading cmbx10@magstep3 for 96dpi that translates to 166pk. For it to comeout as 157 you need to have ~91dpi fonts. As the old version of dvist (1.0-) processes the same file just fine, I am a little confused. Does anyone know how to fix this? What is wrong. Where I can get a copy that works? thankyou Views expressed here do not represent Clarkson University or any part of it. Michael DeCorte // (315)268-3704 // P.O. Box 652, Potsdam, NY 13676 Internet mrd@clutx.clarkson.edu // BIX DMichael Bitnet mrd@clutx.bitnet // Compuserve 72220,3724
tyler@stpl.UUCP (Tyler IVANCO) (05/04/88)
In article <865@sun.mcs.clarkson.edu> mrd@sun.mcs.clarkson.edu (Michael R. DeCorte) writes: > >I just downloaded dvist which was posted to comp.sources.atari.st > >Well... I can't get it to work. There are two programs dvistdl and >dvistnd and I haven't the faintest idea what the differences are >between the two (they aren't documented). Well, the two versions are very similar but one loads only those characters that are required, and the other loads the entire font set regardless of what is used (the dl = demand load). The server works well with the former, and the latter works best when the fonts are available on the ST. Time for a poor excuse for the poor documentation. A great many people have requested the new version of the program for the last while and we have been promising that it would be out "next week". Well "next week" had come and gone (more than a few times) and we felt that the functional differences between the versions were small enough to avoid a great deal of confusion and that the original file with a small addendum would be sufficient. I suspect that we were incorrect and I apologise for that but time is scarce right now. Besides, we felt that we provided the ultimate documentation -- the source! However, I thought that I described some of this as an addendum in the .dvi and the .tex file....Hmmmm I had better check the distribution again! > When I try to run either >one it says that /fonts/cmbx10/157pk can't be found. This is very >reasonable as I don't have it, but I shouldn't have to have it. You >see it should be loading cmbx10@magstep3 for 96dpi that translates to >166pk. For it to comeout as 157 you need to have ~91dpi fonts. As >the old version of dvist (1.0-) processes the same file just fine, I >am a little confused. Does anyone know how to fix this? What is >wrong. Where I can get a copy that works? Here again, a functional difference between the old version and this one pops out. In this version the system will search for the font file, in this case 157pk and if it can't find it, a search for a font +/- 10pk will be performed. The error message reports the last font name that it had attempted to open. However, this doesn't explain why it didn't find the file 157pk. I'll take a wild guess that the dvist.rc startup file does not contain the correct search path-list. BTW a help message can be obtained with the '?' key while running the previewer or with the -h option when invoked. Finally assuming that you have a good archive but that somehow the programs are corrupt, you can alway recompile them from the source (assuming that you have the Alcyon compiler). P.S. The email uucp address for both Avy and myself has changed as our connectivity has changed recently. Avy: ...mnetor!yunexus!yugas!avy Tyler ...mnetor!yunexus!stpl!tyler ...utzoo! ...utzoo! P.P.S. Avy and I plan to release the Atari Laser printer version soon. However we are having trouble with speed. Right now we are lucky if we can print out 2 ppm. Compare that to our HP laserjet version that can dump out the printers maximum rate (I believe it is 8ppm). We are also going to place a print preview into the screen preview program and will release the new atari.h when completed.
saj@chinet.UUCP (Stephen Jacobs) (05/05/88)
I'm also having trouble with dvist32. There is a real possibility that the distribution became corrupted on the way to me, although all the ascii text is readable and the programs load. dvistdl simply returns to the shell without showing anything, while dvistnd says its processing the file, types 'server' and locks up the machine. I'd like to recompile for insurance pur- poses, but I have Mark Williams C, and the stdio.h differences are pretty substantial. Sure I can guess that _fp should probably be changed to _ff, and suchlike. But just 1 bad guess and the result is garbage. Could someone post the description of the struct FILE in Alcyon C, and the values #define-d for IO_READ and IO_WRITE (if there's a legal problem, don't)? I'm really looking forward to being able to see TeX output the way it was meant to be.
tyler@stpl.UUCP (Tyler IVANCO) (05/07/88)
W.R.T. your dvist problems here are a couple of questions/hints.
1) Question. I presume that the arc program didn't croak in file extraction
which strongly implies that the distribution arrived OK.
2) Check the dvist.rc file and insure that the default search path is
correct. Don't try to implement the server at this point.
3) Install the fonts into \font subdirectory as per the instructions.
Basically create a subdirectory for each root font type and
then rename the corresponding font file as the size with
pk appended to it. e.g. cmr10.96 would be placed into the
subdirectory \font\cmr10 as the file 96pk. Now try to preview the
dvist.dvi file with the command:
dvist -f\font dvist
This command assumes that you are running under something like
gulam or gemcsh. If not, insure that the program have been renamed
to a .ttp file so that you can provide command arguments. If this
works, then the programs are ok. If not, send email to me and I'll
look into it a bit further.
4) Recompilation? I would try to disable the CLIENT protocol by undefing
the CLIENT flag (I believe set in system.h). Thus you should not have
to play with stdio etc.
Avy and I are always open to help others with our mistakes and
of course to suggestions. Please feel free to email or phone us.
...mnetor!yunexus!stpl!tyler or ...mnetor!yunexus!yugas!avy
fs300022@yusol.bitnet
Ph (416) 736-2100 x7765 (416) 736-5359gordan@maccs.UUCP (gordan) (05/09/88)
In article <5101@chinet.UUCP> saj@chinet.UUCP (Stephen Jacobs) writes:
-
-I'm also having trouble with dvist32. There is a real possibility that the
-distribution became corrupted on the way to me, although all the ascii text
-is readable and the programs load. dvistdl simply returns to the shell
-without showing anything, while dvistnd says its processing the file, types
-'server' and locks up the machine.
I had the same problem. Check the DVIST.RC file -- as distributed, it
specifies a path of D:\FONTS for the font files. If you don't have a D:
disk, this simply hangs forever with no error message. Simple to fix:
just change DVIST.RC to contain A:\FONTS (or whereever you happen to
have installed them).
Also, don't forget to set up subdirectories properly for the font files,
e.g.
FOOBAR.96 -> \FONTS\FOOBAR.96PK
By the way, DVIST _is_ usable on a color monitor if you use a monochrome
emulator (e.g. MONOWARE.PRG, which came over the net a while ago). Best
to use a speed of 10 with MONOWARE (slowest screen refreshes, but least
amount of CPU cycle stealing).
--
Gordan Palameta
uunet!mnetor!maccs!gordan