summaryrefslogtreecommitdiff
path: root/Build/source/texk/dvipsk/vmcms/README.VMCMS
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/texk/dvipsk/vmcms/README.VMCMS')
-rw-r--r--Build/source/texk/dvipsk/vmcms/README.VMCMS168
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.