TeXhax@cs.washington.edu (TeXhax Digest) (01/01/90)
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" <WSULIVAN%IRLEARN@UWAVM.ACS.WASHINGTON.EDU>
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:<msdos.tex>
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 <louis@aerospace.aero.org>
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 <cbts8001@iruccvax.bitnet>
-----------------------------------------------------------------------------
Date: Sun, 10 Dec 89 23:00 PST
From: "D.A. HOSEK" <DHOSEK@HMCVAX.CLAREMONT.EDU>
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
<mike@inrs-telecom.uquebec.ca>.
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 <your name> % 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
**************************
-------