UKTeX-Request@tex.ac.uk (03/01/91)
UKTeX Digest Friday, 1 Mar 1991
Volume 91 : Issue 9
Today's Topics:
{Q&A}:
BoxedEPSF.tex
DVI to 24-pin
EmTeX distribution from Aston
Re: Changebars.sty
Problem with M & S Font Selection Scheme
Baselinestretch when using M & S font selection scheme
re: use of PK founts under MS-DOS
Euler fonts and MFJOB
use of PK founts under MS-DOS
New smaller.sty
Forward from Eberhard Mattes: [use of PK founts under MS-DOS]
TUG Conference Proceedings Summaries
{Announcements}:
Formation of ITALIC (Irish TeX And LaTeX Interest Community)
Greek typesetting
UK TeX archive directory listings
Announcing DVItoLN03 V4.0 for VAX/VMS
Official new lplain and splain files
{Archive News}:
Additions to archive
Re: Changebars.sty
Rail package for diagrams and TeX
new version of xdvi
Rich Text Format conversion
RE: Greek Typesetting
Apologies to UUCP clients of TeXserver
Would clients of Aston TeXserver please check disk quotas!
Convert MSWord to LaTeX (crude but useful)
Administrivia:
Moderator: Peter Abbott (Aston University)
Editor: David Osborne (University of Nottingham)
Contributions: UKTeX@uk.ac.tex
Administration, subscription and unsubscription requests:
UKTeX-request@uk.ac.tex
------------------------------------------------------------
Date: Thu, 21 Feb 91 23:10:32 +0100
From: LCS%FR.MATUPS.MATUPS@UK.AC.MHS-RELAY
Subject: BoxedEPSF.tex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
EPSF graphics integration via TeX \special's
--- a gentle path out of chaos [version of 22 Feb 1990]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Back in Fall 1990, Teresa A. Ehling
<ehling@mitvma.mit.edu>, and Berthold K.P. Horn
<bkph@ai.mit.edu> of Cambridge Mass posted an open letter on
integration of Encapsulated Postscript graphics Files (EPSF's)
graphics in TeX documents (TeXhaX digest22 Oct 90). Their
problem is exactly one I have met in editing a conference
proceedings volume on 3-manifold topology over the past year.
Encouraged to believe this problem is typical, I would like to
offer my particular solution. It is valid immeditely for just
about everyone, given a modicum of cooperation from readers
here.
Ehling and Horn state the problem very well:
>
> Publishers, particularly those active in
> technical areas, are rapidly moving towards the
> use of author-supplied, machine- readable
> material, for both journal and book production.
> In mathematical and scientific areas, text
> material is often best communicated in the form
> of DVI files. Figures to be inserted are most
> commonly provided in Encapsulated PostScript
> (EPSF) form.
>
> A major stumbling block to completion of the
> transition to seamless electronic publishing is
> that every DVI processing program supports a
> different usage convention for the \special
> command. This means that every book or journal
> project must be customized: instead of a smooth
> operation involving only the transfer of the
> authors DVI and EPS files, serious programming
> effort is often required to deal with the myriad
> variations in the \special syntactical rules.
>
> Realistically, all that the author requires is a
> way of inserting an EPS-defined figure at a given
> place in the TeX document. Our experience with a
> large number of author-supplied DVI files
> indicates that the predominant use of \special is
> for simple figure insertion. In a small number of
> cases, the figure also needs to be scaled. We
> have yet to encounter a case where a figure needs
> to be shifted, rotated, skewed, or clipped. More
> importantly, no use is ever made of the ability
> to insert verbatim PostScript commands, to call
> on PostScript functions native to a particular
> DVI processing program, or to produce overlays.
> While these transformations represent interesting
> and powerful extensions, they apparently are not
> vital to the production of even the most
> sophisticated texts.
>
In my own case, articles are moving constantly back and
forth across several continents by email and ftp. Graphics that
arrive by paper mail weeks or months later are anathema. Each
article consists of an ascii ".tex" file for the print and a number
of ascii EPS files for the graphics inserts. Our editors and
publisher cannot manage with less than three distinct drivers, and
authors would greatly appreciate support for an ever increasing
number.
One quibble though. We almost always use the scaling
feature in \special commands, even when the artist is able to
control scaling; in this way the editor and publisher almost never
have to play with EPSF files and can concentrate their efforts on
the TeX file.
With this nuance, I agree that that our graphics insertions,
like those encountered by Ehling and Horn, currently require only
the bare basics they mention.
Ehling and Horn make a strong plea for the rapid adoption of
a \special standard covering at least the basics. Unfortunately even
if such a standard is rapidly adopted, the present chaotic situation
may not much improve for a few years while drivers are being
revised.
The gist of the present note is that a portable EFSF
integration package can come quite close to providing the seamless
integration Ehling and Horn dream of, even if the present anarchy in
usage for \special commands persists. In a sense this makes the
standard nearly (but not quite) irrelevant. Further it will be able
assimilate a \special standard the day it appears. I programmed
BoxedEPSF.tex for just this purpose, and am now making it available
to the public.
Here is how it is used. One \input's the file
BoxedEPSF.tex. So long as there is no \special standard, you also
have to identify your driver by a command like
\SetArborEPSFSpecial %%(for the ArborTeX dvi to PS driver)
Other driver commands \Set...EPSFSpecial are listed in
BoxedEPSF.tex (or its documentation).
Thereafter, one can place a postscript figure given by an
EPS File myfile.ps by simply typing (for example)
\BoxedEPSF{myfile.ps scaled 400}
Here the (optional) scaling is to 40 percent = 400 mills. The result
is a graphics insert that behaves like a TeX character or *box*,
whose height and width are the height and width indicated in the
bounding box comment of the EPS file, (in the line beginning
"%%Bounding Box:" before the line beginning "%%EndComments"). It is
well known that TeX can be made to read this comment, reserve a
blank box of space of this size (scaled), and then set up an
appropriate \special command of the driver in question, causing the
Postscript printer to insert the (scaled) graphics nicely into this
box. That is what \BoxedEPSF{...} is programmed to do. This should
be contrasted with insertion by naked \special commands, which by
convention imposes no displacement.
Note that the user does not have to know about \special
commands since he uses \BoxedEPSF instead. He just has to pick, out
of a preestablished list, the \Set...EPSFSpecial command that
corresponds to his driver. Yes, that IS a pain, and it will only go
away only when a \special standard comes into use. But it not a big
pain, and not debilitating, even for beginners.
All the ideas above have been in circulation for several
years and BoxedEPSF.tex is not the first package to offer all of
them well knit together. However, the packages that have come to my
attention each serve very few drivers, and often are so
"feature-loaded" --- that porting is problematic. This one is built
for easy portability and makes lowest-common-denominator demands on
the driver. It is a single ".tex" file (the same for all drivers)
BoxedEPSF.tex is currently available from the author
at the addresses below; when it is considered to be in definitive
shape it will be posted more conspicuously. Hopefully soon.
BoxedEPSF.tex offers, via simple TeX programming, quite a
few convenient extra features such as sliding, framing, trimming,
squeezing, squashing, and aligning --- so far as actions worthy of
these names can be accomplished without making extra demands on the
driver. On the other hand it does not explicitly support
sophisticated PostScript features such as shared prologues,
clipping, rotations, distortions etc.
The initial list of \Set...EPSFSpecial commands for
support of specific drivers is:
%%\SetTexturesEPSFSpecial for Textures
%%\SetArborEPSFSpecial for ArborText DVILASER/PS
%%\SetOzTeXEPSFSpecial for OzTeX
%%\SetPsprintEPSFSpecial for sprint for Vax and VMS
%%\SetUnixCoopEPSFSpecial early unix "dvi2ps" driver.
%%\SetRokickiEPSFSpecial for Rokicki's "dvips" driver.
To extend this list is easy, but it will require a bit of
cooperation from the users of other drivers. Who, for example is
willing to be a correspondent for the Beebe drivers?
To let me extend support to ANY OTHER driver PLEASE SEND
ME the \special syntax required to insert a file myfile.ps with
scaling 76 percent!
For example, the right answer for ArborTex was (I hope!):
\special{ps: epsfile myfile.ps 760}
And that was (almost) enough to let me program \SetArborEPSFSpecial.
One more scrap of information is essential. Some
\special's for EPSFs place the lower left corner of the (scaled)
bounding box at the TeX insertion point (which requires reading the
bounding box comment), and others simply place the lower left corner
of the artist's page at the insertion point. No other choice seems
consistent with Knuth's recommendations in the TeXbook. Textures and
ArborTeX belong to the first type, while OzTeX and Rokicki's dvips
belong to the second. Please report on the basis of documentation
and/or experimentation, which type is in question. An experimental
test routine is provided below.
In general, some testing and/or driver documentation
may be needed to clear up lingering questions. For example, are
decimals allowed in in the scaling specification? For ArborTeX I
believe the answer is no.
An information form is included below for those who
would like to see BoxedEPSF.tex adapted to another driver.
When a \special standard finally appears, a command
\SetStandardEPSFSpecial will be added to the list above. And when
the standard is widely respected \SetStandardEPSFSpecial will
no longer be commented out, and consequently it will make the
default setting correspond to the standard.
Laurent Siebenmann
Mathematique, Bat. 425,
Univ de Paris-Sud,
91405-Orsay,
France
lcs@matups.matups.fr (best for big files)
LS@FrMaP711.bitnet (good for big files)
siebenma@FRLAL51.bitnet (reliable!)
siebenmann@LALCLS.decnet.cern.ch (reliable!)
Fax number: 33-1-6941-6221
PS. Request \BoxedEPSF.tex and its documentation by email.
PS. Culled from the correspondence on the net, here are four
references that may give you leads to alternative solutions.
--- PSFIG a package by Trevor Darrell (for at least two drivers)
available by anonymous ftp from whitechapel.media.mit.edu
(18.85.0.124) in ./psfig or linc.cis.upenn.edu (130.91.6.8) in the
directory ./dist/psfig.
--- Merging PostScript Illustrations: Gerald Roylance 1987, 1989,
see MIT AI Laboratory Working Paper 299a; this package supports
dvi2ps and DVILASER/PS.
--- dvips and epsf.tex by by T. Rokicki
<rokicki@Neon.Stanford.EDU>
--- Nicolas Jungers <EDITEX@BUCLLN11.BITNET> two postings in the
GUTenberg forum <GUT@FRULM11.BITNET> 9 Nov 90 and 17 Nov 90; a
"do-it-yourself" kit.
APPENDIX: AN INFORMATION KIT FOR OTHER DRIVERS
-------------------------------cut
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% spectest.tex
%%% Test to discover which point in
% the graphics page (plane) your \special
% command distinguishes and identifies to
% the TeX insertion point.
%
% --- Put the file gsquare.ps into the same folder as
% TeX and this testfile. Hopefully this will make
% gsquare.ps accessible to the printer driver.
%
% --- Complete the \special{... gsquare.ps ...} command below
% as your driver documentation recommends for printing
% the EPSF file gsquare.ps --- without any scaling, or other
% refinement. For example
% \special{ps: epsfile gsquare.ps 1000}
% is suitable for the ArborteX driver.
%
% --- Typeset this file
%
% --- Print the resulting .dvi file using your driver.
%
% INTERPRETATION:
%
% If the black box lies in the square, the
% distinguished point is the lower, left-hand corner of the
% PostScript bounding box.
%
% If the black box lies outside the square, the
% distinguished point is the lower, left-hand corner of the
% artist's page, i.e. the the PostScript origin.
%
% If the square is missing, your driver has probably not found
% the EPS file gsquare.ps, or you have formulated the \special
% command incorrectly. Follow driver instructions more
% carefully.
%
% --- report results to Laurent Siebenmann
% <lcs@matups.matups.fr>
% on the special reply "reply.doc" form provided below.
%
%
\null
\vfill
\vskip -1 in
\moveright 1 in \vbox{\hrule height 1 in width 1 in}
\vskip 1 in
\special{... gsquare.ps ...}%% please carefully adjust this
\eject
\bye
%% end of spectest.tex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-------------------------------cut
%!PS-Adobe-2.0
%%Title: gsquare.ps
%%Pages: 0
%%BoundingBox: 216 216 432 432
%%EndComments
72 72 scale % units are now inches instead of big points
newpath
3 3 moveto
3 6 lineto
6 6 lineto
6 3 lineto
closepath
0.8 setgrey
fill
-------------------------------cut
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% reply.doc %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
INFORMATION FORM for adaptation of BoxedEPSF.tex
to other "dvi-to-PostScript" printer drivers
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Please provide information on in the following items:
--- Name and email address(es) of correspondent.
--- Driver information :Name, version, date, copyright, vendor,
computer(s) served, price etc.
--- Syntax required to print the EPS File gsquare.ps scaled to 76
percent using a command of the form \special{... gsquare.ps ...}. Is
scaling to exactly 76.33 percent available?
--- More info on \special.
--- Location of the distinguished point. (Report result of test
in spectest.tex above).
--- Source(s) of your EPSF files.
--- Do you progam TeX? PostScript?
A trial adaptation to your driver will be returned
with BoxedEPSF.tex. Thank you for cooperating!
Laurent Siebenmann
Mathematique, Bat. 425,
Univ de Paris-Sud,
91405-Orsay,
France
lcs@matups.matups.fr (best for big files)
LS@FrMaP711.bitnet (good for big files)
siebenma@FRLAL51.bitnet (reliable!)
siebenmann@LALCLS.decnet.cern.ch (reliable!)
Fax number: 33-1-6941-6221
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-------------------------------cut
APPENDIX. HOW ARE THE EPS GRAPHICS FILES BEING CREATED?
While everyone admires PostScript graphics, few TeX
users are entirely happy with their tools for producing the EPSF
files. As soon as your integration problem has been disposed of,
this one will be back to haunt you! Here are a few notes that may
help:
a) DrawOver 1.0 copyright Michael Everest 1986, is a converter to
EPSF from the PICT graphics norm of the Macintosh, a norm for which
there are many excellent drawing programs such as MacDraw. DrawOver
is distributed with Illustrator 88 on the Mac. It is aging inasmuch
as it handles the PICTs of more recent MacDraw versions less and
less well.
b) Illustrator 88 on the Mac by Adobe Corp is a MacDraw-like
program that uses the EPSF norm.
c) Macintosh output to LaserWriter printers is postscript code, and
can be diverted into a file. This file cannot be used as is, but a
header file can be added which with a few other changes produces a
(bulky) EPSF file. See the macps converter of unix, or OzTeX or the
$20 shareware Mac package AddLPrep copyright 1988 by SoftWare 101,
15151 Old Ranch road, Los Gatos CA. The output is I believe
equivalent at similar resolution to what the Macintosh-LaserWriter
combination produces. However, starting from the same PICT file,
method (a) often gives better results!
d) fig and xfig by Micah Beck, Cornell University
<beck@cs.cornell.edu> are MacDraw-like programs for unix and unix
X-windows, for which a translator transfig exists to EPSF norm.
e) Naked PostScript code. PostScript is a beautiful language, and
the three Adobe manuals are very helpful.
I am sure it would be extremely useful if readers would extend
and improve the above list! Here is a first response from Berthold
K.P. Horn:
(*) Aldus Freehand on the Mac is a more sophisticated tool for
generating graphic illustrations than Adobe Illustrator. Both are
constrained to basically two-dimensional patterns. Both can produce
output in EPS form.
(*) Micrografx Designer on the PC is a more sophisticated tool for
generating graphics illustrations than Adobe Illustrator. It is the
PC's answer to `MacEnvy', since it provides a Windows based tool
that is about as good as any on the Mac. Designer is also
constrained to basically two-dimensional patterns. It can produce
output in EPS form.
(*) There are also CAD/CAM applications that run on high end PC's,
Sun workstations that can handle `solid modelling' of three
dimensional objects, but they are an order of magnitude more
expensive, so few people have access to them.
(*) Illustrate on the Symbolics LispMachine was one of the first
drawing programs and is still used quite a bit. It can produce
output in EPS form. Very similar features to the other 2-D
illustration applications mentioned above.
(*) Screen Dumps. Another useful source of graphic illustrations
are screen dumps available on LispMachine, Windows on PC, and on Mac
in EPS form. OF course, they are in bitmap form so very limited in
quality and not resolution-independent, but useful for illustrating
program operations.
(*) Paint Programs. On the Mac and the PC there are programs that
instead of manipulating curves and areas work directly with bitmaps.
The output can be in EPS form. But same drawback as screendumps.
Not used much.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
END OF : EPSF graphics integration via TeX \special's
--- a gentle path out of chaos
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-----------------------------------------
------------------------------
Date: Fri, 22 Feb 91 08:53:27 +0000
From: MJH@UK.CO.KERNEL-TECHNOLOGY
Subject: DVI to 24-pin
Some time back in December '90, there was a little talk in this forum about
24-pin printer drivers. There are now lots of these printers on the market at
sensible prices, making them suitable for draft or home-based use by
budding TeX'sters. I saw no follow-up to these requests, so I wonder if
there is any further information is available. I assume that such drivers
must be common in DOS based environments, but now that UNIX is getting
cheaper - and unbundled - for 386 PCs, use in this UNIX environment must be
growing too. So, are there any such drivers? If so, are they acceptable
in terms of speed, quality and facilities? If not, are there any starting
points (eg, a DOS version which uses a comparable font format) from which
The development of a UNIX version may be started?
Mark J. Hewitt
bangpath: ...!ukc!kernel!mjh JANET: mjh@uk.co.kernel
voice: (+44) 532 444566 other: mjh@kernel.co.uk
fax: (+44) 532 425456 old style: mjh%uk.co.kernel@uk.ac.ukc
paper: Kernel Technology Ltd, Development Centre, 46 The Calls, Leeds,
LS2 7EY, West Yorkshire, UK
------------------------------
Date: Fri, 22 Feb 91 12:16:05 +0000
From: ABBOTTP@UK.AC.ASTON.VAX.SPOCK,
ABBOTTP "Peter Abbott - Computing Service"
Subject: EmTeX distribution from Aston
> fr/ Duarte Trigueiros
> Norwich 20/2/91
>
> Dear Peter,
>
> Thanks for sending emTeX. I am returning six HD 5 1/4 disks to replace
> those you kindly put to complete the lot.
>
> I also send you a few more disks because I believe some font libraries are
> missing. Here is the list of the fonts I've got:
>
> LJ_O LJ_H LJ_I LJ_2 LJ_3 LJ_5B
>
> The drivers for HP Laser Jet+ and for Screen complain about not finding the
> LJ_4. In fact, it's missing.
>
> Environment variables and paths seem correct.
>
> I also received the disk DVIPS2.21P with DVIPS on it. Is it the only disk
> required to run DVIPS? If not, I would like to have it all since here at
> UEA we have facilities for using PostScript printers.
>
> Enclosed is a cheque for paying the postage rate.
>
> Thanks again. Best regards,
>
> Duarte
Duarte
Your letter is of general interest to the wider community so a copy of
this message is being sent to the digest.
You are missing lj_4 and lj_5a simply because the ZIP files are too
large for the low density 3.5" and (so I am told) on both densities at
5.25". A member of the archivegroup is working on a procedure to split
ZIP files and this problem will eventually disappear.
I have had the same problem on my portable at home and found that by
backing up the zip files (DOS 3.3) the two ZIP files fitted onto 3 low
density 3.5" disks. I also discovered that by removing the reference to
lj_4 and lj_5a from the v.bat file that the previewer worked fine.
If anyone needs the lj_4 and lj_5a urgently then they can be supplied in
the usual way as backup (DOS 3.3 only). Otherwise the new zip split
should be here soon.
A bonus of the new zip split will be the ability to include other files
which are not currently available on the low density disks.
I have not yet loaded dvips2.zip onto my portable so cannot say if there
is anything missing. No doubt someone else can answer this question for
you.
Peter
------------------------------
Date: Sun, 24 Feb 91 14:01:31 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: Re: Changebars.sty
is anyone rewriting this style file to support a case statement
instead of an if...else construct for \special support? I could
happily hack it to work with dvips, but would prefer to have a more
acceptable framework agreed in advance
sebastian
------------------------------
Date: Mon, 25 Feb 91 10:41:26 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: Problem with M & S Font Selection Scheme
From: P.ABBOTT@UK.AC.ASTON
The following command has been used for the last two years when producing a
newsletter. When used with M & S font selection scheme the \rm is NOT obeyed
and the contents is then set in \bf. I had assumed that \rm and \bf are
series commands (Page 300 (section 2.2) TUGboat Vol 11 no 2).
Anyone know what I am doing wrong?
Peter
%
% majorsec is used to produce the heading VAX GENERAL etc
%
\newcommand?\majorsec?[1]?
\parbox?124mm???\huge\bf \special?greybox.ps?
\begin?center?#1\end?center??
\vspace?0.1in? ?
\addtocontents?toc??\protect\vspace?3pt??
\addtocontents?toc?? #1?
\addtocontents?toc??\protect\newline?
\addtocontents?toc??\protect\vspace?-8pt??
\addtocontents?toc??\protect\normalsize?
\addtocontents?toc??\protect\rm?
?
That depends on whether you are using the oldlfont or the newlfont
option. In the former case it should behave as before (i.e. old
lfonts.tex). With newlfont \rm changes only the family, \bf only the
series.
(Sorry for the ???????, I think it was UK.AC.RL striking again!!!)
Rainer Sch\"opf
Dr. Rainer Schoepf
Konrad-Zuse-Zentrum fuer Informationstechnik Berlin
Heilbronner Strasse 10
D-1000 Berlin 31
Federal Republic of Germany
<Schoepf@sc.ZIB-Berlin.dbp.de> or <Schoepf@sc.ZIB-Berlin.de>
------------------------------
Date: Mon, 25 Feb 91 10:46:42 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: Baselinestretch when using M & S font selection scheme
From: P.ABBOTT@UK.AC.ASTON
When using the new font selection scheme from M & S the baselinestretch
no longer has any effect.
To change to double line spacing
\def\baselinestretch{1.5}
gave the required result. What is the equivalent using the new font
selection scheme?
Peter Abbott
There was a glitch in the New Font Selection Scheme that caused the
\baselineskip not to be initialized properly. It was fixed in June
last year (I think). This fix solves the problem if your
\newcommand{\baselinestretch}{1.5}
is placed in the preamble of the document. If you want to change
\baselinestretch later on, somewhere within the document, you have to
force a size change, e.g.,
\newcommand{\baselinestretch}{1.5}
\small\normalsize
This is the same behaviour as before (i.e. with old LaTeX's font
selection); I hesitate to call it a feature, though.
Rainer Sch\"opf
------------------------------
Date: Mon, 25 Feb 91 09:48:07 +0000
From: CUDAT@UK.AC.WARWICK.CU
Subject: re: use of PK founts under MS-DOS
Brian Hamilton Kelly sent me some electronic mail:-
>Date: Thu, 21 FEB 91 11:00:27 GMT
>From: TEX@UK.AC.CRANFIELD.RMCS
>In a submission to UKTeX of Wed, 20 Feb 91 14:50:14 GMT,
>J M Hicks <CUDAT@UK.AC.WARWICK.CU> wrote:
>> Both DVISCRS and DVITOPS use the fount name, printer resolution
>> and fount magnification to find the required PK file for a fount.
>> To do this, DVITOPS can substitute (resolution x magnification)
>> in the name of a file it is looking for (the resolution is in
>> dots per inch). DVISCRS does something similar, but it
>> uses (resolution x magnification x 5).
>...
>>...
>The solution lies in your hands (well, actually in the configuration
>file, or in the /PF qualifier used on the DVISCRS command line): define
>the path for the packed pixel files as `C:\FONTS\DPI$r'; the `$r' means
>``substitute the result of computing resolution x magnification''.
>There's a different placeholder to specify ``compute the PXL file
>magnification'', which you seem to be using.
>...
Brian is quite right; all I had to do was to use $r and I could use
the same set of fount files with both programs.
The confusion stems, I think, from the description in my copy of
DVIDRV.ENG, the English translation of the German documentation.
It refers to (magnification) and (resolution) rather than
(magnification x resolution x 5) and (resolution x magnification).
The former is explained in more detail but I can't find a detailed
description of the latter. I have looked at the German original:
I can't be sure but it looks as though the translation has been faithful.
Perhaps I simply lack a knowledge of DVI device driver jargon.
Many thanks to Brian for putting me right.
- --
Jim Hicks, Computing Services, Warwick University, Coventry, England. CV4 7AL
Office: Coventry (STD O2O3) 523262
On JANET: cudat@UK.AC.WARWICK.CU
------------------------------
Date: Mon, 25 Feb 91 10:36:30 +0000
From: A42JR@UK.AC.POLY-EAST-LONDON
Subject: Euler fonts and MFJOB
Some time ago I wrote asking about compiling the Euler fonts using
emtex. I did receive some replies, but they were not all that useful.
Has anyone actually successfully comiled these fonts using MFJOB, or the
emtex MF. If so, how did they do it?
John Rostron
Division of Environmental Sciences,
Polytechnic of East London
Romford Rd, E15 4LZ
------------------------------
Date: Mon, 25 Feb 91 14:39:30 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: use of PK founts under MS-DOS
From: CUDAT@CU.WARWICK.AC.UK
I have recently been setting up LaTeX for someone on an IBM PC
compatible. I have been using DVISCRS (version 1.3i) from the emTeX
collection as a previewer, and DVITOPS (by James Clark)
to convert DVI files to PostScript.
Both DVISCRS and DVITOPS use the fount name, printer resolution
and fount magnification to find the required PK file for a fount.
To do this, DVITOPS can substitute (resolution x magnification)
in the name of a file it is looking for (the resolution is in
dots per inch). DVISCRS does something similar, but it
uses (resolution x magnification x 5).
This makes it awkward to have the previewer and the printer driver
use the same set of founts. (DVISCRS gives pretty good results
with 300 d.p.i. founts and it seems silly to have two sets of PK files
when one will do.) Fortunately DVITOPS is persistent enough
to look in all the MS-DOS directories it is given until it
finds exactly the right fount file, so I name the directories
according to emTeX's convention and tell DVITOPS about each
directory individually. This is a nuisance as the directory
names then need to be kept short so that they can all fit into
an MS-DOS environment variable.
Is there any chance that developers might be encouraged to agree
on the general principles of how to locate a required fount file?
This is yet another chapter of a very sad story...
The (resolution x magnification x 5) convention is an old one, and I
don't see any reason why it should still be used. Actually, I don't
see a reason why the directory names should contain the resolution.
There should be one directory for every output device (thus implicitly
or even explicitly containing the resolution of that particular
device), with subdirectories for different magnifications, each
one containing the appropriate .PK files. The names of these
subdirectories should not contain the resolution, but the
magnification, for a very simple reason: I find it very awkward to
remember that cmr10 for \magstephalf is contained in, say, pk329 for a
HP Laserjet, and in 1395pk for a 1270dpi Linotype. Instead, both
directories should be named something like "mag1095".
Driver programs should
(1) be able to read a font substitution definition file,
(2) have settable paths for the pk directories, preferably with
variable parts to conform to different conventions,
(3) no longer use .PXL files instead of .PK files.
I think we should finally put away those old conventions that have
ceased to be useful.
Rainer Sch\"opf
------------------------------
Date: Mon, 25 Feb 91 14:43:54 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: New smaller.sty
From: PLA@UK.AC.EDINBURGH.COMPUTER-SCIENCE.TARDIS
When acronyms or upper-case abbreviations are printed, it is good
typographic style to set them in a smaller type-size to avoid undue
emphasis (the output from WEB files is an example).
Of course, it is possible to use {\small TEXT} in body text, {\scriptsize
TEXT} in footnotes, etc. This falls over in section headings (even if
you can remember the correct size command) when a table of contents is
required (unless you really want a \Large word in there).
One way round this is to use something like {\sc text}. Unfortunately, this
only works for roman text, and the small caps font is often not available ov
er
a full range of sizes.
A better solution is a relative size-changing command, and one appeared in
TeXHaX(?) some time ago. Usage is {\smaller TEXT} and this works no
matter what the current type size. Since it invokes LaTeX size-changing
commands, it has the unfortunate side-effect of re-asserting roman type-face
.
It is possible to use {\smaller\em TEXT} in emphasized text, but this is
tedious and inelegant. There is still a problem with section headings -
{\smaller\bf TEXT} works fine in the heading itself, but again falls over in
the table of contents because the \bf creeps in.
The problem of `re-asserting roman type-face' disappears when the New
Font Selection Scheme is used with its newlfont option. This is only
one of the minor advantages of the NFSS.
Rainer Sch\"opf
------------------------------
Date: Mon, 25 Feb 91 16:47:28 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: Forward from Eberhard Mattes: [use of PK founts under MS-DOS]
> dots per inch). DVISCRS does something similar, but it
> uses (resolution x magnification x 5).
Use (for instance)
/pf\texfonts\canon\$rpk
with dviscrs to use resolution x magnification. $r will be replaced
with the font size (resolution x magnification). The 1.4d release
of dvidrv ceased to use resolution x magnification x 5, but still
supports $s for the old (pxl) convention.
> Driver programs should
> (1) be able to read a font substitution definition file,
> (2) have settable paths for the pk directories, preferably with
> variable parts to conform to different conventions,
> (3) no longer use .PXL files instead of .PK files.
All this can be done with the emTeX drivers. The
/texfonts/canon/cmr10.300pk
font naming scheme will be supported by the next release.
You may want to use dvips 5.47, it can read the emTeX font libraries.
Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
------------------------------
Date: Fri, 01 Mar 91 10:42:00 +0000
From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY
Subject: TUG Conference Proceedings Summaries
Christine Thiele has done a valiant task and compiled four files of
proceedings summaries from all TUG meetings since 1987. I have the
four file TUGPROC.1987, .1988, .1989, .1990 so I will upload them to the
archives...IF...
Can someone please post a summary of the correct addresses for the submission
of material to:
Aston
Ymir
Clarkson
Labrea
Heidelberg
so that I and others know exactly to whom stuff can/should be sent.
///Peter
------------------------------
Date: Fri, 22 Feb 91 14:15:00 +0000
From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY
Subject: Formation of ITALIC (Irish TeX And LaTeX Interest Community)
\magnification=\magstep1 \vsize=9truein \hsize=6truein \font\lit=cmti10 scaled
\magstep4 \font\mf=manfnt \font\sc=cmcsc10 \font\sltt=cmsltt10 \font\mrm=cmr10
scaled \magstep2 \font\msc=cmcsc10 scaled \magstep2 \def\larger{\let\rm=\mrm
\let\sc=\msc\rm} \def\LaTeX{{\rm L\kern-.36em\raise.3ex\hbox{\sc a}\kern-.15em
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}} \def\MetaFont{{\mf METAFONT}}
\def\csc#1{{\sc\lowercase{#1}}} \newbox\ibox\setbox\ibox=\hbox{{\mrm The}}
\parindent=\wd\ibox\advance\parindent by.5em \nopagenumbers
\setbox\ibox=\hbox{{\lit
%
i t a l i c
%
}}\newdimen\iwd\iwd=\wd\ibox \indent\box\ibox\par \setbox\ibox=\hbox to\iwd
{\leaders\hrule height2pt\hfill} \indent\box\ibox\smallskip\begingroup\larger
\item{The} Irish \TeX\ And \LaTeX\ Interest Community
\bigskip\endgroup\parskip=\smallskipamount\noindent\ignorespaces
At the \TeX90 conference in Cork last September there was a brief
meeting to discuss forming a group for Irish users of \TeX,
\LaTeX, \MetaFont\ and allied software.
Users in Ireland and abroad are now invited to signal their
interest in this group and join the mail discussion list {\tt
ITALIC-L} by sending a one-line electronic mail message to {\tt
LISTSERV@IRLEARN.BITNET} saying\hfil\break {\tt SUBSCRIBE
ITALIC-L {\sltt your\_real\_name}}
Present at the meeting were: Peter Flynn (UCC); M\i che\'al \'O
Searc\'o\i d (UCD); Brendan Dixon (UCD); John Finnegan (UCG); Tim
Murphy (TCD); John Simmie (UCG).
\noindent\ignorespaces
The following topics were discussed:
\item{1.} Name of the group: the acronym \csc{ITALIC} had been suggested
at the Texas \csc{TUG} conference by Pierre MacKay. Some
members of the meeting felt an Irish word related to
typography or calligraphy would be more appropriate:
suggestions to date have been: \csc{TACA} (\TeX\ Agus
Cl\'o-dhearadh Ailg\'eabrach---{\it \TeX\ and Algebraic Type
Design\/}); \csc{CELTIC} (Cl\'od\'o\i reacht \'E\i feachtach
Le \TeX\ \'I gC\'omhar---{\it Effective Printing together with
\TeX\/}); \csc{CL\'AR} (Cl\'ochurad\'o\i reacht Le\i ctreonach
Agus R\'\i omhchu\i d\i the---{\it Electronic and
Computer-Aided Typesetting\/}). \csc{TACA} was turned down
because the acronym has political connotations in Ireland.
Comments on the others' suitability (or new suggestions) are
welcomed. For the moment, \csc{ITALIC} remains the most
comprehensible internationally.
\item{2.} Mail distribution: \csc{BD} has set up {\tt ITALIC-L} on {\tt
LISTSERV@IRLEARN} with some file space for storing pointers to
the major repositories ({\it eg\/} filelists for Aston,
Heidelberg, \csc{YMIR}, Clarkson and Labrea), but not much in
the way of \TeX ware itself, as this is easily retrievable
from the aforementioned repositories.
\item{3.} \csc{PF} will supply a regularly-updated copy of the file {\tt
ASTON%ARCHIVE}, containing the complete list of files at Aston
in denormalised form, suitable for searching.
\item{4.} \csc{TM} is to investigate the inclusion of \csc{SGML} users
and software.
\item{5.} \csc{TM} is also to contact Irish \TeX ware authors to arrange
for their notification and eventual inclusion of their
software where permitted.
\item{6.} \csc{PF} is to contact the academic computer centres to sound
out the possibility of making an institutional membership fee
at a low level (instead of an individual membership fee) to
cover (initially) the cost of a meeting later this year (1991)
\bigskip\noindent\sl
Peter Flynn, 19 February 1991, Computer Centre, UCC
\hfil\break\tt
cbts8001@iruccvax.ucc.ie
\eject\end
------------------------------
Date: Mon, 25 Feb 91 10:35:49 +0100
From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY
Subject: Greek typesetting
From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY
A user here wants to do real Greek, and I know there are fonts or macros
to do this (Silvio Levy?) but where are they? There seems to be no mention
in the lists at Aston or Heidelberg.
///Peter
Three flavours of greek fonts have been installed in the MFSOURCE
FILELIST at LISTSERV@DHDURZ1.BITNET a few weeks ago.
Rainer Sch\"opf
------------------------------
Date: Mon, 25 Feb 91 18:04:21 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: UK TeX archive directory listings
In every directory of the UK TeX archive at UK.AC.TEX there is a file
called 00FILES.TXT which contains a list of the files in that directory.
I've just modified the program used to generate the list to provide
slightly more information on the type of file in the directory. Part of
a 'typical' listing is quoted below:
> Files matching DISK$TEX:[TEX-ARCHIVE.BINARY.VMS]*.*
> listed in reverse time order (listing updated: 25-Feb-91 16:38).
>
> Last change Size Type File specification
> --------------------------------------------------------------------------
> 22-Jan-91 03:23 3532 txt 00files.txt
> 4-Dec-90 17:46 2590 txt 00readme.txt
> 4-Dec-90 17:38 634 txt glib_index.dat
> 4-Dec-90 17:29 102 txt grlib-options.opt
> 4-Dec-90 13:09 16548 bin pktype.obj
> 4-Dec-90 13:08 29418 bin gftype.obj
> 4-Dec-90 13:06 29098 bin gftopxl.obj
> 4-Dec-90 12:48 116736 *VMS* cmplain.base
> 4-Dec-90 12:48 914 txt cmplain.inimf_lis
> 4-Dec-90 12:47 69632 *VMS* plain.base
...
> 3-Dec-90 12:28 51888 bin tangle.obj
> 24-Sep-90 12:22 - *DIR* drivers.dir
> 18-May-90 10:30 7172 bin wmerge.obj
> 17-Aug-89 16:51 16538 bin pktopx.obj
> 17-Aug-89 09:51 187158 bin bibtex.obj
> 23-Mar-88 16:59 13816 bin pxtopk.obj
> --------------------------------------------------------------------------
The possible file types and means of accessing them are:
txt - an ordinary text file.
Mail server access: yes
JANET NIFTP access: yes (ASCII/text mode)
bin - an 'ordinary' binary file.
Mail server access: yes (with FILES /ENCODE)
JANET NIFTP access: yes (binary mode)
*DIR* - a VAX/VMS directory file
Mail server access: DON'T !!
JANET NIFTP access: DON'T !!
*VMS* - a file with VAX/VMS specific attributes
Mail server access: yes (with FILE/ENCODE)
JANET NIFTP access: yes, but only from VAX/VMS
systems using TRANSFER /CODE=FAST
Niel Kempson
(Aston archive group)
------------------------------
Date: Thu, 28 Feb 91 18:16:06 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: Announcing DVItoLN03 V4.0 for VAX/VMS
DVItoLN03 Version 4.0 27th February 1991
========= =========== =================
=
This new release of DVItoLN03 provides support for virtual fonts, for
mixing portrait and landscape orientation in a document (including on
the same page) and for the newer DEClaser printers (LN05 & LN06), as
well as managing to effect a 25% increase in speed: it has been placed
in the UK TeX Archive as follows:
Sources, documentation and other support:
in [tex-archive.drivers.ln03.rmcs] -- get 00files.txt for details
Binary files (can only be transferred to a VAX, using TRANSFER/CODE=FAST):
in [tex-archive.binary.vms.drivers.dvitoln03]
DVITOLN03.OBJ -- ought to link under any version of VMS
DVITOLN03.EXE -- linked under VMS V5.3-1
DVITOLN03.BCK -- BACKUP save set containing the complete
distribution; sites able to effect NIFTP can
usefully fetch the whole shebang in one go.
Please ensure that you fetch and read the 00README.TXT file.
This implementation of DVItoLN03 has the following advantages over certain other
DVItoLN03 programs (these are not in order of importance; the new features are
at the end of the list):
i) It IS written in WEB, as opposed to C and other such kludgy languages.
ii) It downloads to the LN03's font memory the rasters for only those
characters actually used in the document. As such, it does not run out
of font memory just because you've used a few characters from each of a
large number of different fonts.
iii) It has a capacity for SIMPLE graphics inclusions. These have to be in a
format the LN03 understands (DEC sixels), and are copied verbatim into
the output file generated. (Can also manage Tektronix insertions
on the LN03-plus.)
iv) It works in landscape and portrait orientations.
v) It makes use of the ``proper'' VAX/VMS DCL interface for commands.
vi) It CAN print glyphs whose rasters are too large to be downloaded to the
LN03 as a font file (by performing a sixel graphics dump of the bitmap);
obviously this slows things down considerably!
vii) It CAN handle the invisible fonts used by SliTeX; each such character is
actually downloaded as a null character locator, ans is imaged by the
appropriate amount of whitespace.
viii) Either packed or unpacked font files (or both) may be provided in either
flat or rooted directory structures; if logical names are used to specify
these locations (as in the .CLD file provided), the files may be spread
over a number of different directories or volumes.
ix) The error messages are improved over earlier versions of the program, and
are now all indexed in the woven (WEAVEd?) WEB. They are also all listed
in the users' manual.
x) The program can now handle fonts with more then 128 characters, up to
TeX's limit of 256. Therefore, it can now process documents which use
Silvio Levy's Greek fonts.
xi) Retention of the log (.TYP) file may now be forced, suppressed, or allowed
to be determined by the success of the processing.
xii) Minor revisions and corrections have been made, in particular, it now
correctly understands the physical limitations to the imaging area.
xiii) Correct some log reports; report files read (except font files); provide
the /OUTPUT qualifier, to permit utilization of a scratch directory or
direct spooling to the output device.
xiv) Support for Flavio Rose \special commands, for drawing changebars, was
added by Robin Fairbairns at Laser Scan of Cambridge, UK.
xv) TeX Font Metrics (TFM files) are no longer sought in the hard-wired
directory TEX$FONTS:, but are instead controlled through the
/TFM_DIRECTORY qualifier.
xvi) Support for Virtual Fonts; the .VF files are sought in whatever is
specified as the value of the /VIRTUAL_DIRECTORY qualifier; users can
speed processing fractionally by specifying /NOVIRTUAL_DIRECTORY if it is
known that no virtual fonts are used in the document. If virtual fonts
are never used at your site, make this the default.
xvii) Fonts for which the program cannot find any rasters no longer cause the
processing to be abandoned; solid rules of appropriate dimensions are
substituted for each missing glyph.
xviii)Landscape and portrait mode material may be mixed within a document, and
even on a single page, through \special{landscape} and \special{portrait}.
However, some suitable style option still needs to be written to make this
feature useful rather than a curiosity!
xix) Qualifiers /LEFT_MARGIN and /TOP_MARGIN now take a dimension (eg 1in)
rather than being required to be entered in pixels; the additional
<physical unit> called PX (pixel) has been added to TeX's normal set.
xx) Support for the new DEClaser 2100 and 2200 printers has been provided by
Karsten Nyblad of the Danish Telecomms Research Lab. Users can select the
paper source tray, separately for the first and subsequent sheets, and
also the printing mode (simplex or duplex). There is even a duplex mode
for the ordinary LN03 (no, it doesn't really print two-sided!) which, by
interspersing blank sheets at appropriate points, produces a single-sided
master suitable for photocopying directly to a double-sided document.
xxi) Last, but definitely not least, the program has been speeded up, in both
the font mapping and the imaging phases, so that overall it runs
approximately 25% faster than V3.1-4.
Author:
B Hamilton Kelly
Royal Military College of Science
Shrivenham
SWINDON
UK SN6 8LA
Swindon (++44 793) 785252 [Direct line]
or via JANET: tex@uk.ac.cranfield.rmcs
INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk
Bitnet: tex@rmcs.cranfield.ac.uk
Good Luck!
Brian HAMILTON KELLY
------------------------------
Date: Mon, 25 Feb 91 13:48:15 +0700
From: JL2%EARN.DHDURZ1@UK.AC.EARN-RELAY
Subject: Official new lplain and splain files
The new versions of the files lplain.tex and splain.tex that have been
changed by Frank Mittelbach and myself to make them usable both with
TeX 2.x and TeX 3.x have been included into the official LaTeX
distribution at LaBrea.Stanford.edu. I have placed them into the
LATEX FILELIST at listserv@dhdurz1 as well.
Rainer Sch\"opf
DANTE coordinator for server machines
------------------------------
Date: Fri, 22 Feb 91 18:34:40 +0000
From: CHAA006@UK.AC.TEX
Subject: Additions to archive
The following files have been added to the archive, by courtesy of
Wayne Sullivan <WSulivan@Irlearn>.
Philip Taylor
- --------
Directory DISK$TEX:[TEX-ARCHIVE.WEB.MS-DOS.BREITENLOHNER]
DVICOPY.BOO;1 220/222 22-FEB-1991 18:24:04.56
GFTODVI.BOO;1 267/267 22-FEB-1991 18:09:51.28
TANGLE.BOO;1 412/414 12-FEB-1991 12:32:50.35
WEAVE.BOO;1 271/273 12-FEB-1991 12:02:30.69
Total of 4 files, 1170/1176 blocks.
- --------
Directory DISK$TEX:[TEX-ARCHIVE.METAFONT.MS-DOS.SBMF]
SBMF12.BOO;1 646/648 12-FEB-1991 11:32:40.57
Total of 1 file, 646/648 blocks.
- --------
Directory DISK$TEX:[TEX-ARCHIVE.TEX.V3.MS-DOS.SB-TEX]
SB32XET.BOO;1 732/732 22-FEB-1991 19:00:00.60
SB34TEX.BOO;1 712/714 22-FEB-1991 18:50:07.02
Total of 2 files, 1444/1446 blocks.
------------------------------
Date: Sun, 24 Feb 91 13:59:55 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: Re: Changebars.sty
the latest revision of a LaTeX style file supporting change bars,
either with LN03 specials, or PostScript specials (for Clark's
dvitops) is installed in the UK TeX Archive as
[tex-archive.latex.contrib]changebar.sty
Note that it is called changebar, not changebars!!!! this is because
that is what the previous version was called, and it makes life easier
for MSDOS and VM/CMS people
sebastian rahtz
------------------------------
Date: Mon, 25 Feb 91 18:22:47 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: Rail package for diagrams and TeX
I have placed Luc Rooijakkers `rail' package in the UK TeX Archive. It
helps making syntax diagrams (short description appended). The source
can be found in
[tex-archive.utils.rail]
sebastian rahtz
The Rail package, version 1.0 #0
--------------------------------
The Rail package allows you to include syntax diagrams (also known as
railroad diagrams) in a LaTeX document. A UNIX manual page and LaTeX
documentation are included. The package consists of a LaTeX style file
(rail.sty) and a C program (rail) and works in two passes not unlike
BibTeX. Diagrams are specified in a regular-expression like format
between \begin{rail} and \end{rail} brackets, and are formatted using
the standard LaTeX picture environment.
To use the package, you need a UNIX system with LaTeX. Actually, the
rail program should be portable to non-UNIX systems, but you need lex
and yacc (or compatible programs such as flex and bison) and a C
compiler. No fancy ANSI C constructions are used, and the program
passes lint quite silently.
--
Luc Rooijakkers Internet: lwj@cs.kun.nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271
------------------------------
Date: Mon, 25 Feb 91 18:25:07 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: new version of xdvi
I have placed the current release of the X11 previewer `xdvi' in the UK
TeX Archive in
[tex-archive.drivers.xdvi]
updating the previous release. This is patchlevel 11, and fixes some
bugs. Most notably (for me!) it no longer dies when asked for a
character which is not in a font. Worth upgrading for this alone.
Sebastian Rahtz
------------------------------
Date: Mon, 25 Feb 91 18:54:06 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: Rich Text Format conversion
Its not strictly TeXery, but as its quite small and as some people are
interested in it, I have installed a small set of programs by Paul
DuBois in the UK TeX Archive, which parse and translate Microsoft's
RTF format. Maybe someone will pick it up and write us an RTF -->
LaTeX or LaTeX--> RTF?
[tex-archive.utils.rtf]
Sebastian Rahtz
------------------------------
Date: Mon, 25 Feb 91 19:11:17 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: RE: Greek Typesetting
In a message UKTeX V91 #6 on Tue, 05 Feb 91 11:44:03 -0000,
P.TAYLOR@UK.AC.RHBNC.VAX wrote:
> Peter Flynn wrote:
>
> >>> A user here wants to do real Greek, and I know there are fonts or macros
> >>> to do this (Silvio Levy?) but where are they? There seems to be no mention
> >>> in the lists at Aston or Heidelberg.
>
> I have, and use, the fonts regularly. If the consensus is that they are
> not already in the archive, I'll put them there. But I suspect they are
> really there all along ...
Yes, they've all been there for ages; herewith the listing of the
relevant parent directory:
Files matching DISK$TEX:[TEX-ARCHIVE.FONTS.GREEK]*.*
listed in reverse time order (listing updated: 22-Jan-91 03:45).
Last change Size Type File specification
- -----------------------------------------------------------------------------
24-Sep-90 14:41 - DIR [tex-archive.fonts.greek]levy.dir
24-Sep-90 14:40 - DIR [tex-archive.fonts.greek]haralambous.dir
24-Sep-90 14:40 - DIR [tex-archive.fonts.greek]hamilton-kelly.dir
- -----------------------------------------------------------------------------
(The directory dates are newer than the files; this is the date on which
they were transferred to the new archive machine from the old one.)
Brian {Hamilton Kelly}
------------------------------
Date: Mon, 25 Feb 91 20:53:11 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: Apologies to UUCP clients of TeXserver
From an analysis of bounced mail, sent out by TeXserver@uk.ac.tex, in
response to requests from users connected via UUCP outside the UK, I've
discovered that the Janet-UUCP gateway at the University of Kent has
been bouncing all the mail, because the new archive machine UK.AC.TEX
appears not to be authorized to send international mail!
Peter Abbott did request UKC to add this new machine towards the end of
last year, and it did work for a while; now it's started to refuse
traffic. I'm asking Peter to chase UKC and ask for them to (re-)
register us.
I expect this will get fixed within a day or two, so if those users of
the archive who heard zilch in response to their requests would care to
try again, I have every hope that they'll work this time!
Sorry for curtailing your enjoyment!
Brian HK
------------------------------
Date: Mon, 25 Feb 91 21:04:10 +0000
From: TEX@UK.AC.CRANFIELD.RMCS
Subject: Would clients of Aston TeXserver please check disk quotas!
Would users of the Aston Archive mail server, TeXserver@Uk.Ac.TeX,
please ensure that they have sufficient room on their disks before
requesting information from the archive. I've just been analysing the
log of bounced mail, and a lot of it was due to traffic being returned
by the target machine because the requesting individual had either
insufficient disk quota, or the file system was full!
If you are unsure as to how much space any particular file might take,
you should fetch the 00files.txt from the relevant directory before
requesting the file itself; such files are only about 1--2kB long, but
something like [tex-archive]00directory.size is over 1MB in length.
Still, if you _have_ got room to keep a copy of this file, it'll save
you having to make DIRECTORY requests. The file is updated daily, so
it's more efficient to request a copy of this (or its smaller brother,
[tex-archive]00directory.list) rather than asking the TeXserver to
repeat all the work by saying DIRECTORY [tex-archive...]! (You'd be
amazed how often that one comes up.)
Requesting files when you've got insufficient space to hold them not
only results in your not getting them, but also wastes our limited
bandwidth for e-mail (9600Bd only!), not to mention the time taken in
the TeXserver sending them out, and the disk space of the TeXserver
taken up by the bounced traffic.
Brian HK
------------------------------
Date: Fri, 01 Mar 91 13:41:17 +0000
From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS
Subject: Convert MSWord to LaTeX (crude but useful)
I have installed the folliowing item in the UK TeX archive:
WD2LATEX.ZIP Convert MSWord to LaTeX (crude but useful)
boo-encoded as
[tex-archive.drivers.wd2latex]wd2latex.boo
on uk.ac.tex
It contains an executable and source. No experience or guarentees from
me - I have not even tried it. Some notes follow.
Sebastian Rahtz
- -------------
Written by Dr Connor J Thomas (cthomas@f.adelaide.edu.au).
The archive comes with both source and a binary.
Selected excerpt from the README file:
THE TRANSLATION PROGRAM works by interpreting Epson compatible printer
codes and translating a limited set of these to appropriate LaTeX code.
This approach is limited and cannot easily be used to interprete undelined
text; tables etc also present dificulties. But I do have some MSWORD
macros to help format basic LaTeX tables.
The present version will cope with:
IBM PC Hi-Ascii characters
Special LaTeX characters such as \ % { } etc.
Math characters such as + -
Italicized text
Bolded text
Superscripts and Subscripts
Small caps format
Characters bolded and to be printed in Epson Large type
will be interpreted as \section{text} but remember to bold first
and change size second (See notes in source code).
The program can be easily expanded to cope with more complex procedures.
------------------------------
UK TeX ARCHIVE at ASTON UNIVERSITY
*** JANET Interactive and NIFTP access ***
Host: uk.ac.tex (JANET DTE 000020120091)
Username: public Password: public
*** Files of interest ***
[tex-archive]00readme.txt
[tex-archive]00directory.list [tex-archive]00directory.size
[tex-archive]00directory_dates.list [tex-archive]00last30days.files
This year's UKTeX back issues are stored in the archive, in directory
[tex-archive.digests.uktex.91]
This year's TeXhax back issues are stored in the archive, in directory
[tex-archive.digests.texhax.91]
Latest TeXhax: #08
TeXMaG back issues are stored in the archive, in directory
[tex-archive.digests.tex-mag]
Latest TeXMaG: V5 N1
*** Media distributions ***
Washington Unix tape (28 March 1990)
TeX 2.993(==3.0), LaTeX 2.09, Metafont 1.9 (2.0)
Unix 4.2/3BSD & System V. Tar 1600bpi, blockfactor 20, 1 file.
Send one 2400' tape with return labels AND return postage.
VMS backup of the archive requires two 2400' tapes at 6250bpi.
VMS backup of TeX 2.991 plus PSprint requires one tape.
Exabyte 8mm tapes: same formats available as 1/2in tapes.
The following tapes are available: SONY Video 8 cassette P5 90MP,
MAXELL Video 8 cassette P5-90, TDK Video 8 cassette P5-90MPB
OzTeX (for Macintosh): Send 10 UNFORMATTED 800K disks with return postage.
emTeX (for MS-DOS): Send 11 UNFORMATTED 1.44Mb or 18 720K 3.5" disks,
or 12 UNFORMATTED 5.25" disks, with return postage.
emTeX is now distributed with a copy of `Baskerville' and documentation.
Please therefore send the disks in packing of A4 size or enclose an
A4 envelope.
*** Postage rates: all prices in pounds sterling ***
(make cheques payable to Aston University)
0.5" tapes: UK: 2.50 (one tape), 5.00 (two tapes).
Europe: 5.00 (one tape), 9.00 (two tapes).
Outside Europe please enquire.
8mm tapes: UK: 1.00, Europe: 2.00.
DC600A cartridges:
UK: 1.00, Europe: 2.00.
Diskettes:
Quantity/Size Europe World UK 1st UK 2nd
18/3.5" 3.10 5.10 1.40 1.10
11/3.5" 1.80 2.90 0.80 0.65
18/5.25" 1.20 2.00 0.60 0.50
11/5.25" 0.80 1.30 0.50 0.35
*** Postal address ***
Peter Abbott,
Computing Service, Aston University, Aston Triangle, Birmingham B4 7ET
(Please include SELF-ADDRESSED ADHESIVE LABELS for return postage).
*** UK TeX Users Group ***
For details, contact
Malcolm Clark or Geeti Granger
IRS John Wiley & Sons
Polytechnic of Central London Baffins Lane
115 New Cavendish Street Chichester
London W1M 8JS W Sussex PO19 1UD
email: malcolmc@uk.ac.pcl.mole
End of UKTeX Digest
*******************