TeXhax Digest Thursday, 4 Nov 1993 Volume 93 : Issue 015
% The TeXhax Digest is brought to you as a service of the TeX Users Group %
% and UK TeX Users Group in cooperation with the UK TeX Archive group %
Today's Topics:
Bibliographic software, Toronto, Canada
Re: ASCII Typesetting from a LaTeX file
Inserting graphics in LaTeX documents
Re: Raw encoding for type1 text fonts (TeXhax93.014)
Macros for AMS-TeX?
Postscript driver for HP9000/700 series workstations.
FTP site for TeX for OpenVMS
Printing Sanskrit
Spacing in Bibliography
Metafont settings in DECUS distribution?
Flushing Inserts ('\midinsert', '\topinsert', etc.)
Info needed on VF files (Q)
How do you single-space captions in a double-spaced document?
Converting troff to TeX?
Virtual fonts, aliases problem in LaTeX and DVIPS.
Elsevier Science announces availability of ESP-LaTeX
New version of subeqnarray available shortly
CTAN-US usage summary -- September 1993
Administrivia:
Moderators: David Osborne and Peter Abbott
Contributions: TeXhax@tex.ac.uk
Administration, subscription and unsubscription requests:
TeXhax-request@tex.ac.uk
M O D E R A T O R ' S N O T E
Apologies for the delay in sending out this issue,
due to vacations and work on other projects.
I'm trying to keep to a two-weekly cycle for TeXhax,
but that's not always successful!
---DAO
----------------------------------------------------------------------
Date: Tue, 05 Oct 1993 17:22:32 -0000
From: David_Rhead@vme.ccc.nottingham.ac.uk
Subject: Bibliographic software, Toronto, Canada
There's a firm in Toronto that produces an MS-DOS bibliographic database
system. The firm is Balboa Software, and the software is Library Master.
(I.e., Library Master is in some respects a potential proprietary
alternative to BibTeX. It has database-y things that BibTeX doesn't.
Conversely, BibTeX has some things that Library Master doesn't.)
I say "potential alternative" because Library Master is currently aimed at
"wordprocessor users". I've had mail from Balboa's Harry Hahne to the
effect that they'd be interested in trying to do a (La)TeX option.
Is there anyone in the Toronto area who'd be interested in collaborating
with them? E.g., get emTeX working on a Balboa PC, tell Balboa what
sort of interface would seem natural to TeX users?
If so, please contact Harry Hahne and/or me. Harry can be mailed as
hahne@epas.utoronto.ca
------------------------------
Date: Wed, 06 Oct 1993 09:06:34 -0000
From: S.J.Bishop.topix01@oasis.icl.co.uk
Subject: Re: ASCII Typesetting from a LaTeX file
I had good results with the dvi2tty program, which came with my
(1990 vintage) UNIX TeX distribution. It didn't need any
special style files, although I used a few minor tweaks to
please the corporate word processing system. Surprisingly
enough, I didn't need to set the document in a typewriter font
to get acceptable output. Stephen
------------------------------
Date: Wed, 06 Oct 1993 13:04:25
From: heitor@GPEB.UFSC.BR
Subject: Inserting graphics in LaTeX documents
Hello all:
Does anybody have some hint on how to insert in Latex documents,
graphic files in any well-known graphic format (e.g. .PCX, .GIF, etc...),
or from spreadsheet charts? I'm using PcTeX, running under DOS, and I noticed
that \special{... doesn't work at all.
Any help will be appreciated!
Thanks,
Heitor S. Lopes
heitor@gpeb.ufsc.br
eel3hsl@ibm.ufsc.br
------------------------------
Date: Wed, 06 Oct 1993 16:02:20 -0700
From: mackay@edu.washington.cs (Pierre MacKay)
Subject: Re: Raw encoding for type1 text fonts (TeXhax93.014)
Wow!!! No need for an outright war though. I really rather
like the fact that my message generated some interest.
> The combination of (i) input encoding, (ii) output encoding, plus
> (iii) virtual font permutation of numeric codes between 0 - 255 is
> unneccessarily complex and confusing.
If a stable input coding is possible (which is to some extent brought
into question below), the confusion is minimised. That's the idea.
> A much simpler approach just uses the idea of the encoding vector per
> se. That is, a mapping from numeric codes (0 - 255) to glyph names.
> DVI processors need the capability to reencode a font on the fly
> anyway, and the encoding vector provides the mechanism.
In what {\em available} driver? I have the problem of trying to make a
variety of accented glyphs available in a variety of environments,
where even the assumption of VF capabilities is questionable, but
where it is at least possible to suggest to the user that an upgrade
to VF capability is a good idea. Alternatively the dvidvi tool makes
it possible to unravel the VF mappings so that a simple-minded driver
can handle them.
> Obviously, ONE mapping instead of THREE mappings in series is much
> easier to understand and implement, and is in fact all that is needed.
But tools to do this are not generally available, to the best of my knowledge.
> It IS possible to make TFM files complete with proper ligature and
> kerning information, WITHOUT virtual fonts. And it certainly is a lot
> less confusing.
Yes, it is, in any number of ways---VPtoVF produces just such a
TFM, and if you have a way to avoid the VF file, I guess that's OK too.
> Virtual fonts have many interesting applications, but they are NOT needed
> for reencoding, and in fact, in and of themselves are quite inadequate for
> reencoding. The reason is that virtual fonts per se can only provide a
> PERMUTATION of the encoding vector, since they ONLY deal with numeric
> codes --- because VF, like TeX itself treat characters as numbers.
> Hence unencoded characters CANNOT be made accessible by the VF mechanism
> itself. Which is why all DVI drivers need in ADDITION a mechanism for
> actually reencoding a font. And once you have THAT, you do not need
> to use the numeric permutation of the VF to achieve reencoding!
> It is easy to be mislead by one particular implementation, which
> (i) forces one to use VF whenever using anything but bitmapped CM fonts,
> and which (ii) forces use of a complex sequence of three mappings rather th
an
> simply the single overall encoding, and (iii) cannot create TFM files
> complete with ligatures and kerning WITHOUT resorting to VF.
This assumes that the only problem is remapping. It isn't. Let's
just take the simple problem of f-ligatures, which in many existing
fonts are split between regular and "expert" layouts (which does
lamentable things to TeX's ligature and hyphenation capabilities).
What VF allows is the ability to make up a tfm that will ultimately call out
characters from more than one file of glyphs, or to supplement
defective fonts (e.g. a font with lots of nice directional arrows, but
all pointing to the west half of the compass) by incorporating Postscript
adjustments.
> The set of available glyphs is only consistent amongst Adobe fonts
> (which uses the same basic set of 228 glyphs for most text fonts).
> Other vendors implement other sets of glyphs. Lucida Bright text fonts for
> example have many additional glyphs not found in Adobe text fonts (for a
> total of 247). An approach based on a fixed `input encoding' that may
> not cover these extra characters is obviously inferior to one using a
> single encoding vector. It also cannot cope with the case where there
> are more than 256 glyphs in a font (Lucida Sans Linedraw has 400).
> There are many fonts that have more than 256 characters, including some
> of the Lucida family (Lucida UNICODE has over a thousand). You cannot
> deal with all of these using a fixed `input encoding'. If, however, you
> drop the idea of THREE sequential mappings and simple use the idea of an
> encoding vector there is no issue here. You just specify what glyph
> you want each number to call up. And your driver should allow you to
> use the same basic font under two TFM names with different encoding.
> Of course, without partial font downloading of Type 1 fonts (provided
> only by DVIPSONE), working with these large fonts (like the IBM
> version of Courier) can become quite unwieldy.
Especially in the case of METAFONT output, but not alone there, VF
techniques allow me to
"use the same basic font under two TFM names with different encoding."
That is one of the things I like best about
them. It is possible to make a single font up with different sets of
ligatures and even with looser or tighter kerning (and I do NOT mean
tracking). Unicode may have over a thousand registered glyphs, but it
happens to omit the couple of dozen that are used by orientalist scholars all
over the world for non latin-letter languages in transcription. One
of the chief reasons for working with VF was to supply these for
Turkish and for Arabic in Roman transcription. Since the Greek fonts
produced by all the major foundries I know of are aggressively
monotone (Monotype half-promises a Porson Greek, but the last time I
asked the promise was well into the future) VF is needed for Greek as
well.
> There is no need for separate `raw' TFM and another TFM for a font.
> Why use two TFM files when one will do? One CAN construct a single
> TFM file complete with ligatures and kerning based on any user specified
> encoding, as already stated above.
In the case of METAFONT output, the complete tfm as distributed can be
used as a raw TFM. That works because TeXText encoding is as
predictable as Adobe Standard Encoding. What raw fonts need is
predictable encoding. I suppose there may be other ways, but I have
found it serves very well to supply the needed accent composites even
for Computer Modern (or Concrete, or Pandora) by creating (e.g.)
cmr10.afm and running it through the afm2tfm and vptovf processes.
There may be a better way, but this uses existing tools and has the
virtue that the results can be made available to a wide variety of
users who need only to be sure that they have VF capabilities.
> Also, if you take the `three mapping' approach, you want to make sure
> that the composite characters ARE in the encoding. You do not want to
> use TeX's \accent to construct composites.
Granted---that is exactly the reason for working with VF and providing
preset and carefully adjusted composites.
> Nor should the virtual font
> mechanism be used to construct composites that the font designer has
> already created, presumably with careful attention to positioning, and in
> some cases by actually designing separate glyphs (for example, shallower
> accents for upper case characters than for lower case).
There are a few such fonts, and clearly Lucida should have been added
to the mention of Adobe Caslon and Garamond. But the majority, even
including some of the best classical designs, use composites. Should
the composite recipes in officially issued afm files be considered to
be barefaced lies? I agree entirely about the flatter accents for
Upper case, and in some conventions the Upper Case letters are
squatted down so that the accent does not project quite so alarmingly
over the type shoulder. For a given publication in a given font I am
prepared to work these refinements out even in a font that does not
otherwise have them. But then I have to use VF composites to create
the composite glyphs. To achieve this it is commonly necessary to
take the substrate letter from one font and the accent from another
(for example, a transformed copy of the substrate font). I regret
having to second-guess the designer but it is all part of the problem
created by the open-ended nature of accented character sets. Remember
that even Unicode lacks many accent combinations that are in
widespread international use for Arabic, Persian Turkish in Romanized
transcription.
> Almost all text fonts have separate character programs for composite
> characters, hence these are real characters in their own right. True, in
> many cases these character programs do use either the `seac' Type 1
> operator, or `Subr' calls and hence similar shapes can be achieved by
> combining the base and accent character with suitable positioning. However,
> in some cases the rendering will not be as good at low resolution, and most
> fonts treat at least Ccedilla, ccedilla, and Aring as complete separate
> glyphs that cannot be achieved by overprinting (The reason is that one does
> not want overlapping contours when the character is `stroked' instead of
> `filled').
I seem to remember that I recommended leaving the Ccedilla and ccedilla
as encoded simplex characters, even though about half the fonts I am
looking at treat them as composites. Aring is a composite in all the fonts
I presently have available to study, though I recognize that the taste
of the literate public most likely to use the letter disaproves of the
way an unadjusted Aring towers over the rest of a line. The last
point about stroked characters is an important one, and what it really
emphasizes is that if you genuinely care about the fonts you choose
you have to be prepared to treat them as individuals, and not try to
set them according to a Procrustean general coding. Hold on now---the
intent is not so much to fix input encoding into concrete as to
{\em stabilize} it so that output encoding can be fluid.
> It may make sense to use AFII glyph numbers for these characters,
> as Adobe seems to suggest, or it may make sense to use UNICODE numbers as
> MicroSoft seems to believe, or we may use the names used by Apple, etc.
> Should it be Trightcommaaccent, Tcaron, Thacek, 0164 (hex), AFII100256, or
> ... ?
Perhaps I should have left those out. Unicode would probably be the
best bet, but when is that likely to be generally recognized?
Email concerned with UnixTeX distribution software should be sent primarily
to: elisabet@u.washington.edu Elizabeth Tachikawa
otherwise to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computing Support Center Resident Druid for
Thomson Hall, Mail Stop DR-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259
------------------------------
Date: Wed, 06 Oct 1993 21:55:45 +0630
From: amit@cc.iitb.ernet.in
Subject: Macros for AMS-TeX?
Can someone pass me some info about site(s) where I can find GOOD macro
compatible with AMS-TeX. Information about other macros with a wide ranging
facility for mathematical expression composition are also welcome. Please help.
The call is for David and Peter as well!!
Amit Kumar Sinha <amit@cc.iitb.ernet.in>
------------------------------
Date: Tue, 12 Oct 1993 14:50:16 +0800
From: Lo Wing Tai <b097766@hp9000.csc.cuhk.hk>
Subject: Postscript driver for HP9000/700 series workstations.
We have dvios but the resolution from pk files are unacceptable. Does
anyone know other public domain or commercial available driver for TeX?
Thanks,
Dr. W. T. Lo
Department of Mathematics
The Chinese University of Hong Kong
Shatin, N.T.
Hong Kong
email: wtlo@cuhk.hk
------------------------------
Date: Tue, 12 Oct 1993 11:35:43 -0700
From: brian@aa.washington.edu
Subject: FTP site for TeX for OpenVMS
I realize that UW is the UNIX site for TeX. Can you tell me the name
of an ftp site for TeX for VMS, specifically Alpha OpenVMS?
Brian Leverson
e-mail: brian@aa.washington.edu
phone: (206)543-6736
FAX: (206)543-0217
mail: University of Washington
Dept of Aeronautics and Astronautics, FS-10
Guggenheim 318A
Seattle, WA 98195
------------------------------
Date: Thu, 14 Oct 1993 14:35:13 +0100
From: J.POTHARST@ELSEVIER.nl
Subject: Printing Sanskrit
Can anyone please help with the following:
I am looking for ways to print Sanskrit characters
("Devanagari") on a laserprinter from a PC,
ideally using Wordperfect. Interest includes also the
transliterated script (Latin characters with dots,
dashes, etc added).
I am very interested to hear on any fonts, programs
or other tools that are being used to produce texts
with these characters.
I've been told that a TeX version or application
from the University of Heidelberg (Germany) exists
that can produce Devanagari, but I don't have details.
Any further information on tools, organisations and
persons is highly appreciated. This question is
not related to, and does not serve, any commercial
purpose.
Jan Potharst
j.potharst@elsevier.nl
------------------------------
Date: Thu, 21 Oct 1993 18:27:21 -0400
From: wkelly@utkvx.utk.edu
Subject: Spacing in Bibliography
I am currently trying to make a bibliography list using BiBTeX to meet local
requirements for Senior Graduate Thesis. The Thesis have to be doubled space,
with no extra spacing between the bibliography entrees. I've tried modifying
\parskip, but to no avail. Everything works okay in the main text, it is just
the bibliography that adds the extra spacing. Any suggestions?
Bill Kelly
Mathematics and Computer Science Dept.
Maryville College email: wkelly@utkvx.utk.edu
Maryville, TN 37801 (internet)
------------------------------
Date: Fri, 22 Oct 1993 13:15:01 -0000
From: David_Rhead@vme.ccc.nottingham.ac.uk
Subject: Metafont settings in DECUS distribution?
A colleague got TeX-and-friends for VAX/VMS via DECUS.
The DECUS suite includes .pk files. I guess that these were generated with
some Metafont settings intended for DEC's LN03.
When my colleague uses these .pk files for output on our Hewlett-Packard
LaserJet IIISi, he gets output that (some say) seems "better" than the
output that other people get using the (CanonCX?) settings that, from
modes.mf, one might expect to do well on a IIISi.
To consider using such .pk files on non-VMS systems, one would need to know
the relevant Metafont settings. Unfortunately, there does not seem to be a
consensus about what should be done for an LN03 (assuming that LN03 is the
DECUS target printer). At Aston, [tex-archive.metafont.vms] suggests
blacker=0.2 (or 0.3, or 0.65)
fillin=-0.4
o_correction=0.5
while [tex-archive.metafont.contrib] suggests (for RicohLP=LN03)
blacker= 0.65
fillin=-0.2
o_correction=0.5
Does anyone know what Metafont settings were actually used to generate the
.pk files in the DECUS distribution?
------------------------------
Date: Mon, 25 Oct 1993 18:26:39 -0500
From: whw@uiuc.edu (Bill Weedon)
Subject: Flushing Inserts ('\midinsert', '\topinsert', etc.)
Dear TeX Hackers,
I am looking for a command to flush inserts created with either
'\midinsert' or '\topinsert' (call this new fictional command
'\flushinsert'). Here is my problem. I am writing a conference
paper in plain TeX and I have several figures (each enclosed in a
'\topinsert') near the end of the document. I am also using
BibTeX with the macro file 'btxmac.tex' to produce my reference
list. The editor of the conference proceedings wants the
reference list to start after the last figure, but not
necessarily on a new page. I would like to have a command
'\flushinsert' to flush the figures and start the reference list
afterwards.
I have solved the problem temporarily by enclosing the last three
figures in a '\pageinsert' and doing a '\break' just before the
reference list. However, a more general solution to this
problem would be nice. I can make my document and figures
available, if necessary.
As an aside, can someone please explain the functional
difference between '\break' in vertical mode and '\eject'?
Thanks,
Bill
Bill Weedon
Graduate Research Assistant
Electromagnetics Laboratory
ECE Department, M/C 702 Office: 217-333-1047
University of Illinois FAX: 217-244-7345
1406 West Green Street E-mail: whw@uiuc.edu
Urbana, IL 61801-2991 (Internet)
------------------------------
Date: Sat, 30 Oct 1993 16:28:00 +0000
From: ajcarr@CCVAX.UCD.IE
Subject: Info needed on VF files (Q)
If I use the NFSS2 nftimes style, I can get all my text typeset in Times
Roman, but the math (including variable names like `x') remain in cmmi. Is
it possible to design a TFM and a VF file which I can substitute for cmmi
which will use Times Italic for the letters and numbers, but cmmi for the
special symbols?
I suppose that this is so obvious that someone would have done it long ago.
Please respond direct, and I will summarise for the Digest if I get enough
responses.
Thanks in advance.
Alun
A. J. Carr, Mech. Eng. Dept., UCD, Belfield, Dublin 4, Ireland
Internet: ajcarr@ccvax.ucd.ie
------------------------------
Date: Mon, 01 Nov 1993 13:16:33 -0800
From: "Ethan V. Munson" <munson@acacia.CS.Berkeley.EDU>
Subject: How do you single-space captions in a double-spaced document?
Hi -
I'm the person maintaining the UCTHESIS style for LaTeX. This style
approximates double-spacing by setting the \baselinestretch to 1.37.
However, certain elements of the document must be single-spaced. To
do this, the style uses the \ssp macro:
\def\ssp{\def\baselinestretch{1.0}\large\normalsize}
Here is an example of the \ssp macro being used to make tabular
environments be single-spaced:
\def\tabular{\par\ssp\let\@halignto\@empty\@tabular}
One document element I'd also like to be single-spaced is captions for
figures and tables, so the style includes the following code:
\long\def\@makecaption#1#2{%
\vskip 10\p@
\setbox\@tempboxa\hbox{#1: #2}%
\ifdim \wd\@tempboxa >\hsize % IF longer than one line:
{\ssp#1: #2}\par % THEN set as ordinary paragraph.
\else % ELSE center.
\hbox to\hsize{\hfil\box\@tempboxa\hfil}%
\fi}
But this does not work even though the 5th line clearly invokes the
\ssp macro. I've been able to use the \message macro to
check the value of \baselinestretch at every point in that line. The
value starts at 1.37, changes to 1.00 immediately after the \ssp
macro, and returns to 1.37 after the closing brace. I suspect that
there is something tricky about the way captions are handled because
they are in floats, but I am not able to figure it out.
Can anyone help with this problem?
Ethan Munson
munson@cs.berkeley.edu
------------------------------
Date: Wed, 03 Nov 1993 18:52:16 -0800
From: John O'Rourke <loyola@crl.com>
Subject: Converting troff to TeX?
Anyone recall seeing something that reads troff and writes TeX?
Regards,
John O'Rourke
loyola@crl.com
------------------------------
Date: Thu, 04 Nov 1993 16:35:00 +1000
From: H.LING@qut.edu.au
Subject: Virtual fonts, aliases problem in LaTeX and DVIPS.
Hello TeX experts,
Re: LaTeX, DVIPS fonts, aliases problem
I would be most grateful if you could help me with the 2 problems below.
My VAX VMS site has experienced peculiar problems with LaTeX and DVIPS
with regards to the new virtual fonts.
Problem 1
- ---------
Around 9/1992, I got all the TeX and DVIPS savesets from the ftp site
ymir.claremont.edu. I then installed them. The DVIPS is by Tomas Rokicki,
version 5490 and has the virtual fonts (e.g. ptmr.vf, ptmr.tfm and rptmr.tfm)
with it which I installed.
Lately, some users been using postscript fonts such as times-roman and
helvetica. When they tried to do LaTeX, it complained bad fonts. WHY????
Are my TeX and LaTeX too old? I have $set watch file/class=all on and
it was accessing the ptmri.tfm alright.
See the trace below:
bauple> latex vhhl
This is TeX, Version 3.14 [PD VMS 3.3a] (preloaded format=lplain 92.2.15)
(DSKC:[TEX.TESTING]VHHL.TEX;6
LaTeX Version 2.09 <14 January 1992>
(TEX_ROOT:[INPUTS.LOCAL]QITDOC.STY;1
Document Style 'qitdoc'. Version 0.05 --- 1988 May 27
(TEX_ROOT:[INPUTS.LOCAL]QITDOC11.STY;1)) (DSKC:[TEX.TESTING]VHHL.AUX;2)
! Font \txxx=ptmri at 36.0pt not loadable: Bad metric (TFM) file.
So I used AFM2TFM and then VPTOVF to regenerate the fonts which resolved the
problem.
Problem 2
- ---------
My users did not like to use aliases for fonts names. So, what I did was
to use the same conventional names as the alias name in the psfonts.map file
and using these long names in the AFM2TFM and VPTOVF commands. What this
means is that times-roman.tfm is not the old font but the virtual font.
Is there any implications for other programs?
I found out my XDVI (pre 1989) did not like the new fonts and I read somewhere
that only XDVI 1.4 or later can handle virtual fonts. Is this correct?
Thanks in advance,
How-Hie Ling.
h.ling@qut.edu.au
Queensland Uni of Technology,
Brisbane, Australia
------------------------------
Date: Thu, 21 Oct 1993 13:20:21 +0100
From: "Nico A.F.M. Poppelier" <N.POPPELIER@ELSEVIER.nl> (Tel 31-20-5803482)
Subject: Elsevier Science announces availability of ESP-LaTeX
Elsevier Science has the pleasure to announce the availability of their
ESP-LaTeX package from the Comprehensive TeX Archive Network (CTAN).
In order to assist authors in preparing their papers for articles published
by Elsevier Science Publishers in such a way that their files can be used to
print the article, we have developed a LaTeX package ESP-LaTeX, consisting of
a document style `espart' and a booklet with instructions to authors.
Authors are kindly requested to use the `espart' document style. This
document style, which produces a preprint-like output, enables the Publisher
to adapt the article to the layout and style of the journal in which the
article will appear (the Publisher will replaced `espart' by a
journal-specific production document style).
The ESP-LaTeX package contains the following files. Please make sure that
you retrieve all these files.
readme.esp Brief instructions.
espart.sty The main document style. Copy this to the directory
where all other .sty files are.
espart12.sty The pointsize-related definitions. Copy this to the
directory where all other .sty files are.
The ESP-LaTeX package can be obtained using anonymous FTP from the
Comprehensive TeX Archive Network (CTAN):
host names: CTAN directory:
- -------------------- ------------------------------------------
ftp.uni-stuttgart.de /pub/tex/macros/latex/contrib/elsevier
ftp.tex.ac.uk /pub/archive/macros/latex/contrib/elsevier
ftp.shsu.edu /tex-archive/macros/latex/contrib/elsevier
Questions concerning the LaTeX author-prepared article project and requests
for the booklet with instructions to authors should be directed to the
address on the inside cover of one of the journals participating in the
project.
Nico Poppelier
Manager for the LaTeX author-prepared article project
------------------------------
Date: Tue, 02 Nov 1993 15:40:51 +0100
From: "Johannes L. Braams" <J.L.Braams@research.ptt.nl>
Subject: New version of subeqnarray available shortly
Hi,
Today I have put a new version of the subeqnarray option in
the incoming directory of ftp.tex.ac.uk. I am sure it will
find its way to the proper place in CTAN shortly.
The difference between this version, 2.0 and the previous one,
1.1, is that it now checks if the user specified either one
(or both) of the options leqno and fleqn.
Regards,
Johannes Braams
PTT Research, P.O. box 421,
2260 AK Leidschendam, The Netherlands.
Phone : +31 70 3325051 E-mail : J.L.Braams@research.ptt.nl
Fax : +31 70 3326477
------------------------------
Date: Wed, 06 Oct 1993 09:05:39 -0600
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Subject: CTAN-US usage summary -- September 1993
TOTALS FOR SUMMARY PERIOD Wed Sep 1 1993 TO Thu Sep 30 1993
Files Transmitted During Summary Period 132516
Bytes Transmitted During Summary Period 11156239589
Systems Using Archives 0
Average Files Transmitted Daily 4417
Average Bytes Transmitted Daily 371874653
Daily Transmission Statistics
Number Of Number of Average Percent Of Percent Of
Date Files Sent Bytes Sent Xmit Rate Files Sent Bytes Sent
- --------------- ---------- ----------- ---------- ---------- ----------
Wed Sep 1 1993 4740 639403757 10.2 KB/s 3.58 5.73
Thu Sep 2 1993 30036 784316348 8.4 KB/s 22.67 7.03
Fri Sep 3 1993 12780 474383193 7.6 KB/s 9.64 4.25
Sat Sep 4 1993 1568 215966902 12.8 KB/s 1.18 1.94
Sun Sep 5 1993 2259 100418333 8.3 KB/s 1.70 0.90
Mon Sep 6 1993 1966 133531811 10.9 KB/s 1.48 1.20
Tue Sep 7 1993 3506 357412081 6.5 KB/s 2.65 3.20
Wed Sep 8 1993 3091 818686870 10.2 KB/s 2.33 7.34
Thu Sep 9 1993 1467 422399485 10.5 KB/s 1.11 3.79
Fri Sep 10 1993 1582 200169264 4.4 KB/s 1.19 1.79
Sat Sep 11 1993 1777 142370666 5.9 KB/s 1.34 1.28
Sun Sep 12 1993 1168 58516174 11.0 KB/s 0.88 0.52
Mon Sep 13 1993 3443 346080667 7.7 KB/s 2.60 3.10
Tue Sep 14 1993 3467 495492262 9.9 KB/s 2.62 4.44
Wed Sep 15 1993 8265 519389193 4.5 KB/s 6.24 4.66
Thu Sep 16 1993 3379 339310317 3.6 KB/s 2.55 3.04
Fri Sep 17 1993 3655 242231830 8.4 KB/s 2.76 2.17
Sat Sep 18 1993 1656 201385046 11.6 KB/s 1.25 1.81
Sun Sep 19 1993 5471 154574819 4.6 KB/s 4.13 1.39
Mon Sep 20 1993 8020 489297353 6.7 KB/s 6.05 4.39
Tue Sep 21 1993 2626 360994684 4.8 KB/s 1.98 3.24
Wed Sep 22 1993 1671 297766050 7.7 KB/s 1.26 2.67
Thu Sep 23 1993 3422 432748660 4.5 KB/s 2.58 3.88
Fri Sep 24 1993 3074 410387999 4.9 KB/s 2.32 3.68
Sat Sep 25 1993 1529 148110909 6.9 KB/s 1.15 1.33
Sun Sep 26 1993 1444 196491225 9.3 KB/s 1.09 1.76
Mon Sep 27 1993 5835 241581838 5.0 KB/s 4.40 2.17
Tue Sep 28 1993 4632 1392929803 19.6 KB/s 3.50 12.49
Wed Sep 29 1993 1600 214632122 2.7 KB/s 1.21 1.92
Thu Sep 30 1993 3387 325259928 3.6 KB/s 2.56 2.92
Total Transfers from each Archive Section
---- Percent Of ----
Archive Section Files Sent Bytes Sent Files Sent Bytes Sent
- ------------------------- ---------- ----------- ---------- ----------
Index/Informational Files 742 236791308 0.56 2.12
bin 20 345125 0.02 0.00
bin/ftp-exec 5 513 0.00 0.00
doc 3 122205 0.00 0.00
economics 4 7196938 0.00 0.06
economics/EconData 20 10402404 0.02 0.09
etc 2 660 0.00 0.00
etc/msgs 1 1225 0.00 0.00
incoming 2 91812 0.00 0.00
incoming/comp-fonts-FAQ 24 1725688 0.02 0.02
incoming/jpeg 2 152143 0.00 0.00
incoming/npr 6 303300 0.00 0.00
incoming/psutils 2 191072 0.00 0.00
incoming/sgi 1 199 0.00 0.00
incoming/texit 2 79124 0.00 0.00
incoming/treetex 8 37111 0.01 0.00
pub 37 1308599 0.03 0.01
pub/MaasInfo 5 83266 0.00 0.00
pub/cdrom 11 580373 0.01 0.01
pub/ftp-list 83 3933253 0.06 0.04
pub/ltx3pub 158 3632405 0.12 0.03
tex-archive 1361 2400487679 1.03 21.52
tex-archive/archive-tools 4609 210237265 3.48 1.88
tex-archive/bibliography 4856 103724470 3.66 0.93
tex-archive/digests 2752 69314531 2.08 0.62
tex-archive/documentation 2225 50441020 1.68 0.45
tex-archive/dviware 6415 239999579 4.84 2.15
tex-archive/fonts 29679 903519346 22.40 8.10
tex-archive/graphics 4604 87342043 3.47 0.78
tex-archive/help 953 79604037 0.72 0.71
tex-archive/indexing 946 10994508 0.71 0.10
tex-archive/languages 7918 197251258 5.98 1.77
tex-archive/macros 38128 1191865483 28.77 10.68
tex-archive/misc 53 2588365 0.04 0.02
tex-archive/support 4610 124424517 3.48 1.12
tex-archive/systems 17708 5134379468 13.36 46.02
tex-archive/web 4553 83079105 3.44 0.74
Total Transfer Amount By Domain
Number Of Number of Average Percent Of Percent Of
Domain Name Files Sent Bytes Sent Xmit Rate Files Sent Bytes Sent
- ----------- ---------- ------------ ---------- ---------- ----------
at 73 656076 3.7 KB/s 0.06 0.01
au 14045 788129076 5.9 KB/s 10.60 7.06
be 317 28053356 1.9 KB/s 0.24 0.25
br 62 5377882 0.8 KB/s 0.05 0.05
ca 5119 754330106 4.5 KB/s 3.86 6.76
ch 308 21388123 16.3 KB/s 0.23 0.19
cl 8 2053709 3.3 KB/s 0.01 0.02
cr 36 8189266 3.3 KB/s 0.03 0.07
cz 14 233140 0.6 KB/s 0.01 0.00
de 1505 54989094 1.2 KB/s 1.14 0.49
dk 221 29854139 4.5 KB/s 0.17 0.27
es 146 20113848 1.1 KB/s 0.11 0.18
fi 283 11614190 8.0 KB/s 0.21 0.10
fr 1736 142116187 9.8 KB/s 1.31 1.27
gr 25 299306 3.4 KB/s 0.02 0.00
hk 144 4325092 1.2 KB/s 0.11 0.04
hu 45 2543453 1.6 KB/s 0.03 0.02
ie 10 524597 0.6 KB/s 0.01 0.00
il 69 1025807 2.4 KB/s 0.05 0.01
in 1 1169695 0.6 KB/s 0.00 0.01
it 221 27881663 3.5 KB/s 0.17 0.25
jp 88 2333739 3.6 KB/s 0.07 0.02
kr 62 10760612 2.5 KB/s 0.05 0.10
mx 1243 13645464 2.0 KB/s 0.94 0.12
nl 1541 44739639 2.9 KB/s 1.16 0.40
no 22 3740876 1.6 KB/s 0.02 0.03
nz 310 28993326 2.6 KB/s 0.23 0.26
pl 2 7862 1.1 KB/s 0.00 0.00
pt 6 108275 1.5 KB/s 0.00 0.00
se 76 2763510 2.3 KB/s 0.06 0.02
sg 95 20543387 1.1 KB/s 0.07 0.18
si 10 64730 3.6 KB/s 0.01 0.00
tw 762 100398023 2.0 KB/s 0.58 0.90
uk 1086 43908740 5.6 KB/s 0.82 0.39
us 90 693789 2.1 KB/s 0.07 0.01
za 90 6037495 0.3 KB/s 0.07 0.05
com 8029 956927996 3.9 KB/s 6.06 8.58
edu 83585 4790386033 14.6 KB/s 63.08 42.94
gov 1166 769859331 19.6 KB/s 0.88 6.90
int 21 7620596 3.8 KB/s 0.02 0.07
mil 694 131115187 18.8 KB/s 0.52 1.18
net 149 38721029 30.4 KB/s 0.11 0.35
org 1087 169293265 2.3 KB/s 0.82 1.52
shsu.edu 8 1917908 47.9 KB/s 0.01 0.02
unresolved 7906 2106790972 6.5 KB/s 5.97 18.88
These figures only reflect ANONYMOUS FTP transfers. There are many
sites which mount the archives via NFS, and those transfers are not
logged and reported by this program.
Top 15 Most Popular Archive Sections By Bytes Transferred
---- Percent of ----
Archive Section Files Sent Bytes Sent Files Sent Bytes Sent
- ------------------------- ---------- ----------- ---------- ----------
tex-archive/systems 17708 5134379468 13.36 46.02
tex-archive 1361 2400487679 1.03 21.52
tex-archive/macros 38128 1191865483 28.77 10.68
tex-archive/fonts 29679 903519346 22.40 8.10
tex-archive/dviware 6415 239999579 4.84 2.15
Index/Informational Files 742 236791308 0.56 2.12
tex-archive/archive-tools 4609 210237265 3.48 1.88
tex-archive/languages 7918 197251258 5.98 1.77
tex-archive/support 4610 124424517 3.48 1.12
tex-archive/bibliography 4856 103724470 3.66 0.93
tex-archive/graphics 4604 87342043 3.47 0.78
tex-archive/web 4553 83079105 3.44 0.74
tex-archive/help 953 79604037 0.72 0.71
tex-archive/digests 2752 69314531 2.08 0.62
tex-archive/documentation 2225 50441020 1.68 0.45
------------------------------
Further information about the TeXhax Digest, the TeX
Users Group, and the latest software versions is available
in every tenth issue of the TeXhax Digest.
Please send contributions to: TeXhax@tex.ac.uk
Administration, subscription and unsubscription requests:
On Internet:
send a one line mail message to TeXhax-request@tex.ac.uk
SUBSCRIBE TEX-L <your real name>
UNSUBSCRIBE TEX-L
On BITNET:
send a similar one-line mail message to LISTSERV@xxx
On JANET:
send a similar one line mail message to TeXhax-request@uk.ac.tex
For information on the TeX Users Group, please send a message to
TUG@math.ams.com, or write TeX Users Group, P.O. Box 869, Santa
Barbara, CA 93102, USA.
Back issues of the digest are available for anonymous ftp from
the UK TeX Archive, tex.ac.uk (134.151.79.28)
in [tex-archive.digests.texhax.YY]texhax.NN
and ftp.tex.ac.uk (134.151.79.32)
in /pub/archive/digests/texhax/YY/texhax.NN
where YY = last two digits of year, NN = issue number
ftp.tex.ac.uk is also mirrored to pip.shsu.edu (192.92.115.10) and
ftp.uni-stuttgart.de (129.69.1.12) as part of the Comprehensive TeX
Archive Network, and may give better response for subscribers in the
USA and Europe, respectively.
\bye
End of TeXhax Digest [Volume 93 Issue 15]
*****************************************