[comp.text] TeXhax Digest V89 #115

TeXhax@cs.washington.edu (TeXhax Digest) (12/31/89)

TeXhax Digest    Tuesday, December 26, 1989  Volume 89 : Issue 115

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:         

                            TeX Previewers
              TeX/LaTeX style sheets for economic journals
            TeX and Soviet rules on camera ready submissions
                    Followup of various requests
              I was asked a question about font files
                A style option to get wider headers

-----------------------------------------------------------------------

Date: Fri,  8 Dec 89 13:28:50 EDT
From: "ATMCLU::AL6169"@UACSC1.ALBANY.EDU
Subject: TeX Previewers
Keywords: previewers, TeX

Hello!

I'm looking for a Tex Previewer for the Vax/MicroVax runining VMS 5.2.
We have VT100, VT240, VT340, and Vax workstation-type terminals, and we'd like 
to be able to preview TeX documents before sending them to the laser printer.
If you know of any such previewers for any or all of the terminal types listed 
above, I would like to know how we might obtain one of them, and how well they
perform.  Of course, cheap or free previewers available through public domain 
are of special interest to us.

Please mail responses directly to :
                                  BITNET:  Al6169@albnyvms
                                INTERNET:  al6169@uacsc1.albany.edu

Andy

-------------------------------------------------------------------------------

Date: 7 December 89, 12:15:54 PDT
From: REGANZ@UCLASSCF
Subject: TeX/LaTeX style sheets for economic journals
Keywords: TeX, LaTeX, economic style sheets

Do you know if there are any macro packages or style sheets for TeX or LaTeX
for use in formatting documents according to the style of leading economic
journals.

Michael Ganz

------------------------------------------------------------------------------

Date: Thu, 7 Dec 89 23:52 EDT
From: <DLV%CUNYVMS1.BITNET@UWAVM.ACS.WASHINGTON.EDU>
Subject: TeX and Soviet rules on camera ready submissions
Keywords: TeX, camera ready submission

I've been involved with the Russian TeX effort and I discussed TeX some time
ago with a well-known Soviet mathematician who has had some experience with
submitting camera-ready stuff to Soviet publications. He pointed out that there
exists a GOST (standard) (don't know the #; I suspect it's 7.3--77 <Originaly
tekstovye avtorskie i izdatel{\cprime}skie>, of which I don't have a copy) that
limits the number of consecutive lines that can end with hyphens (discretionary
breaks). The limit is pretty liberal (sometimes 10, sometimes 5, I believe),
but apparently there have been cases when someone would submit a paper with 5+
consecutive breaks and it would be rejected for that reason. He was concerned
with the fact that, as far as we could determine, TeX does not allow one to
control the # of consecutive broken lines. Now, setting \doublehyphendemerits
to something pretty large (like 10000) would most likely prevent this. But,
suppose your \hsize is really small (like you're doing a multi-column
document), and you can live with double or triple hyphens: anything less than
certain n. (Page 454 in the TeXbook shows what can happen with a large negative
\doublehyphendemerits---lots of consecutive broken lines). Various people have
been proposing various additions for 3.0, so I figured I'll throw in my
2x12.5c's worth: How about adding a new primitive, \maxconsechyphens, a number
>=1 and changing the paragraph code so that if the number of consecutive
hyphens is <=n, everything it fine and no additional badness is introduced,
whereas if it's >n, a different arrangement (possibly with greater badness)
must be sought. This would make the Soviets very happy. I understand that
paragraph code is being changed in 3.0 in some esoteric way almost beyond my
understanding, so perhaps another addition is also possible.

Yet another suggestion (YAS) from:
Dimitri Vulis
Department of Mathematics
City University of New York Graduate Center

--------------------------------------------------------------------------

Date: Thu, 7 Dec 89 16:07 GMT
From: CBTS8001%IRUCCVAX.UCC.IE@UWAVM.ACS.WASHINGTON.EDU
Subject: Followup of various requests
Keywords: MacPaint, CM, Mass-11, LaTeX, \pounds, Cork, REDUCE, languages

I have just gotten round to reading TeXhaxen 90--100 and there are one or
two (well, several) things that seem to have gone uncommented:

Phil Windley <windley@cheetah.ucdavis.edu> asks:

>Is there a way of taking pictures generated on a Macintosh and including
>them in TeX documents?

Arbortxt's Hewlett-Packard LaserJet driver, DVIHP, has this ability and
comes with a program called PAINTHP (or something like), which takes a
MacPaint file and makes a HP PCL3 file from it which can then be included
in the document with a \special. It works, 'cos their own documentation
comes with just such a drawing embedded (an Escher waterfall). Arbortxt's
tech support can be contacted on <cld@arbortxt.com> (I think, that's from
memory).

Philip Taylor <p.taylor@vaxa.rhbnc.ac.uk> asks:

>I wonder if anyone has done any work on increasing the meta-ness of
>Computer Modern.

The CM series follows the traditional printer's pattern of Roman, Italic,
Bold, Small Caps and Slanted. What Phil proposes is a departure from this
pattern, along the lines of font-generator programs like Glyphix, where
the variations from Roman are merely attributes applied as parameters.
While I can see a certain attraction in the idea from the point of view
of symmetry, I feel it has its pitfalls as well: an italic blackletter
(Old English Italic?) perhaps, or Pilgrim Outline, anyone? Yes, it has
its valid uses in display work, but I seriously query its need in fine
typography, which is what we currently have. Jensen managed quite well
without slanted small caps. By all means let us have the facility, and
I am happy that Phil, at least, is capable of handling it well, but we
would need to get much deeper into the typographical training business
if we want to go down this path (maybe we should anyway!)

On the LaTeX-to-Mass--11 conversion problem,
*pause for commercial*
Our campus company, FreeText Technology, is working on a programmable
wordprocessor and text-format conversion program right now. I have no
release date, but 1990 should bring some relief to those who have text
conversion problems, provided they know (or can point to a reference
for) the internal format of the systems involved. No guarantees, but
FreeText are on +353 21 277904 and <freetext@vax1.ucc.ie>
Declaration of interest: I am personally involved in this project, so
I'm completely biased.
*End of commercial*


On the LaTeX $\pounds$ problem, I must repeat my comment of two years
ago: the right pounds sign to use in cmr10 text is in cmu10, not cmti10.
Leslie Lamport is aware of this, but I do not know if this has been
reflected in newer versions of LaTex, cos I don't use it much. Users please
fix, 'cos an italic pounds sign looks silly in upright text.

Allan Adler <ara@lom1.math.yale.edu> asked about copies of papers for the Cork
conference next year. Yes, they will be published, probably commercially, so
the full texts will not be distributed in machine-readable form (anyway, many
of them will contain graphics, and non-TeXable ones at that). Abstracts and
any software/macros in the public domain will of course be available from the
usual servers.

Allan also asks about MACSYMA or REDUCE translation to TeX. There was a paper
presented at the Karlsruhe conference in September on a REDUCE-to-TeX
interface. I haven't got the details beside me right now but I can dig them up
if needed (or contact someone else who was there).

Tor Lillqvist <tml@hemuli.atk.vtt.fi> asks for Swedish to be #1 and Finnish to
be #2 in the new TeX. While I have no objection, I think it would be better to
use the International Standard Country Codes (numeric form) which are ISO
something-or-other (some standards whizz will tell you the number), as these
are already the accepted numbering system (but I don't know if they fit into a
1--256 range).

Thank you to all those people who sent me details of various servers around the
networks. I hope to have the updated SERVERS.TEX out by the end of the month.

    _ ___  _    Peter Flynn, Computer Centre, University College, Cork, Ireland
|) |_  |  |_ |) Phone: +353 21 276871 x2609   Fax: +353 21 277194 or 270579
|  |_  |  |_ |\ Email: <cbts8001@vax1.ucc.ie> or <cbts8001@iruccvax.bitnet>

--------------------------------------------------------------------------

Date:  Wed, 06 Dec 89 10:41:47 IST
From: "Jacques J. Goldberg" <PHR00JG%TECHNION@UWAVM.ACS.WASHINGTON.EDU>
Subject: I was asked a question about font files
Keywords: fonts

     TeX users should know the following things.
     ===========================================

1) TeX creates a .dvi file from a .tex file - I am sure you know THAT.
2) A specific ``DVIdriver'' is required to transform the contents of a .dvi
file into something a human brain can understand. You know that too.
3) The DVIdriver MUST know exactly where you want ink on paper, or light on
a screen, to produce the image of a given glyph ( ``drawing'' of a given
ASCII code in a given font). The DVIdriver therefore needs a bit RASTER
image for each glyph, and this raster is device (printer, display) dependent,
at least, but not only, because devices have different resolutions.
4) TeX does *NOT* need to know the detailed shape of a glyph to ``compose''
a page of text, it only needs to know the size of the box encompassing the
glyph and some boundary (neighboring) conditions.
5) .tfm files contain ONLY the GLOBAL information required by TeX, and are
therefore device independent. In addition TeX knows enough arithmetics to be
able to magnify/demagnify such information by any arbitrary factor.
6) DVIdrivers require the RASTER description of the glyphs; some are happy
with that only, others also fetch some information from the .tfm files, but
this is a detail.
7) For historical and technical reasons there are many FORMATS to the raster
files. .pxl is obsolete but still used by some old drivers, .pk are by far
most efficient specially when it comes to saving disk space, .gf are produced
on the way to making fonts anyway, while .epf and .aaf for example are very
special formats respectively required by one of the popular Epson printer
drivers and by the Apollo Previewer.
8) DVI_drivers are *NOT* supposed to be able to magnify fonts (some try with
rather desastrous results which make beautiful TeX output look worse than lousy
word processors would do). DVI_drivers expect to find the magnified rasters
in a specific directory structure, and the user is responsible for not invoking
magnifications for which no raster files exist; again TeX does NOT check that
the driver will or not be able to print out a font at the requested magnifica-
tion. This is NOT TeX's business.
9) The program METAFONT reads a font definition file, and actual device
parameters, and magnification, (Ok , experts know that these parameters can
be written inside the font definition, at least by default, this is not the
issue here), etc..., to generate TWO output files per input font file
definition. The input is a ``.mf'' file and the two outputs are the
corresponding ``.tfm'' and ``.gf'' files. So if you wish to make a font at
5 different magnifications you have to run 5 times Metafont, on the same .mf
(unless you plug the mag in it, a very bad practice, and then you of course
must edit it each time, better enter the mag on the command line). Or if you
wish to create the font for 3 different devices ( a dot matrix printer, a laser
printer, a display) you again must run 3 times Metafont with the correct
printer definition. ALL THESE RUNS WILL ALWAYS REPRODUCE THE SAME .tfm FILE.
Each will however yield a DIFFERENT .gf file.
10) There is a utility GFtoPK that converts GF files into PK format. Why not
use GF files right away? Some DVI_drivers indeed have this capability, but a GF
font takes 3 times as much disk space as a PK.
11) There is a PKtoPXL utility for those whose DVI_drivers insist on PXL.
12) There is a PXLtoEPF utility for those who need EPF format.
13) There is a PXLtoAAF utility for those who need AAF format.
14) BY THE WAY, you can even make .tfm files from ADOBE POSTSCRIPT fonts
stored in a Postscript printer. It works nice, but you stop being compatible
with TeX_World. Better think twice before doing that -- that's why I don't
say how here. Just likewise, you can make .tfm files out of fonts built in the
IBM 3812 printer. I am sure the list is not exhaustive.

     TeX users who further intend to create more font files may find the
     ===================================================================
     following details helpful.
     ==========================

    I hope it is clear by now that if you wish to make for example a cmr10 font
magnified by a factor 1.019 for some Epson printer driver which needs EPF files
you will need to successively run METAFONT on CMR10.MF with the proper device
and magnification specified, GFtoPK on CMR10.245GF  (245=1.019x240 dots per in.
which is the resolution of that printer), PKtoPXL on CMR10.245PK, and finally
PXLtoEPF on CMR10.1223PXL (1223=1.019x240xHistorical_factor_five) to make
CMR10.EPF to be stored in a  \1223\ subdirectory on your PC.

Some sites have METAFONT working but people do not know how to use it:
Invoke it with the command ``mf''
At prompt ** reply &plain
At prompt *  reply input waits
At prompt * reply mode:=epson;     EXACTLY AS SHOWN
At prompt * reply mag=1.019;   (or mag=magstep 2; for example if using regular
                                conventional steps of x1.2 each)
At prompt * reply input cmr10

Now wait and see. Within some time you will get TWO files, MFPUT.TFM and
MFPUT.245GF. If you do not yet have ( new font) cmr10.tfm, copy mfput.tfm
under you new name to where your .tfm files are located. If you already have
it there, no need to waste your time, forget about mfput.tfm.
Rename MFPUT.245GF to cmr10.245GF (or whatever font you are trying to create,
cmr10 was just an example, remember), reformat and relocate to what you need
and where you need it.

If your Metafont cannot find ``waits.mf'', request it from any TeXpert forum.
If you get a .2602 GF output file, the waits.mf does not include your
favourite printer; update it; printer parameters for almost anything on
the market can be found in TuGBoat.

                                          Good luck - Jacques

------------------------------------------------------------------------------

Date: Fri, 8 Dec 89 21:37 MET
From: "Johannes L. Braams" <JL_Braams%pttrnl.nl@UWAVM.ACS.WASHINGTON.EDU>
Subject: A style option to get wider headers
Keywords: LaTeX, headers, style option

    Hi all,

        In the past several people have asked about how to get headers
        and or footers that were wider than the main body of the text.
        Also requests have shown up in TeXhax about a line in the header
        extending the full width of the headline.
        Triggered by a recent request in UKTeX I hereby submit a style option
        that does both. It is intended for use with the book style (for this
        it was originally created), but can be easily modified to be used
        with any of the other standard LaTeX styles. It currently redefines
        the headings plainstyle, but could also define a new pagestyle.
        I would be happy to receive any comments or suggestions for
        modifications for it. If the maintainers of the sun.soe.clarkson
        archive feel it might a good idea to put it there, please do so.

    Regards,

        Johannes Braams

PTT Research Neher Laboratorium,        P.O. box 421,
2260 AK Leidschendam,                   The Netherlands.
Phone    : +31 70 435051                E-mail : JL_Braams@pttrnl.nl
%-----------------------------------------------------------------------------

E-mail was :
    EARN/BITnet : BRAAMS@HLSDNL5   UUCP        : hp4nl!dnlunx!johannes
    SURFnet     : DNLTS::BRAAMS    INTERnet    : BRAAMS%HLSDNL5@CUNYVM.cuny.edu
 PSS (DATAnet1) : +204 1170358::BRAAMS
%------------------------------------------------------------------------------
%
% File : lh.sty
%        For use with LaTeX version 2.09
%
% Copyright : Johannes Braams (BRAAMS@HLSDNL5.BITNet or JL_Braams@pttrnl.nl)
%             This file may be distributed as long as the copyright
%             notice is distributed with it.
% Original : 23-MAR-1989
% Modified : 31-JUL-1989 wider headers
%
% This file redefines the headings pagestyle to include a line
% in the header. The width of the line is equal to the width of the text.
%
% This file is intended for use with the book style option because
% it enables the 'headings' pagestyle by default
%
%    Define the dimension for the header
%
\newdimen\headwidth
%
%    Make the heading as wide as the text plus the marginpar's
%
\headwidth\textwidth
\advance\headwidth by \marginparsep \advance\headwidth by \marginparwidth
%
%        We need some extra boxes for the headers
%
\newbox\et@p\newbox\ot@p
%
% Define a box to contain the line
%
\newbox\@linebox
\setbox\@linebox\hbox \bgroup \rule[-8\fboxrule]{\headwidth}{\fboxrule} \egroup
\wd\@linebox 0pt
%
% Now redefine the 'headings' page style (taken from report.doc)
% Definition of 'headings' page style
%  Note the use of ##1 for parameter of \def\chaptermark inside the
%  \def\ps@headings.
%
\if@twoside         % If two-sided printing.
\def\ps@headings{\let\@mkboth\markboth
%
%    Define commands to fill two heading boxes
%
\def\mot@p{\setbox\ot@p\vbox to\headheight{%
\hbox to \headwidth{\copy\@linebox%
\hbox{}\sl \rightmark \hfil \rm\thepage}% Right heading.
}\wd\ot@p\textwidth}
%
\def\met@p{\setbox\et@p\vbox to\headheight{%
\hbox to \headwidth{\copy\@linebox%
\rm \thepage\hfil \sl \leftmark\null}%        Left heading.
}\wd\et@p\textwidth}
%
\def\@oddfoot{}\def\@evenfoot{}%       No feet.
\def\@evenhead{\hskip-\marginparwidth\hskip-\marginparsep\met@p%
\box\et@p\hfill\null}%% Left heading
\def\@oddhead{\mot@p\box\ot@p}%% Right heading.
%
\def\chaptermark##1{\markboth {\ifnum \c@secnumdepth >\m@ne
      \@chapapp\ \thechapter. \ \fi ##1}{}}%
\def\sectionmark##1{\markright {\ifnum \c@secnumdepth >\z@
   \thesection. \ \fi ##1}}}
\else               % If one-sided printing.
\def\ps@headings{\let\@mkboth\markboth
%
%    Define a command to fill the heading box
%
\def\mot@p{\setbox\ot@p\vbox to\headheight{%
\hbox to \headwidth{\copy\@linebox%
\hbox{}\sl \rightmark \hfil \rm\thepage}% Right heading.
}\wd\ot@p\textwidth}
%
\def\@oddhead{\mot@p\box\ot@p}\let\@evenhead\@oddhead% Headings.
\def\@oddfoot{}\def\@evenfoot{}%     No feet.
\def\chaptermark##1{\markright {\ifnum \c@secnumdepth >\m@ne
  \@chapapp\ \thechapter. \ \fi ##1}}}
\fi
%
%  Reactivate the headings pagestyle
%
\ps@headings

-----------------------------------------------------------------------

%%% 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
**************************
-------