8-Dec-89 11:05:34-MST,13350;000000000001 Date: Fri 8 Dec 89 11:05:34-MST From: "Nelson H.F. Beebe" Subject: DVI driver family newsletter #20 To: "DVI mailing list": ; cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12548506613.20.BEEBE@SCIENCE.utah.edu> DVI Driver Family Update #20 [06-Dec-89] ============ INTRODUCTION ============ There has not been a DVI newsletter since #19 [23-Nov-88], over a year ago. During periods of that time, I've been working on a completely new version, to be numbered 3.0. In late May of this year, I presented a paper entitled ``TeX and Graphics--The State of the Problem'' at the GUTenberg 89 conference in Paris. It is in English, and available in Cahiers GUTenberg No. 2, May 1989. The preparation of that paper gave me an opportunity to address what I feel is an important problem for the future of TeX, and ideas generated from it are making their way into the DVI 3.0 development. Our Center suffered severe budget cuts this past spring that resulted in the loss of 2 of our 5 staff members, and we went over 5 months without an active systems manager, which necessitated my taking over much of that job. In Salt Lake City, we are in the planning stages for the replacement next year of our venerable, and much loved, DEC-20/60 (soon to be 12 years old), and for mapping out the future of our Center for Scientific Computing. That work occupied much of the summer. At the same time, I also organized the funding and purchase of a high-performance graphics system for the Department of Mathematics for which I did most of the work (funding requests, bid specifications, performance evaluation, bid evaluation, and final selection). We finally chose an Ardent Titan 2; it is named graphics.utah.edu, and has been running about a month now. There has therefore been much less time than I would have like to have for software development. Besides the above-mentioned activities, I have assumed a new outside job---President of the TeX User's Group for 1990--1991, a post to which I was elected in August at the Tenth Anniversary TUG meeting in Stanford. =================== DVI 3.0 DEVELOPMENT =================== The DVI 3.0 work is not complete, and I cannot predict when it will be done, so PLEASE DON'T ASK ME (I feel rather the same way that Don Knuth feels about Volume 4 of the Art of Computer Programming). Until I declare it complete, no DVI 3.0 sources will be released to anyone, anywhere, under any circumstances. I estimate that there are now over 3000 sites around the world (in at least 25 countries) running these drivers, and I simply cannot manage the development if I have to keep merging in contributed changes and drivers based on versions I now longer have. Regrettably, disk space is in such short supply here that it has been out of the question to squirrel away a 10MB copy of the current development directories at each minor version (I'm now at 3.0.064). Merging changes based on earlier versions would take more time than I have (and I never have enough time to do all that I'd like to do). Outside availability of source code before it is complete would result in the spawning of a multitude of incompatible versions that would utterly defeat the goal I'm trying to achieve---a consistent portable FAMILY of code which is derived from a common base (like TeX and Metafont) that is stable and reliable. As long as I have exclusive control of the source, I can (and do) make sweeping editorial changes to the code, sometimes daily. The 3.0 redesign effort addresses all of the problems and objections that have been raised against the 2.10 family (the last one available to the public), as well as extending support to more operating systems, more compilers, and to many more output devices. In addition, the code has been rewritten for an ANSI C environment, and I've provided missing pieces for those systems that are not yet at ANSI level (notably UNIX, except for the fine GNU C compiler, gcc). On most systems (with the exception of the deficient Prime Primos and IBM CMS C implementations), it is possible to compile the code without making any source modifications whatever (no more editing machdefs.h---that confused several users). I won't say much more about this work now; a document, dvistatus.ltx, is available on science.utah.edu for Internet anonymous ftp retrieval, together with output files for several devices. It describes the state of the development as of 1-Jul-89, and I expect to update it before Christmas. For those without Internet access, there is hope in sight; one of my goals as TUG President is to enhance network access of TeXware, and I expect software to be in place shortly that will facilitate retrieval of software from our local systems in response to e-mail requests. One last point before moving on to other things. The DVI 3.0 family code by the beginning of November had reached 33 drivers, 45K lines of C code, and 400+ pages of documentation. To put that into perspective, TeX and Metafont are each about 20K lines of C code. In mid-November, I began a job for which the coding is now complete, and testing has begun. That is to replace the 16 dot-matrix printer drivers by a single new driver, dvidot, that in one program does more than any of the older drivers did. No longer is it necessary to prepare separately-compiled versions for high and low resolution output; dvidot supports 36 combinations of output device and resolutions, including several that were previously unavailable. The total number of drivers to maintain has thereby been halved, the total code has been reduced by more than 3000 lines, the new driver will make it much easier to add support for additional dot-matrix printers, and to top it off, the output is 10%--20% shorter (and likely, faster printing) than that of the old drivers. ============ TeX ARCHIVES ============ As some of you may be aware, possibly the greatest DEC-20 of them all, score.stanford.edu, was retired in August of this year, leaving the TeX community without a home for a master archive of TeXware. For the time being, labrea.stanford.edu, a VAX 750 (almost as old as the DEC-20/60, and about 3 times slower) is holding the archives; the TUG board is evaluating alternatives for the longer term. When that issue has been settled, I expect to have automated network electronic mail retrievals established for it as well. This brings us to the next section, which may provide an interim solution for some of you. ================================= INTERNET TO BITNET FILE RETRIEVAL ================================= The following letter arrived in my mail box today, informing me of a mechanism for automated retrieval of files accessible via Internet ANONYMOUS FTP to Bitnet sites. I was unaware of this service, and I think it is important enough to be a major portion of this newsletter. This still does not help people who have neither direct Bitnet nor Internet connections, but the plans noted above should soon provide a solution for them as well. >> From: Princeton BITNET FTP Server >> Subject: BITFTP HELP >> >> > HELP >> BITFTP -- Princeton BITNET FTP Server >> >> BITFTP provides a mail interface to the FTP portion >> of the IBM TCP/IP product ("FAL") running on the >> Princeton VM system, to allow BITNET/NetNorth/EARN users >> to ftp files from sites on the Internet. >> >> BITFTP currently accepts requests only via RFC822-format >> mail, IBM NOTE-format mail, PROFS-format messages, or >> files with no headers at all. BITFTP currently returns >> the requested files only as NETDATA-format files. >> >> BITFTP currently cannot send binary files through mail-only >> gateways, such as the gateway from BITNET into JANET. >> >> If BITFTP sends you a file you cannot read, THE FIRST THING >> TO DO is to make sure that you specified ASCII if the file >> should contain textual material or that you specified BINARY >> if the file should contain binary data, executable programs, >> tar files, or the like. VMS users should specify BINARY F 512 >> and should use RECEIVE/BINARY to receive the binary files BITFTP >> sends them. >> >> To use BITFTP, send mail containing your ftp commands to >> "BITFTP@PUCC". The first command to BITFTP must be "FTP" >> or "HELP". >> >> The recommended syntax for ftp requests is: >> >> FTP hostname >> USER username password >> >> >> (If the username is "anonymous", no password is required; >> BITFTP will use your userid and nodeid as the password.) >> >> Note that on many systems passwords are case-sensitive; >> that is, the password may be required to be in lower case >> or mixed case or upper case. (The same is true of directory >> and file names.) >> >> The following is an example of an ftp request: >> >> FTP plains.nodak.edu >> USER anonymous >> CD /pub/pictures >> BINARY >> GET coke.bottle.Z COKE.BOTTLE >> QUIT >> >> BITFTP implements a subset of the ftp subcommands provided >> in the IBM TCP/IP and uses the same syntax. Therefore, you >> may find it useful to obtain the "IBM TCP/IP for VM Command >> Reference Manual", IBM order number GC09-1204. >> >> The currently supported subcommands are: >> >> ACCT -- to send host-dependent account information. >> format: ACCT account-information >> >> ASCII -- to change the file transfer type to ASCII. >> format: ASCII >> >> BINARY -- to change the file transfer type to image. >> format: BINARY >> >> CD -- to change the working directory. >> format: CD directory >> >> CLOSE -- to disconnect from the foreign host. >> format: CLOSE >> >> DIR -- to get a list of directory entries. >> format: DIR >> >> EBCDIC -- to change the file transfer type to EBCDIC >> format: EBCDIC >> >> GET -- to get a file from the foreign host. >> format: GET foreignfile >> >> If you specify "localfile", it must be in >> the forms "filename.filetype" or "filename", >> and the filename and filetype may each be no >> more than 8 characters long and may not contain >> periods. >> >> LOCSTAT -- to display local status information. >> format: LOCSTAT >> >> LS -- to list the files in a directory. >> format: LS >> >> PWD -- to print the working directory. >> format: PWD >> >> QUIT -- to disconnect from the foreign host. >> format: QUIT >> >> STATUS -- to retrieve status information from a foreign host. >> format: STATUS >> >> SYSTEM -- to get the name of the foreign host's operating system. >> format: SYSTEM >> >> TYPE -- to specify Image, ASCII, or EBCDIC file transfer. >> format: TYPE >> >> The files you request will be sent to you in NETDATA format. >> You will also receive a mail file containing a log of your >> ftp session. In that mail file, entries prefixed by ">" are >> your original commands; those prefixed by ">>" are your >> commands as interpreted by BITFTP and passed to TCPIP; those >> prefixed by ">>>" are your commands as interpreted by TCPIP and >> passed to the remote host; those prefixed by "<<<" are messages >> from the remote host; and those prefixed by ">>>>" are completion >> messages from BITFTP. >> >> If BITFTP is unable to connect to the host you specify, >> it will send you mail after the first attempt, but will keep >> trying at intervals over three days. The only additional mail >> files you will receive will be when the connection is made >> successfully or when BITFTP gives up after three days. >> >> The load on BITFTP is often very heavy and the network >> backlogs are often so great that it may take several days >> for a file to get to you once BITFTP sends it, so please be >> patient and don't send multiple requests for the same file. >> If your system allows you to send interactive messages, you >> can inquire about BITFTP's backlog by sending the query >> "How are you?", e.g., on a VM system: >> >> TELL BITFTP AT PUCC How are you? >> >> >> This service is currently under development and is far from >> complete. Current plans for improvements include: >> >> 1. Acknowledgments via MSG when mail is received and when >> processing has been completed. >> >> 2. A much more complete HELP facility. >> >> Questions about BITFTP and suggestions for improvements >> should be directed to Melinda Varian, MAINT@PUCC on BITNET. >> >> The author gratefully acknowledges the use of the FTP >> SUBCOM interface written by David Nessl (DAVID@NERVM) and >> of the RFC822 parsing routine written by Eric Thomas >> (ERIC@LEPICS). ==============================THE END============================= -------