diff options
Diffstat (limited to 'info/digests/texhax/93/texhax.14')
-rw-r--r-- | info/digests/texhax/93/texhax.14 | 577 |
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] +***************************************** |