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 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 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 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" 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 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 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 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] *****************************************