NeXTSTEP 3.3.4.17 [SPARC, PA-RISC]/nextstep33_risc.iso/NextLibrary/TeX/tex/src/dvips/vmcms/README.VMCMS

Text File | 1992-11-14 | 7.6 KB | 165 lines

README.VMCMS:  Remarks and history of the VM/CMS port of DVIPS.

Appropos DVIPS version 5.495.

Written by Jim Hafner ([e-mail]).
Last revised 10 Nov. 1992.

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 Gugliemli
   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 dvi.   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 Gugliemli
([e-mail]) and Marco Prevedelli
([e-mail]) with help from via Michel Goossens
([e-mail]) and Ronald Kappert ([e-mail])