summaryrefslogtreecommitdiff
path: root/info/digests/texhax/93/texhax.14
diff options
context:
space:
mode:
Diffstat (limited to 'info/digests/texhax/93/texhax.14')
-rw-r--r--info/digests/texhax/93/texhax.14577
1 files changed, 577 insertions, 0 deletions
diff --git a/info/digests/texhax/93/texhax.14 b/info/digests/texhax/93/texhax.14
new file mode 100644
index 0000000000..ffbc20046a
--- /dev/null
+++ b/info/digests/texhax/93/texhax.14
@@ -0,0 +1,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]
+*****************************************