README.VMCMS: Remarks and history of the VM/CMS port of DVIPS. Appropos DVIPS version 5.495, 5.55. Written by Jim Hafner (hafner@almaden.ibm.com). Last revised 10 Nov. 1992. Version 5.55 checked and slightly modified on 2 May 1994. NOTE: This port was not done by Tom Rokicki and he has no responsibility for it. You can direct questions to the name and address above. The current set of changes and enhancements to the VM/CMS port over the previous release should be fairly complete. Lots of things have changed and been enhanced. Here are some of the features of the port and VM/CMS package: 1) We have completely revised the MKDVIPS EXEC so that it behaves a bit more like the Unix 'make' facility. In particular, it now allows for command line options to do any or all of the package building for the DVIPS program, the AFM2TFM program, the HEADERS files and to clean up the TEXT and LOAD MAP files after completion. This has only been tested with C/370, not, in particular with Waterloo C. Furthermore, it also does a rudimentary time stamp check of existing TEXT files against that for the corresponding C file and ALL H files so that the compiler will not be called unless it seems necessary. Note that it checks ALL H files in all ACCESSED disks. This can be fixed by simply editing the MKDVIPS EXEC. See the file itself for more detailed information. 2) We have completed the port of AFM2TFM. If should now produce identical files on VM/CMS as on Unix (it certainly does as far as we could test it). There is a small front-end EXEC included that sets up the necessary run-time environment. The current version is extensively revised from the original port due to Alessio Guglielmi and Marco Prevedelli of Pisa. The syntax for the EXEC is the same as described in the DVIPS manual and the manpage is available as AFM2TFM.DOC. 3) The DVIPS front-end EXEC has been extensively remodeled. It now supports automatic font generation at the EXEC level (and the MODULE level with the appropriate command line options). More on this feature later. The EXEC assumes that the first command line argument is the dvifilename. The online documentation indicates this as well, though DVIPS.DOC does not. This is NOT required by the MODULE, just the EXEC, and only to make parsing the arguments easier. The current version of this exec handles the LOADLIB and TXTLIB save/reset/restore processes much better, so users with very large libraries accessed will not have them lost along the way. This version does not access any font disks since that is surely site dependent. So, it assumes that the required fonts are available. It also assumes that MF is somewhere to be found. Local installers might want to modify this exec in the following way. Parse the command line options for a -P PRINTER specification. If found, then either use PRINTER to determine which font disk to access OR read the corresponding CONFIG.PRINTER file and use the 'M' option to get the Metafont mode for that PRINTER. Then use that mfmode to access the right font disk. 4) AUTOMATIC FONT GENERATION: This can be handled in two ways, at the installers or users discretion. First, we have included a MakeTeXP EXEC which we think is pretty generic and should need little modifications. (See below for a few additional comments.) This MakeTeXP EXEC can be called in two different ways. The default (based on DVIPS EXEC) is to have DVIPS run completely and create a MISSFONT LOG file for any missing fonts. If there are any found, then the DVIPS EXEC prompts the user, asking to attempt to generate the fonts. If requested, then MakeTeXP EXEC is called by processing each line of MISSFONT LOG. If this process completes, then the user is again prompted. This time, the user can specify an exit from the EXEC or to RE-invoke DVIPS (the module not the exec) on the file. In this way, all the font generation can be handled entirely OUTSIDE of the module, using no special system calls (which have been known to cause memory clashes). To make sure that DVIPS doesn't try to make the system call, a '-M' flag is prepended to the options list. Consequently, if the installer is sure that system calls will be safe, then this option can be removed. Conversely, if a user wants to risk it, putting '-M0' in the command line options will override this default. We mention explicitly that, contrary to the earlier VM/CMS port, we have NOT disabled the system call within DVIPS itself. 5) MakeTeXP EXEC: This exec is similar to the Unix version in that if no Metafont mode is specified on the command line, then it tries to 'guess' a mode from the base dpi. This part of the exec is very site dependent and will need to be modified for your location. You might want to modify this exec to read some configuration file like CONFIG.MODES or DVIPS.MODES and use this to set the mfmode from the base dpi. Furthermore, we have written this to not invoke MF EXEC but to call MF MODULE directly. We hope that this will be more generic since we structure the parameters as MF MODULE wants them and not as some fancy execs might. We have set up a special default for passing arguments to the module. Namely, &plain modes; \mode=mfmode; ... where 'modes' is the name of your local .MF file that contains the mode definitions. Because of this, each output file of MF will have a filename of MODES. Later in the exec, these output files are renamed with the font input filename. If you have a mode def file of a different name, you will need to change the defining variable (localModeFile) accordingly. If you don't have such a file, then you will probably have to modify this EXEC somewhat to compensate. All (we hope) site dependent parts of the code are tagged boldly with 'SITE DEPENDENCIES'. Look at these locations for places that might require modifications. 5) As before, the .dvipsrc file referred to in the manuals has the new name DVIPS.PROFILE on VM/CMS. 6) Online documentation is available by invoking DVIPS with no arguments or filename. You can also browse the file dvips.doc for some additional comments (this was converted from the Unix manpage via, on Unix, "nroff -man dvips.1 | col -b > vmcms/dvips.doc" and so some comments may not be appropriate for VM/CMS, e.g., the order of the filename in the command line arguments. 8) Since there are no pipes on VM/CMS, the option -f is meaningless. Also, the output is always written to a file, with the same filename as the dvi file and filetype "PS". You can always override this with the -o option. 9) Since there are no PATHs in VM/CMS, the H, P, S and T configuration file options are meaningless. The DVIPS.EXEC file should make sure that all the necessary disks are linked (we have all .tfm, .pro, config. and other files on our main TeX disk, with the EXECs and MODULES -- only our fonts (the pk files) are on separate disks.) To compile the programs, run the program MKDVIPS.EXEC program. Be sure you edit this file first to make sure that your C/370 programs disks and libraries are all correctly link. See the comments at the beginning of that file for more information. When complete, all the necessary modules and files should be built, on your primary write-accessed disk. You may need to move them to their destination manually. THANKS: Some of this port was provided courtesy of Alessio Guglielmi (guglielm@di.unipi.it) and Marco Prevedelli (prevedelli@ipisnsva.bitnet) with help from via Michel Goossens (goossens@cernvm.bitnet) and Ronald Kappert (R.Kappert@uci.kun.nl). Acknowledgements to Shashi Sathaye for fix to 5.55 and other helpful hints for the original port of 5.495.