diff options
author | Karl Berry <karl@freefriends.org> | 2006-01-17 21:41:51 +0000 |
---|---|---|
committer | Karl Berry <karl@freefriends.org> | 2006-01-17 21:41:51 +0000 |
commit | 487ca4806cc046076293cf6cc5fbba0db282bac7 (patch) | |
tree | 847b412ab5158dd7bdd7ed7e5a4cc3fbca94be32 /Build/source/texk/dvipsk/vmcms/README.VMCMS | |
parent | a3d3111bfe26b8e5f5bc6049dfb2a4ca2edc7881 (diff) |
texk 1
git-svn-id: svn://tug.org/texlive/trunk@1485 c570f23f-e606-0410-a88d-b1316a301751
Diffstat (limited to 'Build/source/texk/dvipsk/vmcms/README.VMCMS')
-rw-r--r-- | Build/source/texk/dvipsk/vmcms/README.VMCMS | 168 |
1 files changed, 168 insertions, 0 deletions
diff --git a/Build/source/texk/dvipsk/vmcms/README.VMCMS b/Build/source/texk/dvipsk/vmcms/README.VMCMS new file mode 100644 index 00000000000..3312ddcc7a4 --- /dev/null +++ b/Build/source/texk/dvipsk/vmcms/README.VMCMS @@ -0,0 +1,168 @@ +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. |