summaryrefslogtreecommitdiff
path: root/info/digests/texhax/93/texhax.14
blob: ffbc20046a3f07a8316e4e924f85568e56bb090d (plain)
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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
TeXhax Digest    Monday,  4 Oct 1993  Volume 93 : Issue 014

%  The TeXhax Digest is brought to you as a service of the TeX Users Group  %
%    and UK TeX Users Group in cooperation with the UK TeX Archive group    %

Today's Topics:
                   Re: DVI to (Acrobat) PDF driver
             Re: A raw encoding file for type1 text fonts
                 ASCII Typesetting from a LaTeX file
                      TeX, LaTeX, etc. on IBM PC
           On why LaTeX uses save stack while reading .aux
                       Tex Installation on Vax
                            babel release
                        modes.mf 1.0 available
                  xdvik 1.2, dvipsk 5.519a available

Administrivia:
    Moderators:    David Osborne and Peter Abbott
    Contributions: TeXhax@tex.ac.uk
    Administration, subscription and unsubscription requests:
                   TeXhax-request@tex.ac.uk

----------------------------------------------------------------------

Date:    Sat, 11 Sep 1993 08:48:21 -0400
From:    bkph@ai.mit.edu (Berthold K.P. Horn)
Subject: Re: DVI to (Acrobat) PDF driver

> Is anyone working on a DVI to PDF driver for DOS, Unix or OS/2?
  
Yes, just use DVIWindo.  Aside from being a previewer, it will print to
anything that has a Windows Printer driver, including the PDF driver.

> PDF is the Portable Document Format, the Adobe Acrobat file format,
> based on the PostScript imaging model, that is capable of representing
> any PostScript page.
  
> If we could get our TeX documents in PDF format, then we could use
> one of the Acrobat viewers, like Acrobat Reader or Acrobat Exchange,
> to preview our documents with all the benefits of the Acrobat technology
> (e.g. font metric emulation, zooming, panning, searching, post-it-like
> annotations, etc). With Adobe Exchange, we could print PDF documents
> on PostScript AND EVEN on non-PostScript printers.
  
Which is all very well if you are using plain text fonts.  With TeX you
may find this approach somewhat problematic unless the recipients also
has all of the fonts called for in ATM compatible Adobe Type 1 format.
This is because (i) you need specialized math fonts for TeX, and 
(ii) the encoding of fonts used with TeX is usually non standard.

> This, of course, assumes that Adobe Acrobat is going to take off,
> which I believe it will, and that the Adobe Acrobat products are ...

Well, as long as it only exists on one platform (Mac) it won't do
much for inter-platform interchange.  It does exist for Windows also
now, but without Super ATM for Windows is somewhat limited.  It also
needs an Adobe Windows Printer Driver for Windows to be really useful.

> I would really like to hear your thoughts on the merits of a DVI2PDF driver.

Well, you can try one now and see whether you like it!

Just keep in mind that part of what Acrobat is supposed to do is solve a
problem to which we already have a solution when we use TeX, namely document
portability.  You can move DVI files (or even TeX source) files between
many platforms and be able to preview and print them.  

Regards, Berthold.

P.S. I have connections with Y&Y, the source for DVIWindo, DVIPSONE and fonts.

------------------------------

Date:    Sat, 11 Sep 1993 08:53:29 -0400
From:    bkph@ai.mit.edu (Berthold K.P. Horn)
Subject: Re: A raw encoding file for type1 text fonts

> Over the course of a rich discussion of virtual fonts, I have
> finally come to understand and appreciate the full usefulness
> of Tom Rokicki's careful distinction between input encoding
> and output encoding in afm2tfm.  In a virtual font environment
> it answers several questions that have recently been raised about
> the proper encoding of a {\em raw} tfm file.  The raw tfm
> should contain references to every simple (non-composite)
> character in the actual list of glyphs, and it need not contain
> anything else.  

I know this will start a flame war, but...

The combination of (i) input encoding, (ii) output encoding, plus
(iii) virtual font permutation of numeric codes between 0 - 255 is
unneccessarily complex and confusing.  A much simpler approach
just uses the idea of the encoding vector per se.  That is,
a mapping from numeric codes (0 - 255) to glyph names.  
DVI processors need the capability to reencode a font on the fly
anyway, and the encoding vector provides the mechanism.  
Obviously, ONE mapping instead of THREE mappings in series is much 
easier to understand and implement, and is in fact all that is needed.

To be concrete, an encoding can be specified in a file 
containing lines like the following:

        32      space
        65      A

etc. (or whatever equivalent way you want to use to define the 
encoding). Such a file can be read by DVI file processors, as well as
programs that produce metric files in various formats, including
TFM for TeX, PFM for Windows, screen fonts for Mac etc.  Nothing
could be simpler!

While I am at it, it is also not necessary to force users to resort
to virtual fonts just because they want a different font layout,
or because they are using TrueType or Type 1 fonts!  It IS possible
to make TFM files complete with proper ligature and kerning information,
WITHOUT virtual fonts.  And it certainly is a lot less confusing.

Virtual fonts have many interesting applications, but they are NOT needed
for reencoding, and in fact, in and of themselves are quite inadequate for 
reencoding.  The reason is that virtual fonts per se can only provide a
PERMUTATION of the encoding vector, since they ONLY deal with numeric
codes --- because VF, like TeX itself treat characters as numbers.
Hence unencoded characters CANNOT be made accessible by the VF mechanism
itself.  Which is why all DVI drivers need in ADDITION a mechanism for
actually reencoding a font.  And once you have THAT, you do not need
to use the numeric permutation of the VF to achieve reencoding!

It is easy to be mislead by one particular implementation, which 
(i) forces one to use VF whenever using anything but bitmapped CM fonts, 
and which (ii) forces use of a complex sequence of three mappings rather than
simply the single overall encoding, and (iii) cannot create TFM files
complete with ligatures and kerning WITHOUT resorting to VF.

Nothing could be more intuitive than the idea of the `encoding vector'

Now for some minor details:

> ...all the unmapped characters.  Fortunately, the list of
> unmapped characters is almost as consistent as Adobe Standard
> Encoding at least in text fonts.  I propose therefore...

The set of available glyphs is only consistent amongst Adobe fonts 
(which uses the same basic set of 228 glyphs for most text fonts).  
Other vendors implement other sets of glyphs.  Lucida Bright text fonts for
example have many additional glyphs not found in Adobe text fonts (for a
total of 247).  An approach based on a fixed `input encoding' that may
not cover these extra characters is obviously inferior to one using a
single encoding vector.  It also cannot cope with the case where there
are more than 256 glyphs in a font (Lucida Sans Linedraw has 400).

> There remains the question of what to do about the various
> Superfont layouts: Courier in its most prolific version has
> 352 simple characters and the Monotype TimesNewRomanSF Superfont
> has 337 simple characters.  In the case of TimesNewRoman, the
> excess is the result of combining the regular with the expert

There are many fonts that have more than 256 characters, including some
of the Lucida family (Lucida UNICODE has over a thousand).  You cannot
deal with all of these using a fixed `input encoding'.  If, however, you
drop the idea of THREE sequential mappings and simple use the idea of an
encoding vector there is no issue here.  You just specify what glyph
you want each number to call up.  And your driver should allow you to
use the same basic font under two TFM names with different encoding.
Of course, without partial font downloading of Type 1 fonts (provided
only by DVIPSONE), working with these large fonts (like the IBM
version of Courier) can become quite unwieldy.

%   The sole purpose of this file is to ensure that all non-composite
%   characters in the font are made available in the raw TFM.  Therefore
%   there are no ligatures or any other refinements.  The raw TFM
%   file contains no ligatures or kernings---nothing but character 

There is no need for separate `raw' TFM and another TFM for a font.
Why use two TFM files when one will do?  One CAN construct a single
TFM file complete with ligatures and kerning based on any user specified
encoding, as already stated above.

Also, if you take the `three mapping' approach, you want to make sure
that the composite characters ARE in the encoding.  You do not want to
use TeX's \accent to construct composites.  Nor should the virtual font
mechanism be used to construct composites that the font designer has
already created, presumably with careful attention to positioning, and in
some cases by actually designing separate glyphs (for example, shallower
accents for upper case characters than for lower case).

Almost all text fonts have separate character programs for composite
characters, hence these are real characters in their own right. True, in
many cases these character programs do use either the `seac' Type 1
operator, or `Subr' calls and hence similar shapes can be achieved by
combining the base and accent character with suitable positioning. However,
in some cases the rendering will not be as good at low resolution, and most
fonts treat at least Ccedilla, ccedilla, and Aring as complete separate
glyphs that cannot be achieved by overprinting (The reason is that one does
not want overlapping contours when the character is `stroked' instead of
`filled').

So if you are going to take this approach you'd want to include at least 
the `standard' 58 composites in your `input encoding'.  Of course, with
some fonts you then start to run out of space in the limited 0 - 255
range.  Which is another reason why the idea of just a single encoding
vector is much to be preferred to the `three map' approach.

%  /Aogonek /Eogonek /Iogonek /Kafii9170 /Lafii9170 /Lcaron /Nafii9170 /Rafii91
70 
%  /Safii9170 /.Scedilla /Tafii9170 /Uogonek /.notdef /.notdef /.notdef /.notde
f
 
% 0x10
%  /aogonek /eogonek /iogonek /kafii9170 /lafii9170 /lcaron /nafii9170 /rafii91
70 
%  /safii9170 /.scedilla /tafii9170 /uogonek /.notdef /.notdef /.notdef /.notde
f

The names for basic characters (like `exclam') are pretty much generally
agreed upon (even to the point of accepting the misspelled `guillemot' for
`guillemet'!).  However, when it comes to some of the above there is
absolutely no agreement, and you enter the arena of current corporate
warfare.  It may make sense to use AFII glyph numbers for these characters,
as Adobe seems to suggest, or it may make sense to use UNICODE numbers as
MicroSoft seems to believe, or we may use the names used by Apple, etc.
Should it be Trightcommaaccent, Tcaron, Thacek, 0164 (hex), AFII100256, or
... ?

Again, a fixed `input encoding' is guaranteed to loose out in the end
because of such incompatabilities.

Anyway, these are minor issues.  My main point is that designing a unique
`input encoding' is not a useful excercise since it is solving a problem
unqiue to one implementation which happens to use a complex system of three
mappings where one mapping (the encoding vector) is in fact all that is needed.

Berthold.

P.S. I put all the emphasized words in upper case just to irritate Don Hosek

P.P.S. I have connections with Y&Y, which supplies Lucida fonts in Type 1 form.

------------------------------

Date:    Wed, 22 Sep 1993 09:30:20 -0400
From:    gajoshi@cam.nist.gov (Ghanashyam_A._Joshi)
Subject: ASCII Typesetting from a LaTeX file

Dear TeXhackers:
        I need to use my file typeset in LaTeX and create an ASCII output
or text output which preserves the typesetting as far as possible. Can
you please URGENTLY send me suggestions on how this can be done using
any of the style-files of programs out there. Thanks.

Ghanashyam Joshi

------------------------------

Date:    Mon, 27 Sep 1993 13:53:43 -0400
From:    Debashis Bhattacharya <bhattach@test1.CE.YALE.EDU>
Subject: TeX, LaTeX, etc. on IBM PC

I am familiar with TeX on Unix systems. I wish to use it on an IBM PC. Are
all sources that I need (including fonts, web2c, various macros, some
previewer, postscript drivers, etc.) available in an organized manner from
one site? I have looked at various README files from ftp.uu.net and
labrea.stanford.edu and have not found my answer.

Is it meaningful to use TeX under Windows, or should I stick to DOS? Are there
guidelines to take care of other similar (perhaps stupid) questions?

Debashis Bhattacharya.

------------------------------

Date:    Fri, 01 Oct 1993 00:49:54 -0000
From:    Chris Thompson <CET1@phx.cam.ac.uk>
Subject: On why LaTeX uses save stack while reading .aux

The following came up in a thread "Managing Large LaTeX Files" on
comp.text.tex. I think the explanation may deserve recording in a
somewhat more durable medium, so I am posting it here as well.

In article <...>, Werenfried Spit <SPIT@EVALUN11.BITNET> writes:
> In article <...>, kaye@vax.oxford.ac.uk (Richard Kaye) says:
> >Has anyone else had save stack overflow when LaTeX read the .aux files?
> >
> >[Will a TeX guru please explain it to me?  I thought \global\def's could not
> >cause save stack overflow until I found this problem.  If it's a general
> >problem, it seems a bit silly that LaTeX should try to input so much
> >information in this way.]
> >
> >I fixed it so that the data was read {\it outside} the group (as part of one
>
> Could someone explain it to me too? I'm even more puzzled after I tried
> out Richards solution and played a bit with it. When you put in
> your input file directly after the \documentstyle command the line
>  \input \jobname.aux
> LaTeX reads the aux file without its memory getting overflowed; then
> at \begin{document} it reads the aux file again (as expected), but
> the memory doesn't overflow this time either. (If you leave out the
> \input \jobname.aux LaTeX only reads the aux file during \begin{document}
> and then chokes on an exceedence of the save size.)

This was a hard one to track down. I could claim that it was all my fault...

The entries on the save stack are not the result of the \global\@namedef,
which as suggested above never needs to use such a thing. They come from
the earlier \@ifundefined call in \newlabel.

Change #337 in tex82.bug numbering, applied in TeX 2.9, changed the implicit
setting of an undefined control sequence referenced via \csname...\endcsname
to \relax (TeXbook, page 213) from being (sort of) global to being local to
the current group. Don made this change as a direct result of my posting to
TeXhax (year 1987, digest 103) pointing out that the TeXbook didn't correctly
describe what happened.

The change was a potent source of new bugs, because TeX was not originally
designed to cope with token expansion have side-effects of modifying the
save stack (see in particular change #371 in tex82.bug). I have more than
once wondered whether I should have kept quiet about the whole business...

In an ideal world, the problem wouldn't arise because the implicit setting
to \relax wouldn't occur at all (IMNSHO). But everything (especially LaTeX)
relies on it now, so it's (far) too late to change it. Something to be got
right in the next incarnation.

Chris Thompson
Cambridge University Computing Service
Internet: cet1@phx.cam.ac.uk
JANET:    cet1@uk.ac.cam.phx

------------------------------

Date:    Fri, 01 Oct 1993 14:03:55 -0800
From:    SYSTEM@SALK-SC2.SDSC.EDU
Subject: Tex Installation on Vax

Help!  I just received a request from a user to install TeX and
Latex on a 6220 Vax.  Can you tell me where I might find documentation
on installing TeX on the VAX.

Some have told me that TeX is old and why would I even bother.  I suppose
you don't have the same opinions, could you explain why you like it.

thanks,
diane burns-giles
system administrator

------------------------------

Date:    Fri, 24 Sep 1993 16:31:25 +0200
From:    "Johannes L. Braams" <J.L.Braams@research.ptt.nl>
Subject: babel release

    Hi all,

        Today I put babel release 3.3.2 in the incoming directory of
        ftp.tex.ac.uk and it has already found its way to its proper
        place, pub/archive/languages/babel. It wil presumably also find
        its way to the other CTAN hosts tonight. This release fixes a 
        number of bugs that crept into the jluy release, which was never
        announced because of them.

        Johannes Braams

PTT Research,                           P.O. box 421,
2260 AK Leidschendam,                   The Netherlands.
Phone    : +31 70 3325051               E-mail : J.L.Braams@research.ptt.nl
Fax      : +31 70 3326477

------------------------------

Date:    Wed, 29 Sep 1993 15:38:57 -0400
From:    Karl Berry <karl@cs.umb.edu>
Subject: modes.mf 1.0 available

I have released version 1.0 of modes.mf.  You can get it by anonymous ftp from

        ftp.cs.umb.edu:pub/tex/modes.mf

You can also get it by email from George Greenwade's (thanks, George!)
file server if you cannot ftp: mail fileserv@shsu.edu with a body of
`sendme modes'.

This file is a collection of Metafont mode_def's.  It also makes common
definitions for write/white printers, `special' information, and
landscape mode.

This version has new modes for the HP ruggedwriter, the QMS 1725, and
8-character or less abbreviations for all modes.  As always, thanks to
the contributors.

If you have mode_def's which are not listed below, or corrections to the
existing ones, please send them to me.  Improvements to the exposition,
particularly in how to create a new mode_def, are also welcome.

karl@cs.umb.edu

mode_def AgfaFourZeroZero =             % AGFA 400PS
mode_def amiga =                        % Commodore Amiga
mode_def AtariNineFive =                % Atari 95dpi previewer
mode_def AtariNineSix =                 % Atari 96x96 previewer
mode_def AtariSLMEightZeroFour =        % Atari ST SLM 804 printer
mode_def AtariSMOneTwoFour =            % Atari ST SM 124 screen
mode_def aps =                          % Autologic APS-Micro5
mode_def ApsSixHi =                     % Autologic APS-Micro6
mode_def bitgraph =                     % BBN Bitgraph at 118dpi
mode_def boise =                        % HP 2680A
mode_def CanonCX =                      % Canon CX, SX, LBP-LX
mode_def CanonEX =                      % CanonEX in LaserWriter Pro 630
mode_def CanonLBPTen =                  % e.g., Symbolics LGP-10
mode_def ChelgraphIBX =                 % Chelgraph IBX
mode_def CItohThreeOneZero =            % CItoh 310
mode_def CItohEightFiveOneZero =        % CItoh 8510A
mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600
mode_def CompugraphicNineSixZeroZero =  % Compugraphic 9600
mode_def crs =                          % Alphatype CRS
mode_def DataDisc =                     % DataDisc
mode_def DataDiscNew =                  % DataDisc with special aspect ratio
mode_def DECsmall =                     % DEC 17-inch, 1024 x 768
mode_def DEClarge =                     % DEC 19-inch, 1280 x 1024
mode_def dover =                        % Xerox Dover
mode_def epsdraft =                     % Epson at 120x72dpi
mode_def epsfast =                      % Epson at 60x72dpi
mode_def epsonlo =                      % Epson at 120x216dpi
mode_def EpsonLQFiveZeroZeroMed =       % Epson LQ-500, 360x180dpi
mode_def EpsonLQFiveZeroZeroLo =        % Epson LQ-500, 180x180dpi
mode_def EpsonMXFX =                    % 9-pin Epson MX/FX family
mode_def GThreefax =                    % 200 x 100dpi G3fax
mode_def HPDeskJet =                    % HP DeskJet 500
mode_def HPLaserJetIIISi =              % HP Laser Jet IIISi
mode_def HPrugged =                     % HP RuggedWriter 480
mode_def ibm_a =                        % IBM 38xx (\#1)
mode_def IBMD =                         % IBM 38xx (\#2)
mode_def IBMFourZeroTwoNine =           % IBM 4029-30, 4250
mode_def IBMFourTwoOneSix =             % IBM 4216
mode_def IBMProPrinter =                % IBM ProPrinter
mode_def IBMSixOneFiveFour =            % IBM 6154 display
mode_def IBMSixSixSevenZero =           % IBM 6670 (Sherpa)
mode_def IBMThreeOneSevenNine =         % IBM 3179 screen
mode_def IBMThreeOneNineThree =         % IBM 3193 screen
mode_def IBMThreeEightOneTwo =          % IBM 3812
mode_def IBMThreeEightTwoZero =         % IBM 3820
mode_def IBMEGA =                       % IBM EGA monitor
mode_def IBMVGA =                       % IBM VGA monitor
mode_def imagewriter =                  % Apple ImageWriter
mode_def laserjetfour =                 % 600dpi HP LaserJet 4
mode_def laserjetlo =                   % HP LaserJet at 150dpi
mode_def lasermaster =                  % 1000dpi LaserMaster
mode_def LASevenFive =                  % DEC LA75
mode_def LinotypeOneZeroZeroLo =        % Linotype Linotronic [13]00 at 635dpi
mode_def LinotypeOneZeroZero =          % Linotype Linotronic [13]00 at 1270dpi
mode_def LinotypeThreeZeroZeroHi =      % Linotype Linotronic 300 at 2540dpi
mode_def LNZeroOne =                    % DEC LN01
mode_def LPSTwoZero =                   % DEC lps20
mode_def LPSFourZero =                  % DEC LPS40
mode_def lview =                        % Sigma L-View monitor
mode_def MacMagnified =                 % Mac screens at magstep 1
mode_def MacTrueSize =                  % Mac screens at 72dpi
mode_def NCD =                          % NCD 19-inch
mode_def NEC =                          % NEC
mode_def NEChi =                        % NEC-P6 at 360x360dpi
mode_def Newgen =                       % Newgen 400dpi
mode_def NeXTprinter =                  % NeXT 400dpi
mode_def NeXTscreen =                   % 100dpi NeXT monitor
mode_def nullmode =                     % TFM files only
mode_def OCESixSevenFiveZeroPS =        % OCE 6750-PS
mode_def okidata =                      % Okidata
mode_def OneTwoZero =                   % e.g., high-resolution Suns
mode_def phaser =                       % Tektronix Phaser PXi
mode_def PrintwareSevenTwoZeroIQ =      % Printware 720IQ
mode_def qms =                          % QMS (Xerox engine)
mode_def QMSOneSevenTwoFive =           % QMS 1725
mode_def QMSOneSevenZeroZero =          % QMS 1700
mode_def RicohFourZeroEightZero =       % e.g., TI Omnilaser
mode_def RicohLP =                      % e.g., DEC LN03
mode_def SparcPrinter =                 % Sun SPARCprinter
mode_def StarNLOneZero =                % Star NL-10
mode_def sun =                          % Sun and BBN Bitgraph at 85dpi
mode_def supre =                        % Ultre*setter at 2400dpi
mode_def toshiba =                      % Toshiba 13XX, EpsonLQ
mode_def ultre =                        % Ultre*setter at 1200dpi
mode_def VarityperFiveZeroSixZeroW =    % Varitype 5060W
mode_def VarityperFourThreeZeroZeroLo = % Varityper 4300P at 1200dpi
mode_def VarityperFourThreeZeroZeroHi = % Varityper 4300P at 2400dpi
mode_def VarityperFourTwoZeroZero =     % Varityper 4200 B-P
mode_def VarityperSixZeroZero =         % Varityper Laser 600
mode_def VAXstation =                   % VAXstation monitor
mode_def XeroxDocutech =                % Xerox 8790 or 4045
mode_def XeroxEightSevenNineZero =      % Xerox 8790 or 4045
mode_def XeroxFourZeroFiveZero =        % Xerox 4050/4075/4090
mode_def XeroxNineSevenZeroZero =       % Xerox 9700
mode_def XeroxThreeSevenZeroZero =      % Xerox 3700

------------------------------

Date:    Wed, 29 Sep 1993 15:36:55 -0400
From:    Karl Berry <karl@cs.umb.edu>
Subject: xdvik 1.2, dvipsk 5.519a available

I've released new versions of:
* kpathsea -- my path searching library,
* xdvik -- my modified xdvi that uses it, and
* dvipsk -- my modified dvips that uses it.

        ftp.cs.umb.edu:pub/tex/{xdvik,dvipsk}.tar.gz

I've established a mailing list, tex-k@cs.umb.edu, for bug reports and
discussions for the TeX-related stuff I maintain.  I hope this will
provide for sharing of interim fixes, quicker help when I cannot respond
immediately, and so on.  To join, email tex-k-request@cs.umb.edu with a
message whose body contains a line
subscribe your-preferred-email-address

Next thing up is web2c.  I don't expect to have something releasable for
a month at best (so please don't ask :-).

As always, thanks to the many people who contributed.
Here's the NEWS:

kpathsea 1.2
* Running MakeTeXPK is tried before the fallback resolutions.
* The final bitmap name uses a variable spec, so DOS & OS/2 can get
  dpi300/cmr10.pk.
* Document TeX-specific features.
* Dpi passed to MakeTeXPK via the envvar KPATHSEA_DPI instead of MAKETEX_DPI.

xdvik 1.2
* Remove unnecessary backslash-only lines from dependencies in Makefile.
* Make -DGREY and -DTEXXET the default.
* Runtime control of whether MakeTeXPK is invoked.
* Support for drawing EPS files (using Ghostscript).

dvipsk 5.519a
* Document DVIPSMAKEPK and DVIPSSIZES.
* Remove unnecessary backslash-only lines from dependencies in Makefile.
* Use the envvar DVIPSHEADERS, and document it.
* Do not include the emtex fontlib support, as it likely does not work.
* Update for dvips 5.519.

karl@cs.umb.edu
Help fight the new programming monopolies -- write lpf@uunet.uu.net.

------------------------------
 
Further information about the TeXhax Digest, the TeX
Users Group, and the latest software versions is available
in every tenth issue of the TeXhax Digest.

Please send contributions to: TeXhax@tex.ac.uk

Administration, subscription and unsubscription requests:
  On Internet:
    send a one line mail message to TeXhax-request@tex.ac.uk
        SUBSCRIBE TEX-L <your real name>
        UNSUBSCRIBE TEX-L
  On BITNET:
    send a similar one-line mail message to LISTSERV@xxx
  On JANET:
    send a similar one line mail message to TeXhax-request@uk.ac.tex

For information on the TeX Users Group, please send a message to
TUG@math.ams.com, or write TeX Users Group, P.O. Box 869, Santa
Barbara, CA 93102, USA.

Back issues of the digest are available for anonymous ftp from
the UK TeX Archive, tex.ac.uk (134.151.79.28)
    in [tex-archive.digests.texhax.YY]texhax.NN
and ftp.tex.ac.uk (134.151.79.32)
    in /pub/archive/digests/texhax/YY/texhax.NN
where YY = last two digits of year, NN = issue number

ftp.tex.ac.uk is also mirrored to pip.shsu.edu (192.92.115.10) and
ftp.uni-stuttgart.de (129.69.1.12) as part of the Comprehensive TeX
Archive Network, and may give better response for subscribers in the
USA and Europe, respectively.

\bye

End of TeXhax Digest [Volume 93 Issue 14]
*****************************************