summaryrefslogtreecommitdiff
path: root/info/digests/texhax/93/texhax.15
blob: 495e91299ecebf7c27840c31585e17577e91877d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
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]
*****************************************