Subject: TeXhax Digest V89 #116 From: TeXhax Digest Errors-To: TeXhax-request@cs.washington.edu Maint-Path: TeXhax-request@cs.washington.edu To: TeXhax-Distribution-List:; Reply-To: TeXhax@cs.washington.edu TeXhax Digest Friday, December 29, 1989 Volume 89 : Issue 116 Moderators: Tiina Modisett and Pierre MacKay %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% %%% in cooperation with the UnixTeX distribution service at the %%% %%% University of Washington %%% Today's Topics: Upgrade of sbtex for MSDOS Some neat Macintosh utilities Floating bottom inserts TeX 3 hyphenation pattern assignments TeX 3 in a multilingual environment - some ideas ------------------------------------------------------------------------------- Date: Mon, 11 Dec 89 10:25:43 GMT From: "Wayne G. Sullivan" Subject: Upgrade of sbtex for MSDOS Keywords: SBTEX, MSDOS An upgrade of sbtex, sb29, is now available by anonymous FTP as sb29tex.zip from VENUS.YCC.YALE.EDU and as sb29tex.arc in the SIMTEL20 pd1: directory. It is (or should soon be) available from ASTON. sb29 is TeX 2.991 for MSDOS. I regret that I have not had, nor will have in the near future, time to include the 2.992 changes: sbtex is a spare time project. The features of sb29: 1. Bug fix concerning CTRL-BREAK during terminal I-O. 2. Editing support: sb29 includes Peter Sawatzki's TE editor which facilitates rapid scrolling between errors in the TeX file which are marked in the LOG file. Support for the 'E' option by means of batch files. 3. Increased hash-size. sb29 can handle up to 3500 multi-letter control sequences; sb26 was limited to 3050. 4. User adjustable pool-size and save-size: some of the recent work by Rainer Schoepf and Frank Mittelbach requires larger values for these than that specified in TeX.WEB. 5. Multiple paths for TEXINPUTS and FONTTFMS. (sbtex uses FONTTFMS for the TFM directories rather than TEXFONTS because the Beebe drivers use TEXFONTS for fonts, which seems reasonable.) Wayne Sullivan ----------------------------------------------------------------------------- Date: Sat, 9 Dec 89 11:07:44 -0800 From: Louis M. McDonald Subject: Some neat Macintosh utilities Keywords: PostScript, Macintosh I recently found the program AddLPrep on the BBS "America OnLine". This is a program that runs on the Mac and can be used to create "portable" PostScript. It is not perfect, and I have not been able to test it against non-Apple PostScript printers. A description follows. A copy of it (in STUFFIT/binhex format) can be found in aerospace.aero.org (26.2.0.65) as the file pub/addlaserprep.hqx. Also, if you do not read USENET newsgroup comp.binaries.mac, someone recently posted a MacDraw-Like program that can be used to create "picture" files for the LaTeX picture environment. I have not used it much, but it does seem to work okay. This can also be found on aerospace.aero.org, file is pub/pictex.hqx Louis McDonald %=== AddLPrep v1.2 Documentation 7/31/89 Apple's LaserWriter system allows a user to get a complete PostScript disk file (including the library code from the "Laser Prep" file) by hitting Command-K WHILE MOUSING DOWN on OK from the LaserWriter Print dialog, or a file without the library code by hitting Option-F. Option-K and Command-F may do one or the other (??). Unfortunately, the Laser Prep code includes a few features that make the Command-K file unusable on certain non-Apple laser printer systems, such as a DEC ScriptPrinter connected to a VAX. The AddLPrep program remedies this situation by adding a modified version of the PostScript code from the Laser Prep file to a PostScript file created by hitting Option-F. The output file produced by AddLPrep is thus suitable for downloading to any PostScript printer or typesetter. This version (1.2) differs from 1.1 in two ways: 1. It works with "Laserwriter 6.0" (AppleDict 70) as well as System 6.0 (AppleDict 68) and System 5.0 (AppleDict 65). 2. A problem is fixed, wherein the DA version caused a system crash after an error message. VERY IMPORTANT: AddLPrep is SHAREWARE and is copyright ) 1988 by Software101, Los Gatos, CA. Feel free to try it out and give copies to others, but if you find the program useful and continue to use it, send $20 to Software101, 15151 Old Ranch Road, Los Gatos, CA 95030. As indicated below, this program may need considerable support; problems will be solved only for those who have paid for the program. Someday, in some manner, new versions may be available only to those honest folks. TECHNICAL NOTE: AddLPrep substitutes the Laser Prep code for a line starting with: %%IncludeProcSet: "(AppleDict md)" If the input file does not contain a line like this, then AddLPrep produces an Alert box noting that it has just functioned as a text file duplicating program. (This will not occur for files created by Option-F as described above.) ABOUT RELIABILITY: As AddLPrep transfers the PostScript code from the Laser Prep file to the output file, it makes a few modifications to the code to make it suitable for use as a "transient" program that doesn't "take over" the printer or modify its state. AddLPrep has been tested with a number of common Mac applications and with a DEC ScriptPrinter. However, it may prove unreliable in any of the following cases: a) when used with a version of Laser Prep other than the ones distributed with Apple's System Software 5.0 and 6.0 (a.k.a. System 4.2/Finder 6.0 and 6.0/6.1 respectively). Internally, the code in these Laser Prep files is called version 65 and 68 respectively. The current version of AddLPrep (1.2) has also been tested with "Laserwriter 6.0"; the accompanying Laser Prep is called version 70 internally. If the Laser Prep file is sufficiently different, AddLPrep will detect the problem and show an Alert box. Or, b) when used with a different PostScript printer, or c) when used with applications other than those the author has tested it with, or d) when used with documents that contain graphic shapes other than those the author happens to have tested (e.g., arcs have not been tested). The most likely source of problems is a), for future versions of Laser Prep. --------------------------------------------------------------------------- Date: Mon, 11 Dec 89 00:06 GMT From: CBTS8001%IRUCCVAX.UCC.IE@UWAVM.ACS.WASHINGTON.EDU Subject: Floating bottom inserts Keywords: TeX, insertions, floating, pagebottom I have an urgent need for a \botinsert macro to perform the same as a \topinsert but to float the inserted material to the bottom of the page, much in the same way as footnotes. Footnotes are not being used in the particular document, but double-column macros (TeXbook, p417) *are*, using \begindoublecolumns etc. My experience with getting footnotes to spread across the whole \pagewidth is that I can't do it without help. Anyway, the design requirement is for bottom inserts with a box drawn round them, full pagewidth, and not taking up more than 2" height. Can anyone fix me a \botinsert to do this? It doesn't look too difficult, but any attempt I have made to date either causes \maxdeadcycles to be overrun, or I get massive overfull vboxes at \output time. BTW this is PLAIN TeX, not LaTeX. All contributions gratefully received, and a working version will be posted if I get one. ///Peter Flynn ----------------------------------------------------------------------------- Date: Sun, 10 Dec 89 23:00 PST From: "D.A. HOSEK" Subject: TeX 3 hyphenation pattern assignments Keywords: TeX 3.0, hyphenation It would be silly to plan on trying to come up with standard pattern numbers for each language that TeX might come across; it would be a pain to try and keep track of it all, and I, for one, am disinclined to bother with keeping a directory of the nature: 0 = US English 1 = Italian 2 = French 3 = Turkish etc. There are doubtless more than 256 hyphenatable languages in the world (anybody care to come up with the actual number), and sites are likely to only pre-load those patterns that receive common use anyway. What I would recommend is that we have \newhyphenation along the lines of \newtokens, \newbox, etc. Then, we would do something along the lines of \newhyphenation\german etc. and automatically be able to say \patterns\german to select the German patterns. The calling file can check to see if the patterns are pre-loaded and if not set \german (or whatever) to \relax (I think, in fact, that the TeXbook has an example of a macro that does just that). Then, rather than having to agree on a cryptic, possibly useless, set of numbers, we only need to come up with standard names. Much more sensible, I think. On the topic of names, I have suggested in the past and continue to advocate the following scheme for the naming of hyphenation patterns: ccHYPHxn.TEX Where cc is the two character ISO country code for the country where the language is most commonly spoken (this might cause problems for some languages, e.g., the many Indian languages--Dominik, can you offer some sage wisdom on that topic?); x is A if the hyphenation pattern takes diacriticals into account, null otherwise; and n is normally null, unless more than one version of a hyphenation pattern for a certain language is available. For languages which cannot be assigned by a country, an arbitrary two letter code should be chosen by the designer of the patterns (e.g., RM for a Latin hyphenation pattern). The following are the hyphenation patterns available for FTP from ymir.claremont,edu (subdirectories of SOFTWARE:[TEX.BABEL], if you care to investigate). DEHYPH.TEX German Hyphenation DEHYPHA.TEX German Hyphenation with Umlaut ISHYPHA.TEX Icelandic Hyphenation ITHYPH.TEX Italian Hyphenation NEHYPH.TEX Dutch Hyphenation PTHYPH.TEX Portuguese Hyphenation TKHYPHA.TEX Turkish Hyphenation If a new hyphenation pattern for German with umlauts were to appear, then we would have DEHYPHA1.TEX and DEHYPHA2.TEX instead. Any comments on this naming convention? (I will summarize notes sent to me in a future not to TeXhax, if necessary) Incidentally, Michael J. Ferguson volunteered to collect hyphenation patterns. His e-mail address is . I also would appreciate receiving any hyphenation patterns I do not already have. -dh ------------------------------------------------------------------------------ Date: Sat, 09 Dec 89 17:12:18 GMT From: PEB%DM0MPI11.BITNET@CUNYVM.CUNY.EDU Subject: TeX 3 in a multilingual environment - some ideas Keywords: TeX, multilingual environment Below is a draft for an article to be published in TUGboat and TeXhax. This is a preliminary version and I would greatly appreciate comments and suggestions from all those with experience in using TeX in a multilingual environment. P.Breitenlohner (peb@dm0mpi11.bitnet) Title: Using TeX 3 in a multilingual environment. Author: Peter Breitenlohner, Max-Planck-Institut fuer Physik, Muenchen As a physicist at a research institute I am using TeX (2.x) in a bilingual (german + english) environment since many years. In the past we had for each format package (plain, LaTeX, AmSTeX, ...) two versions, one with english and one with german hyphenation patterns. With the new TeX 3 this will probably change: we will use versions of the format packages containing hyphenation patterns for both languages and the user will have to select the apropriate language (globally at the beginning of his input and maybe locally if his document contains parts from the other language). This seems to be the right time to consider how the new multilingual TeX 3 can be used in an portable, user friendly and efficient way (in that order). In the following I will try to discuss what should and what can be done for such a situation. 1. Assigning numbers to the languages. Recently there have been various proposals (e.g. in TeXhax) how to assign numbers to the various languages. In would like to advocate a rather different point of view: for the user of TeX it is completely unnecessary to know these numbers because he should not select the language numbered 1 but rather the language named \english. Thus numbers should be assigned to languages by a \newlanguage macro somewhat similar to plain's \newcount, \newbox etc. When I first proposed to Don Knuth that such a macro should be included in plain.tex his immediate reply was: ``I have no intention of changing plain.tex ever again! ...'', but later on he sent me a message containing the paragraph: ``I still don't want to change plain TeX; but it's easy to publish a short definition of \newlanguage that every hyphenation-table package could define at its beginning.'' In a multilingual environment one may or may not want to include the english pattens and in a monolingual non-english version of TeX the english patterns should certainly be excluded. In order not to change plain.tex one should therefore have a dummy file hyphen.tex and the original (english) hyhpen.tex could be renamed hyphen.eng (or similar). Thus the absolute minimum one would need is a \newlanguage macro which could be used (in an INITEX job) as follows: \input plain \newlanguage\english \language\english \input hyphen.eng \newlanguage\german \language\german \input hyphen.grm \dump The user can then, in his TeX, job select his language with the command \language\english . 2. Setting up an environment for each language. From past experience we know that more needs to be done. For german texts one would probably want a larger value for \tolerance than the value (200) chosen in plain.tex for english texts. In addition one would want to make " an active character for german and define it such that "a, "s, "ck, "ll etc. expand to something like \"a, \ss, \discretionary{k-}{}{c}k, l\discretionary{l-}{}{}l and so on. (The actual definitions used for german are different but this is the basic idea.) Finally macro packages designed for multiple languages should have a possibility to select texts, e.g., for headings, in a way which depends on the language currently selected. (I strongly advocate that all format packages should be redesigned in this sense in the near future.) In the past such things have often been put on top of the macro package (e.g., german.sty on top of latex.tex). With TeX 3 and its capability to handle multiple patterns it seems naturall that the basic mechanisms for language dependencies should be defined when the hypenation patterns are digested, i.e., immediately after plain.tex (or lplain.tex) but before further further macros definitions (latex.tex, amstex.tex or whatever). Thus I would propose a \newlanguage macro invoked as \newlanguage\english{eng_setup}{eng_reset} \newlanguage\german{grm_setup}{grm_reset} which assigns numbers to \english and \german and defines macros \setenglish and \setgerman. Assume that the current language is \english and the user wants to switch to german: \setgerman should first execute the `eng_reset' code in order to cancel the effect of a previous \setenglish, set \language=\german, and finally execute the `grm_setup' code which could - remember the current value of \tolerance which needs to be reactivated by the `grm_reset' code and set \tolerance - make " an active character with the appropriate definition and add " to the \dospecials list (needed e.g., for \verbatim) All this would be cancelled automatically when either the current group ends or when the user explicitely selects a different language, e.g., via \setenglish. In addition one would need a mechanism to produce language dependent texts. Consider a macro \themonth which produces the name of the current month or \chap@head producing the heading for a chapter (with expansion of expandable tokens and nothing else!). Possible definitions could be \def\themonth{\caselang\english \the@eng@month % \language=\english \caselang\german \the@grm@month % \language=\german \elselang{???}% none of the above \filang} \def\chap@head{\caselang\german {Kapitel}% \language=\german \elselang {Chapter}% all other languages \filang} with \def\the@eng@month{\ifcase\month ???\or January\or February\or ... \or December\else ???\fi} and similar for \the@grm@month. There should be no necessity that the \caselang commands appear in the same order as the corresponding \newlanguage commands. 3. Defining sub-languages or dialects. Unfortunately things are even more complicated (at least for the german language). The month January is called `Januar' in Germany and `J"anner' in Austria. Thus one might want to define dialects within one language - the distinction being that whoever uses the same hyphenation patterns uses the same language. In complete analogy to \newlanguage there should be a \newdialect macro which defines a new dialect for the current language. The sequence of commands \input plain \newlanguage\english{eng_setup}{eng_reset} \language\english \input hyphen.eng \newdialect\USenglish{...}{...} % english language, USA \newdialect\UKenglish{...}{...} % english language, UK \newlanguage\german{grm_setup}{grm_reset} \language\german \input hyphen.grm \newdialect\Dgerman{...}{...} % german language, germany \newdialect\Agerman{...}{...} % german language, austria \newdialect\CHgerman{...}{...} % german language, switzerland \dump would assign numbers 1 to \USenglish and \Dgerman, 2 to \UKenglish and \Agerman and 3 to \CHgerman and would define macros \setUSenglish, ... \setCHgerman which, if necessary, first select the appropriate language and the the dialect specified. Note that the scheme is such that the user always specifies \set... not knowing whether, e.g., USenglish was defined as language or as dialect. This if different for the designer of a macro package who now could define \def\the@grm@month{\ifcase\month ???\or \casedial\Agerman {J"anner}% used if austrian dialect \elsedial {Januar}% used if other or no dialect \fidial\or Februar\or ... \or Dezember\else ???\fi} 4. Protection Some of the macro definitions discussed above (\setenglish etc.) certainly must be protected against expansion if they are, e.g., written to an external file. Here I would, however, propose a slight deviation from LaTeX's scheme. \setenglish should be defined via \global\defprotect\setenglish\s@tenglish with the definitions \def\defprotect#1#2{\def#1{\pr@tect#1#2}} \def\doprotect{\let\pr@tect\d@protect} % could be prefixed \global \def\noprotect{\let\pr@tect\n@protect} % idem \def\n@protect#1{} \def\d@protect#1#2{\noexpand#1} \noprotect % normally we want no protection Thus the sequence {\doprotect \immediate\write{\setenglish}} would write the string `\setenglish' (not `\s@tenglish') which would still be protected when read in and written again. 5. In the preceding I have discussed the design of a scheme to handle multiple languages in TeX 3. I have intentially left out almost all details how such a scheme could be implemented. For the moment it seems more urgent to agree on a design (including the user interface) than on details how such a design can be realized through macro definitions. ----------------------------------------------------------------------- %%% 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. %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% %%% BITNET: send a one-line mail message to LISTSERV@xxx %%% SUBSCRIBE TEX-L % to subscribe %%% or UNSUBSCRIBE TEX-L %%% %%% Internet: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% JANET users may choose to use %%% texhax-request@uk.ac.nsf %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nn %%% yy = last two digits of current year %%% nn = issue number %%% %%%\bye %%% End of TeXhax Digest ************************** -------