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 ------------------------------ Date: Tue, 12 Oct 1993 14:50:16 +0800 From: Lo Wing Tai 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" 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 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" (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" 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" 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 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] *****************************************