1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
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.
|
