move this list?
K. Berry
kb@cs.umb.edu
Mon, 29 Jul 1996 15:08:51 -0400
change the headers for "tex-k" so that one would get a consistent
tex-k will change when I move it to mail.tug.org, but not before.
I'll change your address when I put in twg-tds.
Archive-Date: Mon, 06 Dec 1993 12:47:38 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 06 Dec 1993 12:46:27 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: info-tex@SHSU.edu, pol-econ@SHSU.edu, ctan@SHSU.edu, TUGBD-L%IRLEARN.BITNET@HEARN.nic.SURFnet.nl, VMSGopher-L@trln.lib.unc.edu, tex-cd@SHSU.edu, litprog@SHSU.edu
CC: bparks@wuecona.wustl.edu, bgoffe@whale.st.usm.edu
Message-ID: <009769BE.61462A00.19927@SHSU.edu>
Subject: Your patience, please........
My apologies for the wide broadcast of this note to a few lists where I
have a "presence" (i.e., I manage or co-manage them, have something to do
with their archives, etc.).
If you have sent me any e-mail within the past week or so and have not
heard back, or have attempted to unsubscribe from a list and are awaiting
manual removal for some reason, or have noticed that manual maintenance
aspects of our archives haven't taken place, or have sent me a personal
note and think I'm ignoring you, please bear with me. I will make every
effort to get to your post as soon as possible. I intend to get to the
unsubs first, any problems on the lists second, any problems with the
archives third, then personal items (based on subject lines, anyway).
Given that I have to focus at least a modicum of attention to finals this
week and next, it may take me a brief time to get caught up with the 1,200
or so messages already awaiting me. If you have a message for me which is
truly urgent, please include the word "urgent" in your subject line and I
will get to it as soon as I see it before plowing through all the rest.
Last week I managed to get myself hospitalized for an impacted lower
intestinal tract (so those of you who thought I was full of sh*t were
obviously right 8-)). You don't even want to hear what was like nor what
done to me -- suffice it to say that it was less than pleasant in both
instances, and that recuperation hasn't been all that much joy either.
However, I will get better and I will get caught up (not necessarily in
that order).
Regards and thanks in advance for your patience, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
Archive-Date: Tue, 07 Dec 1993 17:25:35 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 7 Dec 93 23:27:04 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312072327.AA06559@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
CC: karl@cs.umb.edu, mackay@june.cs.washington.edu
Subject: first proposal
[
i have put some thoyghts in here. reactions? specifically to my
assumptions and my questions
Sebastian
karl and pierre - can you join this group with a `subscribe tex-cd
"Name" ' to listserv@shsu.edu?
]
The combined TeX User Groups "TeX KIT"
======================================
Version 1: 07/12/93. Sebastian Rahtz
Summary
-------
This documents attempts to describe:
- the contents of a realistic TeX kit; what any user group or vendor
should offer in addition to TeX itself.
- a means of classifying and supplying `extras' such as fonts, macro
packages, support programs, etc
- a standard directory structure for TeX-related files, which can be
used across the common operating system architectures
We will create from this a CDROM containing a runnable setup for a
variety of platforms.
Assumptions
-----------
a) only binary programs and format files should differ between
machine/OS setups; all fonts, macros, etc will be the same on all
platforms
b) all directory and file names must be lowercase and >= 8 characters;
if in doubt, the ISO9960 standard must be followed
c) the structure should be a single tree to a maximum of 4 levels
d) support for the following platforms is envisaged: Amiga,
Atari, DOS, Mac, NT, OS/2, Unix and VMS. Within these, we
provide distinct setups for:
DOS: dos, dos386, doswin
VMS: Vax/VMS, OpenVMS
Unix: Sparc, HP9000, RS6000, Irix, Alpha Unix, Linux
These yields a total of 16 sets of binaries.
e) the kit should be reproducible; this means that all elements are
stored on CTAN archives, and we have scripts to generate the different
bits
f) the majority of disk will be made up of uncompressed, unarchived,
files, so that it can be mounted and run as a file system
Software
--------
A) TeX and MF programs for all platforms:
- TeX, Metafont, MFware, TeXware (all the programs maintained by
Knuth)
- TeX formats
- plain, LaTeX2e, AMSTeX formats with US hyphenation
- 3 or 4 sets of plain, LaTeX2e, AMSTeX formats with different
hyphenation patterns
- Metafont bases
- plain
- BibTex, Makeindex
- a dvi to PostScript program
- a dvi to PCL program
- a previewer
- dviconcat, dvimerge, dvidvi, dviselect, dvicopy, detex, dvidoc
B) Support packages for all platforms:
- compress and archiving programs (gzip and zip)
- Ghostscript/Ghostview
- a dvi to dotmatrix program
- gnuplot
- ps2pk, font utils (afm to tfm etc)
C) Support packages where available:
- Word-processor conversion programs (WP-to-LaTeX, etc)
- graphics format conversion programs (HP2xx, transfig, bm2font,
pbmtopk etc)
- TeX shells (e.g., 4TeX) and superscripts
- drawing programs (Xfig, TeXcad)
- hypertext tools (latex2html, dvi to pdf)
TeX macros and fonts
--------------------
A) standard kit
plain TeX
- manmac
- pictex
- edmac
- tugboat (also for LaTeX)
TeXinfo
LaTeX2e
- Mainz packages (array, multicol, etc)
- babel
- amslatex
Phyzzx
CM fonts
DC fonts
AMS fonts
TFM (T1 and OT1) files for 35 PostScript fonts
B) named macro kits
Country/language package provided by each LUG
seminar
pstricks
foiltex
changebar
LaTeX-tricks (some selection of the single style files ...)
Plain TeX tricks (some selection of the single style files ...)
C) named language/font kits
arabic
greek
hebrew
cyrillic
IPA
OCR
DIY european hyphenation kit
african languages
D) font-related macro kits
music
chemistry
chess
games (go, crosswords, etc)
E) BibTeX extension kit
all the BibTeX style files
Directory structure
-------------------
For a first suggestion, I propose the tree be rooted simply at
Unix: /usr/local/lib/tex (compatibility with GNU)
DOS: \tex
Mac: :TeX:
VMS: ????:[tex]
root
- archive [sources, goodies, whatever there is room for]
- bases [MF bases]
- bin [the only thing to go on the path]
- one subdirectory for every supported platform
- doc
- info [texinfo format]
- one subdirectory for every package that needs it
- one subdirectory for each language supported
- fonts
- one subdirectory for each font package with sources,
tfms, vfs etc
- pk
- one subdirectory for each supported MF mode
- directory for each dpi
- fontname.pk
- formats
- one subdirectory for each supported platform
(Unix could have links)
- inputs
- one subdirectory for each named package; includes languages
- lib
- one subdirectory for configuration files for each
support package
Questions to answer
-------------------
1. Do we want a commercial publisher? Addison-Wesley, eg, are willing to
take it on and sell at a small profit to them, with some royalties.
Who gets the money? Authors? TUG? Participating LUGs? Clearly LUGs
must be able to resell the disk and make some profit.
will all authors allow us to put stuff on a CD which makes a profit?
what about shareware things like OzTeX?
2. Can all TeX implementations cope with an automatic search of
subdirectories, to one level?
3. Do we support `small' and `big' format files? how?
4. Do we allow for `normal' DOS and 386-only DOS?
5. Do we include more than one program in a given category? for Mac,
for instance, do we have OzTeX? DirectTeX? CMacTeX?
6. Assuming it is *possible* to mount the CD as a file system, and run
with it, most people will install a section onto local disk. What
sort of scripts and interfaces do we need to automate this?
================================================================================
Archive-Date: Tue, 07 Dec 1993 17:32:48 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 7 Dec 93 23:35:45 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312072335.AA06624@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: who we are
just thought it would help to know whos reading this so far:
"George D. Greenwade" <bed_gdg@SHSU.EDU>
"Barbara Beeton" <BNB@MATH.AMS.ORG>
"Christina Thiele" <cthiele@CCS.CARLETON.CA>
"Rainer Schoepf" <Schoepf@SC.ZIB-BERLIN.DE>
"Sebastian Rahtz" <spqr@FTP.TEX.AC.UK>
"Kees van der Laan" <cgl@RISC1.RUG.NL>
"Norman Walsh" <norm@ORA.COM>
goossens@CERNVM.CERN.CH
e.h.m.frambach@ECO.RUG.NL
jos.winnink@CPB.NL
piet@CS.RUU.NL
rcpt@URC.TUE.NL
Sebastian
================================================================================
Archive-Date: Tue, 07 Dec 1993 21:31:44 CST
Sender: CTAN-Mgr@SHSU.edu
From: cthiele@ccs.carleton.ca (Christina Thiele)
Reply-To: TeX-CD@SHSU.edu, cthiele@CCS.CARLETON.CA
Message-ID: <9312080331.AA09779@yoho.YP.nobel>
Subject: Re: first proposal
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Date: Tue, 7 Dec 93 22:31:35 EST
Sebastian Rahtz writes:
>
> ...
>
> Version 1: 07/12/93. Sebastian Rahtz
>
> ...
>
> E) BibTeX extension kit
> all the BibTeX style files
Would this mean that someone ought to contact Oren? If yes, may I
suggest Barbara ... she is conveniently absent this week ;-)
> ...
>
> Questions to answer
> -------------------
> 1. Do we want a commercial publisher? Addison-Wesley, eg, are willing to
> take it on and sell at a small profit to them, with some royalties.
> Who gets the money? Authors? TUG? Participating LUGs? Clearly LUGs
> must be able to resell the disk and make some profit.
Seems to me that one would have to get some input from A-W -- find out
what their expectations might be, so that the working group has
something to bounce off of. That is, one would need to find out what
their conditions for cooperation might include and then see how
acceptable/unacceptable those would be ... And then do some bargaining
if this was the route chosen.
What kinds of options exist for an A-W participation: do they get a
percent of all sales? do they just give some money as an investment
(being a good corporate citizen in the TeX community)? do they
undertake marketting/advertising (and at what rate)? do they get a
special rate to buy copies to include/bundle with any TeX publications
they may distribute?
And if A-W participate in some capacity, what about other commercial
concerns? Open it up? Offer them a chance to invest and buy in to a
reduced unit cost for further distribution? Or keep it small?
Seems like the options are wide open -- for anyone to define the
limits and set the rules ...
> will all authors allow us to put stuff on a CD which makes a profit?
> what about shareware things like OzTeX?
Sounds like semi-legal counsel is needed here ;-) Or at least someone
who can dig up the rules and regulations for copyleft and shareware,
not to mention of course finding out what the authors themselves want.
> ...
>
> 5. Do we include more than one program in a given category? for Mac,
> for instance, do we have OzTeX? DirectTeX? CMacTeX?
Choose on the basis of popularity? Fewest bugs/hassles? Imply a scale
of good to bad ... ? Or just try and get them all on, and let the user
make the decision -- one implementation may be good for user A, but
user B finds that it's not as good as another ...
In short -- when do you decide to use space limitations as a deciding
criterion?
> 6. Assuming it is *possible* to mount the CD as a file system, and run
> with it, most people will install a section onto local disk. What
> sort of scripts and interfaces do we need to automate this?
==============================
Please read these comments with a great deal of forbearance -- given
Sebastian's message listing the readers of this list, I am ... shall
we say ... the most archivally-challenged of the bunch ... ;-)) [a
semi-intelligible phrase to those who live in North America, where
political correctness has become a tremendous source of improbable
terminology ... ;-)) ]
Christina
================================================================================
Archive-Date: Wed, 08 Dec 1993 12:22:32 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 8 Dec 1993 13:18:02 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199312081818.AA15472@ora.com>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: first proposal
References: <9312072327.AA06559@ftp.tex.ac.uk>
Reply-To: TeX-CD@SHSU.edu, norm@ora.com
On 7 December 93, spqr@ftp.tex.ac.uk wrote:
> i have put some thoyghts in here. reactions? specifically to my
> assumptions and my questions
>
> c) the structure should be a single tree to a maximum of 4 levels
That seems quite doable, but is there a compelling reason for the 4-level
limit?
> d) support for the following platforms is envisaged: Amiga,
> Atari, DOS, Mac, NT, OS/2, Unix and VMS. Within these, we
> provide distinct setups for:
>
> DOS: dos, dos386, doswin
> VMS: Vax/VMS, OpenVMS
> Unix: Sparc, HP9000, RS6000, Irix, Alpha Unix, Linux
DEC Ultrix? The DEC Alpha?
> These yields a total of 16 sets of binaries.
Our "Unix Power Tools" contains 8 sets of Unix binaries w/o Linux, so I
think there may need to be a few more...
> f) the majority of disk will be made up of uncompressed, unarchived,
> files, so that it can be mounted and run as a file system
Uncompressed, unarchived files are a necessary, but not sufficient
condition, for making a mountable file system.
> Software
> --------
> A) TeX and MF programs for all platforms:
> - TeX, Metafont, MFware, TeXware (all the programs maintained by
> Knuth)
> - TeX formats
> - plain, LaTeX2e, AMSTeX formats with US hyphenation
> - 3 or 4 sets of plain, LaTeX2e, AMSTeX formats with different
> hyphenation patterns
Might as well do all the formats we can: Lollipop, TeXinfo, LaTeXinfo,
Eplain, ...
> - a dvi to PostScript program
> - a dvi to PCL program
What about dvi to everything else?
> C) Support packages where available:
> - graphics format conversion programs (HP2xx, transfig, bm2font,
> pbmtopk etc)
pbmplus, imagemagick ... ?
> - TeX shells (e.g., 4TeX) and superscripts
> - drawing programs (Xfig, TeXcad)
Tgif, xv, ... ?
> - hypertext tools (latex2html, dvi to pdf)
Perl for latex2html? Latex2hyp, ... ?
> plain TeX
> - manmac
> - pictex
> - edmac
> - tugboat (also for LaTeX)
eplain, midnight, ...
> TeXinfo
LaTeXinfo ...
> LaTeX2e
> - Mainz packages (array, multicol, etc)
> - babel
> - amslatex
> Phyzzx
REVTeX, INRSTeX, ...
> LaTeX-tricks (some selection of the single style files ...)
> Plain TeX tricks (some selection of the single style files ...)
Are you not planning to put the entire style archive on the CD???
> C) named language/font kits
Are you not planning to put the entire MF source archive on the CD???
What about all the PS fonts?
> Questions to answer
> -------------------
0. Will we need and are we willing to produce a two-volume CD set. You see,
I have this suspicion that all the compiled binaries should go on one disk
and all of the "sources" should go on another. The sources disk needs to
be mountable, while I'm not as convinced that the binaries disk does. Who's
going to execute TeX off a mounted CD-ROM?
> 2. Can all TeX implementations cope with an automatic search of
> subdirectories, to one level?
Regardless, I don't know of any TeX implementations that can't be configured
to look in a few places.
> 3. Do we support `small' and `big' format files? how?
Yes, if possible. How 'bout "formats" and "bformats" directories?
> 4. Do we allow for `normal' DOS and 386-only DOS?
Yes.
> 5. Do we include more than one program in a given category? for Mac,
> for instance, do we have OzTeX? DirectTeX? CMacTeX?
Absolutely.
> 6. Assuming it is *possible* to mount the CD as a file system, and run
> with it, most people will install a section onto local disk. What
> sort of scripts and interfaces do we need to automate this?
That's a *really large* headache because many (Unix) operating systems
require kernel patches to mount a CD-ROM. That was O'Reilly's experience
with the mountable X11 CD, anyway...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |
(617) 354-5800 |
================================================================================
Archive-Date: Thu, 09 Dec 1993 09:02:45 CST
Sender: CTAN-Mgr@SHSU.edu
From: cthiele@ccs.carleton.ca (Christina Thiele)
Reply-To: TeX-CD@SHSU.edu, cthiele@CCS.CARLETON.CA
Message-ID: <9312091503.AA28285@yoho.YP.nobel>
Subject: Proposed standard TeX distribution (fwd)
To: tex-cd@shsu.edu
Date: Thu, 9 Dec 93 10:03:34 EST
I have just received the following from Phil Taylor; he had sent it to
Kees and myself, but I feel it is important at this point to make sure
this is part of the official log for this list.
Were any of you aware of this NTS plan? I certainly was not, but then
I'm afraid I only very occasionally dip into c.t.t. I do not see
anything that is being prepared for TUGboat. And I don't subscribe to
any of the other European lists. But was anyone else aware of the NTS
proposal via these routes?
I don't feel competent at this point to answer Phil but someone has
to. Since this leads from NTS to DANTE (let's not kid ourselves), the
possible damage to the collaborative nature of the project concerns
me.
Christina
============================================================
CHAA006@VAX.RHBNC.AC.UK writes:
> From CHAA006@VAX.RHBNC.AC.UK Thu Dec 9 09:36:00 1993
> Via: uk.ac.rhbnc.vax; Thu, 9 Dec 1993 13:59:40 +0000
> Date: Thu, 9 DEC 93 13:59:32 GMT
> From: CHAA006@VAX.RHBNC.AC.UK
> To: Cthiele <Cthiele@ccs.carleton.ca>
> Subject: Proposed standard TeX distribution
> Actually-To: <Cthiele%ca.carleton.ccs@UK.AC.NSFNET-RELAY>
> Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" <CHAA006@VAX.RHBNC.AC.UK>
> Message-Id: <29E018CA_0007D970.00976C2415489350$23_1@UK.AC.RHBNC.VAX>
> Reply-To: Philip Taylor (RHBNC) <P.Taylor@Vax.Rhbnc.Ac.Uk>
> Originally-To: NET%"Cthiele@ca.carleton.ccs",NET%"cgl@nl.rug.risc1"
> Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 )
>
> Dear Kees/Christina ---
>
> I was rather saddened to received the attached mail from Sebastian, dated 3rd
> December, in which he outlines some proposals for a standardised TeX kit, based
> on a suggestion from Kees to Christina. The reason for my sadness is, of
> course, that this document post-dates by almost four weeks the announcement (on
> multiple TeX-related lists, on the Comp.Text.TeX group of Usenet News, and in a
> submission to the editor of TUGboat) that the NTS team proposed to undertake a
> _very_ closely related project. Has the TeX world fragmented to such an extent
> that two almost identical projects must be undertaken in order to achieve a
> single aim? Is there any reason at all why the NTS proposal is not mentioned
> in Sebastian's discussion document?
>
> Yours very sincerely,
> ** Phil.
>
> [text of the proposal had been appended here]
>
%% END OF MESSAGE
================================================================================
Archive-Date: Thu, 09 Dec 1993 10:20:33 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 1993 17:17:12 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9312091617.AA23273@risc1.rug.nl>
To: P.Taylor@Vax.Rhbnc.Ac.Uk
Subject: Re: Proposed standard TeX distribution
CC: TeX-CD@shsu.edu, cgl@risc1.rug.nl
Dear Phil,
Glad to hear that the eminent NTS persons are embarking a near-similar project.
I was not aware of that and that was also part of me asking/looking for
collaboration. No problems with me on that as long as something will come
out in the near-future. Can you please put the NTS proposal on the floor,
and if that is better why not reorganize it and make it a TUG/LUGs project?
Those organizational details are not important in MHO and hope others have
no strong feelings either. We, NTG just liked the idea, which was undoubtedly
on the floor
somewhere.. (whoops mail editor went out of its mind, sorry)
Perhaps Christina can recollect the material and make a new organizational
proposal, I'm so happy that many active people are involved already...
Just bundling the energy in the right direction, that is all what has to be done
for the short term, and then there we go, with a superb CDROM to come
like the most beautiful TeX-Music on it...
Best wishes, ---Kees---
P.S. You don't mind we go on talking on the discussion list about relevant issue
ues? I beg you don't that is useful anyways, whoever in charge and whatever
the ourcome...
================================================================================
Archive-Date: Thu, 09 Dec 1993 10:21:58 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 1993 17:21:25 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9312091621.AA23292@risc1.rug.nl>
To: TeX-CD@SHSU.edu, cthiele@CCS.CARLETON.CA
Subject: Re: Proposed standard TeX distribution (fwd)
CC: cgl@risc1.rug.nl
Dear Christina,
Keep upright, no problem. Of course I was not aware of this too, otherwise
I would have told. Neither of my Dutch friends was. I sensed it should have
been on the air, as I told you before. This is good news, really it is,
and if a matter of competence, I'll step down and give room to others.
No problem. Let us face the music. What are their proposals and let's
bundle the energy, no? Naive again? :-(.
Cheers, ---Kees---
================================================================================
Archive-Date: Thu, 09 Dec 1993 10:25:31 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 1993 17:24:21 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9312091624.AA11688@risc1.rug.nl>
To: TeX-cd@shsu.edu
Subject: Seb's questions and some more...
CC: cgl@risc1.rug.nl
%
In reply to Kees answer to Yannis doubts: I would like to announce at once
that the Nordic Group at this years annual meeting discussed again
a "Nordic distribution" compatible for UNIX, PC and MAC. (Enn Saar from
Estonia was present and wants to use the same distribution in his country).
We need to do this for the benefit of the existing users. We do not think
that this will hinder interested people to look at other things on the servers
as well. The FTP.kth.se archive will anyhow be maintained.
We would like to help NTG to start of with a contribution of what we think
we need to be there - common and national special. Our next meeting will be
in Oslo Norway in May (Kees, this time we will send a more formal invitation).
We would like to have a representative from the Nordic Group on the
CD-Rom project.
Roswitha
Dear Kees/Christina ---
I was rather saddened to received the attached mail from Sebastian, dated 3rd
December, in which he outlines some proposals for a standardised TeX kit, based
on a suggestion from Kees to Christina. The reason for my sadness is, of
course, that this document post-dates by almost four weeks the announcement (on
multiple TeX-related lists, on the Comp.Text.TeX group of Usenet News, and in a
submission to the editor of TUGboat) that the NTS team proposed to undertake a
_very_ closely related project. Has the TeX world fragmented to such an extent
that two almost identical projects must be undertaken in order to achieve a
single aim? Is there any reason at all why the NTS proposal is not mentioned
in Sebastian's discussion document?
Yours very sincerely,
** Phil.
--------
To: TeX User Groups
Subject: A standard TeX Kit on CD ROM
The TUG President has been asked by the Kees van der Laan, for the
Dutch TeX Users Group (NTG), to collaborate on the production of a new
CD ROM containing a standard TeX distribution for immediate
installation/use on personal computers. Following discussion, we
would like to broaden this project to include the ongoing concerns of
the TUG-sponsored CTAN archives to promote better kits, and work with
all interested parties to define a complete TeX kit, and issue it
regularly on CD. The intention of this note is to elaborate on what is
proposed, and to ask whether you would like to collaborate.
The aim of the scheme is to establish and promote three things:
- the structure of a realistic TeX kit; what any user group or vendor
should offer in addition to TeX itself and the CM fonts (e.g., a
previewer, a PostScript driver, an HPLJ driver, BibTeX, Makeindex,
Ghostscript, etc)
- a means of classifying and supplying `extras' such as fonts, macro
packages, support programs, etc, so that different vendors or
groups can add or remove modular components
- a standard directory structure for TeX-related files, which can be
used across the common operating system architectures; this should
enable, for instance, PC users to mount a Unix file system and run
the same TeX font and macro files as the Unix kit, with no
additional settings
A over-riding consideration will be the separation of the
machine-dependent binary programs and idiosyncrasies from the main
body of TeX macros, fonts, styles etc, which will be the same on any
setup. We would hope that we could quite easily establish a common kit
for all Acorn, Amiga, Atari, DOS, Linux, Mac, NT, OS/2, Unix and VMS
users using the Roman alphabet. Systems like VM/CMS, and non-Roman
alphabets, perhaps need more discussion.
These principles will be used to put together a runnable CD for a
number of PC/Unix/Mac platforms, and to enable the CTAN archives to
supply kits for different machines on demand over the networks,
mirroring the latest versions of software and macros. Obviously, the
principles would also be followed by user groups who supplied TeX on
floppy disk or tape.
We would like to stress that the CD initiative is distinct from the
production of archival source CD-ROMs, and the continued archival role
of CTAN. CTAN/TUG is already collaborating with Prime Time Freeware on
an archival CD, to be issued early in 1994, and it is hoped that this
will be updated at regular intervals. The Archive CD will be for
system people and hackers to have sources and stuff online when
needed; the Kit CD will be for normal people to actually mount and run
from, or copy direct to their local disks.
We believe that the many TeX kits being distributed around the world
with different contents, and different versions of macro and support
packages, considerably damages the `image' and portability of TeX; we
hope that as many people as possible will forget their long-held views
on how to create a TeX kit, and promote a common view. With the very
considerable space available on a CD-ROM, we should be able to offer
almost everything different groups want their members to have access
to.
If this scheme is agreed, it will also immediately affect the way the
CTAN archives are maintained. Directory hierarchies and names in the
archive will be changed if necessary to reflect what is agreed.
We propose that the NTG act as the technical leaders on the CD
project, to take the form of a working group. The NTG would actually
produce the disk, but the structure would be adopted by the
participating groups, who would also follow that structure in their
own disk-based kits. The distribution by the TUG office in Santa
Barbara will of course follow the project lead. If a user group is
willing to collaborate, they should name a technical person to join
the working group, and agree to follow the group decisions. Authors
of TeX kits, and commercial vendors, will also be asked to join the
group.
User groups may also join the project financially; if they agree to
purchase at least 30 copies of the first CD (at approximately $15 per
copy), they can then sell the disk to members at a suitable price to
allow for expenses and some reasonable profit. It is important to note,
however, that we would welcome the participation of groups even if they
do not wish to sell the disk themselves.
The working group will be led initially by NTG. Sebastian Rahtz and
George Greenwade will act as the liaison between the TUG Board, CTAN
and the project. This is not intended to be a long-term, drawn-out,
discussion! We suggest that three months (January to March 1994) is
more than sufficient to agree on the structure; the CTAN sites can
implement it immediately, and a CD could be produced within a few
months.
If you want to work on this, we ask you to nominate someone to
represent your views as soon as possible, so that work can get under
way.
Appendix: A possible outline for discussion
===========================================
This was put together by Sebastian Rahtz, using the current NTG
proposals. The precise contents of the packages are not necessarily to
be precisely specified for a given platform; thus, in the case of
previewers, or word-processor conversion programs, a kit may offer
none, one, or many programs. The important thing is that the
documentation describes their presence or absence in a consistent way,
and that they can be installed or uninstalled without upsetting the
rest of the setup.
It is a matter of importance to establish early on whether or not to
support dynamic directory hierarchy searching; e.g., do we add each
new macro package in its own directory, or we fold it into one or more
general directories, with a control file to facilitate its later
removal? This needs, at least, some discussion with the main TeX
implementors.
Software
--------
A) Standard programs for all platforms:
- TeX, Metafont, MFware, TeXware (all the programs maintained by
Knuth)
- TeX formats
- plain, LaTeX, AMSTeX and eplain formats with US hyphenation
- plain, LaTeX, AMSTeX and eplain formats with a set of
hyphenation patterns determined by supplier
(LaTeX is assumed to be LaTeX2e *only*)
- Metafont bases
- plain
- Bibtex, Makeindex
- dvi to PostScript program (presumably dvips)
- dvi to HPLJ program
- previewer
- dviconcat, dvimerge, dvidvi, dviselect, dvicopy, detex,
dvi-to-ASCII
- documentation
B) Optional program packages:
- Ghostscript/Ghostview
- Word-processor conversion programs (WP-to-LaTeX, etc)
- dvi to dotmatrix programs
- graphics format conversion programs (HP2xx, transfig, bm2font, etc)
- TeX shells (e.g., 4TeX) and superscripts
TeX macros and fonts
--------------------
A) standard kit
plain TeX
- manmac
- pictex
- edmac
- tugboat (also for LaTeX)
TeXinfo
LaTeX2e
- Mainz packages (array, multicol, etc)
- babel
Phyzzx
CM fonts
DC fonts
Cork-encoded TFM files for 35 PostScript fonts
B) named macro kits (obviously a lot to add here!)
(Local styles for a given LUG)
seminar
pstricks
foiltex
changebar
LaTeX-tricks (some selection of the single style files ...)
C) named language/font kits (needs much clarification)
arabic
greek
hebrew
cyrillic
IPA
OCR
european hyphenation kit
african languages
D) font-related macro kits
music
chemistry
chess
games (go, crosswords, etc)
E) BibTeX extension kit
all the BibTeX style files
%% END OF FILE
================================================================================
Archive-Date: Thu, 09 Dec 1993 13:09:32 CST
Sender: CTAN-Mgr@SHSU.edu
From: cthiele@ccs.carleton.ca (Christina Thiele)
Reply-To: TeX-CD@SHSU.edu, cthiele@CCS.CARLETON.CA
Message-ID: <9312091908.AA29372@yoho.YP.nobel>
Subject: Re: Kees' message starting ``In reply to Kees...''
To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Date: Thu, 9 Dec 93 14:08:18 EST
Kees van der Laan writes:
>
>
> %
> In reply to Kees answer to Yannis doubts: I would like to announce at once
> that the Nordic Group at this years annual meeting discussed again
> a "Nordic distribution" compatible for UNIX, PC and MAC. (Enn Saar from
> Estonia was present and wants to use the same distribution in his country).
> We need to do this for the benefit of the existing users. We do not think
> that this will hinder interested people to look at other things on the servers
> as well. The FTP.kth.se archive will anyhow be maintained.
> We would like to help NTG to start of with a contribution of what we think
> we need to be there - common and national special. Our next meeting will be
> in Oslo Norway in May (Kees, this time we will send a more formal invitation).
> We would like to have a representative from the Nordic Group on the
> CD-Rom project.
> Roswitha
>
> ... [rest of message deleted] ...
>
Just to keep things clear: the above text was posted to TUG's board by
Roswitha, forwarded to this list by Kees. Sounds good!
Ch.
================================================================================
Archive-Date: Thu, 09 Dec 1993 13:25:23 CST
Sender: CTAN-Mgr@SHSU.edu
From: cthiele@ccs.carleton.ca (Christina Thiele)
Reply-To: TeX-CD@SHSU.edu, cthiele@CCS.CARLETON.CA
Message-ID: <9312091924.AA29407@yoho.YP.nobel>
Subject: Re: Proposed standard TeX distribution
To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Date: Thu, 9 Dec 93 14:24:00 EST
Kees van der Laan writes:
>
>
> Dear Phil,
>
> Glad to hear that the eminent NTS persons are embarking a near-similar project.
> I was not aware of that and that was also part of me asking/looking for
> collaboration. No problems with me on that as long as something will come
> out in the near-future. Can you please put the NTS proposal on the floor,
> and if that is better why not reorganize it and make it a TUG/LUGs project?
> Those organizational details are not important in MHO and hope others have
> no strong feelings either. We, NTG just liked the idea, which was undoubtedly
> on the floor
Kees, thank you very much for answering Phil. I was of course
concerned with the idea that the NTS proposal had perhaps been known
but not mentioned.
And yet -- the notion of TeX on a CD has been popping up in many
quarters these past few months -- we went through this little
discussion early on as the proposal was being drafted: there was the
NTG proposal, the CTAN archivists had been talking about it, Norm
Walsh is in there too ... and now NTS. I guess we should be prepared
for someone else to now surface saying they too had been toying with
the idea ...
If we can mesh and combine all these notions, avoiding getting bogged
down and just moving ahead with the work, we should all be able to
benefit.
> somewhere.. (whoops mail editor went out of its mind, sorry)
> Perhaps Christina can recollect the material and make a new organizational
> proposal, I'm so happy that many active people are involved already...
Do you really think we need a new proposal? Or are you suggesting
that the initial paragraphs perhaps be revised, to take into account
what we're now learning about the NTS's proposal? I'm not quite clear
what you'd like me to do.
> Just bundling the energy in the right direction, that is all what has to be done
> for the short term, and then there we go, with a superb CDROM to come
> like the most beautiful TeX-Music on it...
>
> Best wishes, ---Kees---
> P.S. You don't mind we go on talking on the discussion list about relevant issue
> ues? I beg you don't that is useful anyways, whoever in charge and whatever
> the ourcome...
No, I don't mind at all! I think this is where this discussion should
be, because we don't want to inadvertantly make false steps in this
venture. If we can join up the ideas which are now clearly all around
us, then we're all better off. From my perspective, it's more
important to see that we end up with a good product. No one has a
monopoly on the one best greatest idea ... we're all muddling along
the same road to seeing that a solid TeX installation kit finds a home
on a CD (... or CDs ... if it comes to that!).
Ch.
================================================================================
Archive-Date: Thu, 09 Dec 1993 14:55:59 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 93 20:14:06 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312092014.AA03057@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu, P.Taylor@vax.rhbnc.ac.uk
Subject: Re: Proposed standard TeX distribution (fwd) AND NTS
References: <9312091503.AA28285@yoho.YP.nobel>
Christina Thiele writes:
>
> Were any of you aware of this NTS plan? I certainly was not, but then
All i was aware of was the minutes of the NTS committee which Phil
issued. Is there more?
> > I was rather saddened to received the attached mail from
> > Sebastian, dated 3rd December, in which he outlines some
> > proposals for a standardised TeX kit, based on a suggestion from
> > Kees to Christina. The reason for my sadness is, of course, that
> > this document post-dates by almost four weeks the announcement
> > (on multiple TeX-related lists, on the Comp.Text.TeX group of
> > Usenet News, and in a submission to the editor of TUGboat) that
> > the NTS team proposed to undertake a _very_ closely related
i presume this *is* those meeting minutes you posted? I am sorry, but
i did not see them as very concrete. I gathered that NTS was
interested in defining a standard TeX, and that you had allocated some
members to look at the subject, and this was in my mind when i
originally put the subject before the TeX board some months back (this
is not a new thing!), but the real drive behind this project was NTG's
plan to issue a CD, and CTAN's scheme to define standard TeX kits
> > project. Has the TeX world fragmented to such an extent that two
> > almost identical projects must be undertaken in order to achieve
> > a single aim? Is there any reason at all why the NTS proposal is
> > not mentioned in Sebastian's discussion document?
well, yes, because i have not seen any formal proposal! i would have
expected that NTS would have contacted the TeX archive world and TUG
when it started getting serious about a TeX kit.
please lets bear in mind that the contents of a standard TeX kit are
only part of the TeX-CD ideas, by the way.
can we forget about competition and high horses and just work towards
getting a standard TeX kit on the market? i, for one, don't care if we
all join NTS, or if NTS joins this group, but no, we dont want two
projects.
Phil, i assume you'll alert your sub-committee to discuss this and let
TUG know how they are going to work, and what we should do?
sebastian
================================================================================
Archive-Date: Thu, 09 Dec 1993 16:05:52 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 1993 16:59:56 -0500
From: "K. Berry" <kb@cs.umb.edu>
Message-ID: <199312092159.AA12776@terminus.cs.umb.edu>
To: tex-cd@shsu.edu
Subject: Re: first proposal
Reply-To: TeX-CD@SHSU.edu, kb@cs.umb.edu
1. Do we want a commercial publisher? Addison-Wesley, eg, are willing to
Do we have a choice? I had the impression no one had the capital to cut
the CD.
2. Can all TeX implementations cope with an automatic search of
subdirectories, to one level?
Right now? As far as I know, I invented subdirectory searching for TeX
and it hasn't caught on with anyone else...
3. Do we support `small' and `big' format files? how?
smalltex.fmt and smallmf.bas, if we must.
I'm not sure it's worth it, though.
6. Assuming it is *possible* to mount the CD as a file system, and run
with it, most people will install a section onto local disk. What
sort of scripts and interfaces do we need to automate this?
Ones that will be extremely painful to write, debug, and have them work
in all the trillions of environments people will be using them in!
norm> That's a *really large* headache because many (Unix) operating
systems require kernel patches to mount a CD-ROM. That was
O'Reilly's experience with the mountable X11 CD, anyway...
Even if the CD is not mountable, there has to be some way to get the
info off it. Ideally we would supply scripts to do that, right?
I agree with the really large headache part.
================================================================================
Archive-Date: Thu, 09 Dec 1993 16:06:06 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 9 Dec 1993 16:59:50 -0500
From: "K. Berry" <kb@cs.umb.edu>
Message-ID: <199312092159.AA12773@terminus.cs.umb.edu>
To: tex-cd@shsu.edu
Subject: Re: first proposal
Reply-To: TeX-CD@SHSU.edu, kb@cs.umb.edu
(This message and my next one are about the never-ending question of
installation directories and other such, not organizational stuff. I
leave it to better-qualified others to debate that.)
b) all directory and file names must be lowercase and >= 8 characters;
You mean <= 8 chars. Plus 3 chars of extension, I assume.
Unix: Sparc, HP9000, RS6000, Irix, Alpha Unix, Linux
Sparc means both SunOS and (shudder) Solaris?
TFM (T1 and OT1) files for 35 PostScript fonts
What about including the free Type 1 fonts from IBM/Bitstream/URW?
At least optionally.
- a dvi to PostScript program
- a dvi to PCL program
I remain unconvinced that these should be ``mandatory'' instead of
``optional''. Whatever that might mean.
D) font-related macro kits
music
I'd hardly call musictex a ``font-related macro kit''. But maybe you're
talking about something else here.
Unix: /usr/local/lib/tex (compatibility with GNU)
I suggest /usr/local/lib/texmf. .../tex is already being used at many
sites to be just the TeX- (not MF-)related files.
- bases [MF bases]
- formats
I don't see any need for separate directories here. I would just have
`formats'.
By the way, does this mean I have to modify Metafont to read plain.bas
in response to &plain? I guess so.
- fonts
- one subdirectory for each font package with sources,
tfms, vfs etc
- pk
- one subdirectory for each supported MF mode
- directory for each dpi
- fontname.pk
I think all font directories should be by typeface. The idea of one pk/
directory is a bad one imho.
================================================================================
Archive-Date: Thu, 09 Dec 1993 19:09:57 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199312100055.AA03438@rw3.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Fri, 10 Dec 1993 01:55:37 MET
To: TeX-CD@SHSU.edu, kb@cs.umb.edu
Subject: Re: first proposal
[ "K. Berry" (Dec 9, 23:11):
> 2. Can all TeX implementations cope with an automatic search of
> subdirectories, to one level?
> Right now? As far as I know, I invented subdirectory searching for TeX
> and it hasn't caught on with anyone else...
There is a Dutch saying `in beperking toont zich de meester' (there ought
to be moderation in everything). I think DEK was a master by not demanding
to much fancy features. In your kpath search heuristics there are too much
fancy things: a) we don't need b) are hard to implement on non UNIX
platforms. Will your dvipsk and xdvik ever become standard on UNIX?
What we could try is to define a directory structure:
- that allows the installation of new packages, the removal of packages,
the update of packages (dividing TeX into ortogonal add-ons)
- can be ported to the general available computers.
We also have to be very aware of not providing `modulo intel 8086
solutions'. That are the sort of solutions we get when we want to provide
solutions that also work on MSDOS. So I can imagine we have:
- a META directory structure (not necessary acceptable by any system)
- no hard wired paths inside executables
although I like UNIX I don't like these hardwired paths. We need
someting you see on VAX-VMS: a system wide TEXROOT logical. TeX
binaries should accept data relative from a root. Then updating your
TeX can be as easily as getting the latest binaries for your system
- exchangable format files (one per country for all machines?)
That would also ease the process of making the installation painless.
I am afraid that the fixed length arrays of TeX makes format files
not exchangable.
- software that can convert from a META structure into a machine
dependant structure. It should be possible, although not trivial, to
write client/server programs that can ease the installation or update
of an existing TeX installation. The server runs on a CTAN archive and
knows about the META TeX, the client runs on a whatever box and knows
how to convert the META stuff into BOX stuff.
- the same kind of software could use the CD with META TeX from the CTAN
server and move (updating, installing) it into machine dependant
format on your harddisk.
> 3. Do we support `small' and `big' format files? how?
> smalltex.fmt and smallmf.bas, if we must.
> I'm not sure it's worth it, though.
This is typical MSDOS stuff (16-bit misary). For DOS people the only
way to get their TeX job done. I don't know if it is possible to make
TeX fixed-array free and to invent a portable format file. That would
be nice.
> 6. Assuming it is *possible* to mount the CD as a file system, and run
> with it, most people will install a section onto local disk. What
> sort of scripts and interfaces do we need to automate this?
> Ones that will be extremely painful to write, debug, and have them work
> in all the trillions of environments people will be using them in!
Please no mountable CD-ROM solutions. I think the ISO9660 CD-ROM
standard again is a modulo MSDOS solution. Only allowing for uppercase
names restricted to 8+3 characters. I have looked at the NLUUG CD-ROM
we got at our Unix Users Group. There was TeX on it. It consisted of
a README.TXT;1 and SUNTEX.TAZ;1. You may guess where the `;' comes
from.
A CD-ROM can help in making things available for `almost free'. But a lot
of problems have to been solved. But if we don't succeed there may be one
consolation: the wish has triggered a nice discussion about making TeX more
standard across platforms and making it easier to bring the new TeX stuff
to the end-users.
It is late here now. I wish you all a good day/night!
--Piet
--
internet: rcpt@urc.tue.nl __o Piet Tutelaers
bitnet: rcpt@heitue5.BITNET _`\<,_ Computer Center Room RC 1.90
phone: +31 (0)40 474541 (_)/ (_) Eindhoven University of Technology
fax: +31 (0)40 434438 Save nature P.O. Box 513, 5600 MB Eindhoven, NL
================================================================================
Archive-Date: Fri, 10 Dec 1993 05:06:20 CST
Sender: CTAN-Mgr@SHSU.edu
From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)
Date: Fri, 10 Dec 1993 10:51:03 +0100
Message-ID: <9312100951.AA21230@pumuckl.ZIB-Berlin.DE>
To: TeX-CD@SHSU.edu, kb@cs.umb.edu
Subject: Re: first proposal
References: <199312092159.AA12773@terminus.cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, Schoepf@sc.ZIB-Berlin.DE
"K. Berry" writes:
> (This message and my next one are about the never-ending question of
> installation directories and other such, not organizational stuff. I
> leave it to better-qualified others to debate that.)
>
> b) all directory and file names must be lowercase and >= 8 characters;
> You mean <= 8 chars. Plus 3 chars of extension, I assume.
>
> Unix: Sparc, HP9000, RS6000, Irix, Alpha Unix, Linux
> Sparc means both SunOS and (shudder) Solaris?
What about SGI and Ultrix Mips? And what about the lesser known ones
(System V.4 on 386, Data General AViiOn,....)
Rainer Schoepf
Konrad-Zuse-Zentrum
fuer Informationstechnik Berlin
Heilbronner Strasse 10
D-10711 Berlin
Federal Republic of Germany
<Schoepf@sc.ZIB-Berlin.de> or <Schoepf@sc.ZIB-Berlin.d400.de>
================================================================================
Archive-Date: Sun, 12 Dec 1993 12:46:27 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Sun, 12 Dec 93 18:40:50 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312121840.AA22130@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: TeX cd plans
Apologies for the delay and confusion of this single large reply to
posts last week; they coincided with a brain transplant on
ftp.tex.ac.uk, which means i may well not have got all the mail.
apologies for the confused order.
George said:
------------
> June). Whether it is one project under the auspices of one authority and
> publisher or many projects under the auspices of many authorities and
> publishers is something we need to consider. I am not opposed to
We have to decide what we want to do about this, because we already
have commercial partners willing to discuss plans. To reiterate:
Firstly, Norm Walsh & O'Reilly Associates were already planning a CD
to go with (inter alia) Norm's forthcoming book, and Norm is willing
to make this a joint effort with O'Reilly underwriting the cost of
producing the disks, selling them, and making some royalty payment to
the collected TeX User Groups, if the collected wisdom and effort
represented here do the work for ORA. Secondly, Addison Wesley are
also interested in publishing and selling a TeX CD, which they would
commission from TUG in effect. Obviously no-one involved sees this a
money spinner, or wants any sort of competitiveness. This is strictly
a project to benefit TeX users the world over, and the publishers
interest is in getting new users so that they buy books. There are
some questions here:
a. do we want to keep it entirely in the user group family, taking
all the financial risks, and all the profits and credit?
b. can the commercial firms price it low enough to let us get it to
members in large quantities, and get copies to the East Europeans very
cheaply?
c. if we go with a real publisher, it becomes even more vital that we
get it right! ORA or A/W will want something that *works* - well,
dont we all?
d. what does TUG want out of this? i originally saw it as something
in which TUG could really play a role as the international group,
and have a `visible' product. there is a danger here that a
`commercial' disk would lose TUG some prestige
My suggestion: we publish a CD on behalf of a consortium of TeX User
Groups (ie the participating groups would have their names on the
cover, as it were), and ask a commercial firm to license it from us.
Christina said
--------------
>
> > will all authors allow us to put stuff on a CD which makes a profit?
> > what about shareware things like OzTeX?
>
> Sounds like semi-legal counsel is needed here ;-) Or at least someone
> who can dig up the rules and regulations for copyleft and shareware,
> not to mention of course finding out what the authors themselves want.
this is clear enough. we are OK legallly to distribute OzTeX on the
CD (though obviously we point out the shareware rule), and Andrew is
happy to be involved. Anything which is copylefted we can include, and
make money from if we can, so long as we provide full sources. I would
suggest that we ask TeX authors to use the GNU Copyleft in their work
in future, to make this clear.
> > 5. Do we include more than one program in a given category? for Mac,
> > for instance, do we have OzTeX? DirectTeX? CMacTeX?
>
> Choose on the basis of popularity? Fewest bugs/hassles? Imply a scale
> of good to bad ... ? Or just try and get them all on, and let the user
> make the decision -- one implementation may be good for user A, but
> user B finds that it's not as good as another ...
>
> In short -- when do you decide to use space limitations as a deciding
> criterion?
650 Mb is not *that* much. we will have to limit ourselves to one
system for each platform, in my view.
Karl said
---------
> 1. Do we want a commercial publisher? Addison-Wesley, eg, are willing to
>
> Do we have a choice? I had the impression no one had the capital to cut
> the CD.
we need to find enough groups willing to invest. if 500 copies are
ordered in advance, its no problem at all. it does require the LUGs to
invest money, but not impossible amounts.
> 6. Assuming it is *possible* to mount the CD as a file system, and run
> with it, most people will install a section onto local disk. What
> sort of scripts and interfaces do we need to automate this?
> Ones that will be extremely painful to write, debug, and have them work
> in all the trillions of environments people will be using them in!
we'd probably have to give them all Perl as part of their binary kit.
> Unix: Sparc, HP9000, RS6000, Irix, Alpha Unix, Linux
> Sparc means both SunOS and (shudder) Solaris?
you tell me. does Solaris run Sunos binaries?
> TFM (T1 and OT1) files for 35 PostScript fonts
> What about including the free Type 1 fonts from IBM/Bitstream/URW?
> At least optionally.
natch
> D) font-related macro kits
> music
> I'd hardly call musictex a ``font-related macro kit''. But maybe you're
> talking about something else here.
semantics. musictex, anyway
> Unix: /usr/local/lib/tex (compatibility with GNU)
> I suggest /usr/local/lib/texmf. .../tex is already being used at many
> sites to be just the TeX- (not MF-)related files.
i see what you mean. a clean break at least. but confusing to the many
many people who dont know about MF. i dont care.
> - bases [MF bases]
> - formats
> I don't see any need for separate directories here. I would just have
> `formats'.
yes. why do we always make them different?
> By the way, does this mean I have to modify Metafont to read plain.bas
> in response to &plain? I guess so.
doesnt it already? :-}
> - one subdirectory for each supported MF mode
> - directory for each dpi
> - fontname.pk
> I think all font directories should be by typeface. The idea of one pk/
> directory is a bad one imho.
i take the point, but i think this is one area where we have to
compromise for the DOSsers. the huge directory search is going to take
time and memory for them, even if they can do it, and there are a lot
of programs to convert to a very different way of working. I think its
asking too much of Eberhard Mattes at this stage.
Piet said
---------
> to much fancy features. In your kpath search heuristics there are too much
> fancy things: a) we don't need b) are hard to implement on non UNIX
> platforms. Will your dvipsk and xdvik ever become standard on
> UNIX?
if we put them on our CD...
> - a META directory structure (not necessary acceptable by any system)
> - no hard wired paths inside executables
> although I like UNIX I don't like these hardwired paths. We
i think Karl already has this on board to implement, with
config files for web2c TeX.
> - exchangable format files (one per country for all machines?)
> That would also ease the process of making the installation painless.
> I am afraid that the fixed length arrays of TeX makes format files
> not exchangable.
what *is* the expert opinion on this?
> - software that can convert from a META structure into a machine
> dependant structure. It should be possible, although not trivial, to
> write client/server programs that can ease the installation or update
> of an existing TeX installation. The server runs on a CTAN archive and
> knows about the META TeX, the client runs on a whatever box and knows
> how to convert the META stuff into BOX stuff.
> - the same kind of software could use the CD with META TeX from the CTAN
> server and move (updating, installing) it into machine dependant
> format on your harddisk.
this is what we had in mind for CTAN (see half-hearted discussions on
and off all summer between self, George and Rainer); it just finding
the time and energy to do it all (which is why we are all here). BUT
are we sure we want to go down this path, of a CD which isn't actually
_directly_ useable by anyone? i can see the attractions, and it solves
all sort of problems (eg ^J vs ^M vs ^M^J in text files) and allows
compression. it would also allow us to use existing directory
structures of TeXes, which needn't be the same. This is a central
decision to take!!! it means that our _real_ product is a set of
reliable, extensible, scripts which take CTAN/CD products and
install/de-install them for all supported platforms. which is a very
different thing from a disk with a very large working TeX setup for
multiple platforms.
>
> Please no mountable CD-ROM solutions. I think the ISO9660 CD-ROM
> standard again is a modulo MSDOS solution. Only allowing for uppercase
> names restricted to 8+3 characters. I have looked at the NLUUG CD-ROM
> we got at our Unix Users Group. There was TeX on it. It consisted of
> a README.TXT;1 and SUNTEX.TAZ;1. You may guess where the `;' comes
on the other hand, look at the Linux CD i just purchased for 20
pounds. i can use it either by mounting it as a file system, or
installing off it onto my hard disk, or a combination, or just using
it to browse for interesting stuff. thats the sort of model i had in mind
Rainer said
-----------
> What about SGI and Ultrix Mips? And what about the lesser known ones
> (System V.4 on 386, Data General AViiOn,....)
i see the aim being to establish exactly what and where a Unix TeX is.
we dont actually have to provide for all the little nasties like the
AViiOn (i have bad memories of one), so long as we have source ready
to go with a configure;make (which thanks to Karl we essentially do).
the stuff thats missing from web2c for beginners (fonts and macros)
the funny Unixes just use as normal
Sebastian
================================================================================
Archive-Date: Mon, 13 Dec 1993 06:54:47 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 13 Dec 1993 07:54:23 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199312131254.AA00889@ora.com>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: TeX cd plans
References: <9312121840.AA22130@ftp.tex.ac.uk>
Reply-To: TeX-CD@SHSU.edu, norm@ora.com
On 12 December 93, spqr@ftp.tex.ac.uk wrote:
> > > 5. Do we include more than one program in a given category? for Mac,
> > > for instance, do we have OzTeX? DirectTeX? CMacTeX?
> > [...]
> > In short -- when do you decide to use space limitations as a deciding
> > criterion?
> 650 Mb is not *that* much. we will have to limit ourselves to one
> system for each platform, in my view.
I don't like this idea. It alienates everyone using packages that we don't
include. I still think a double-CD set may be the way to go. One CD for
binaries and system-dependent stuff and another for system-independent things
like fonts and sources files...
> > - directory for each dpi
> > - fontname.pk
> > I think all font directories should be by typeface. The idea of one pk/
> > directory is a bad one imho.
> i take the point, but i think this is one area where we have to
> compromise for the DOSsers. the huge directory search is going to take
> time and memory for them, even if they can do it, and there are a lot
> of programs to convert to a very different way of working. I think its
> asking too much of Eberhard Mattes at this stage.
Which ever way we distribute it on CD, let's make sure the user has the option
of installing it either way. Since they may be running it off of the mounted
CD, I'm inclined to say let's distribute it organized by typeface because
that is a *huge* improvement over the old way...
> Piet said
> ---------
> > to much fancy features. In your kpath search heuristics there are too much
> > fancy things: a) we don't need b) are hard to implement on non UNIX
> > platforms.
Clearly, there are some issues of personal preference on this point. I
resisted the kpathsea heuristics myself for a long time (partly becuase I
had an existing installation and didn't feel I had the time or resources to
reorganize it). But recently, I had an opportunity to start "from scratch"
and I used subtree-by-typeface organization. I'll never go back. I'll
hack other utility sources to support it before I'll go back to the old
way... ;-)
> > Will your dvipsk and xdvik ever become standard on
> > UNIX?
Yes.
> > - a META directory structure (not necessary acceptable by any system)
> > - no hard wired paths inside executables
Well, how about no hard-wired paths that aren't configurable. It's helpful
to have some defaults built into the executable. Otherwise, you have to make
sure everyone understands all the different environment settings before they
even test the installation.
> structures of TeXes, which needn't be the same. This is a central
> decision to take!!! it means that our _real_ product is a set of
> reliable, extensible, scripts which take CTAN/CD products and
> install/de-install them for all supported platforms. which is a very
> different thing from a disk with a very large working TeX setup for
> multiple platforms.
That'd be *really* hard to implement.
> > Please no mountable CD-ROM solutions. I think the ISO9660 CD-ROM
> > standard again is a modulo MSDOS solution. Only allowing for uppercase
> > names restricted to 8+3 characters. I have looked at the NLUUG CD-ROM
> > we got at our Unix Users Group. There was TeX on it. It consisted of
> > a README.TXT;1 and SUNTEX.TAZ;1. You may guess where the `;' comes
> on the other hand, look at the Linux CD i just purchased for 20
> pounds. i can use it either by mounting it as a file system, or
> installing off it onto my hard disk, or a combination, or just using
> it to browse for interesting stuff. thats the sort of model i had in mind
Absolutely.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does not
O'Reilly & Associates, Inc. | absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800 |
================================================================================
Archive-Date: Mon, 13 Dec 1993 08:15:41 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 13 Dec 93 14:07:57 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312131407.AA01685@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: TeX cd plans
References: <199312131254.AA00889@ora.com> <9312121840.AA22130@ftp.tex.ac.uk>
Norman Walsh writes:
> > 650 Mb is not *that* much. we will have to limit ourselves to one
> > system for each platform, in my view.
>
> I don't like this idea. It alienates everyone using packages that
> we don't include. I still think a double-CD set may be the way to
> go. One CD for binaries and system-dependent stuff and another for
> system-independent things like fonts and sources files...
once we have 2 CDs, we pretty much forget the mounting of the disk,
dont we? or we assume that you always install binaries on your HD?
2 CDs doubles the cost, doesnt it? i am not against it, but it is
moderately critical that the price is low.
i quite appreciate the point about having multiple copies of the same
thing. but where do you stop? so you include sbTeX? and dosTeX? and
gTeX? and all those crummy previewers? my experience is that people
*complain* about the choice on CTAN and say "we just want the
best/what everyone else has". i dunno. we just need to play this by
ear, with no set rules
> reorganize it). But recently, I had an opportunity to start "from scratch"
> and I used subtree-by-typeface organization. I'll never go back. I'll
> hack other utility sources to support it before I'll go back to the old
> way... ;-)
the Berry fan club gets larger...
sebastian
================================================================================
Archive-Date: Mon, 13 Dec 1993 08:34:12 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 13 Dec 1993 09:33:38 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199312131433.AA05004@ora.com>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: TeX cd plans
References: <199312131254.AA00889@ora.com> <9312121840.AA22130@ftp.tex.ac.uk> <9312131407.AA01685@ftp.tex.ac.uk>
Reply-To: TeX-CD@SHSU.edu, norm@ora.com
On 13 December 93, spqr@ftp.tex.ac.uk wrote:
> > > 650 Mb is not *that* much. we will have to limit ourselves to one
> > > system for each platform, in my view.
> >
> > I don't like this idea. It alienates everyone using packages that
> > we don't include. I still think a double-CD set may be the way to
> > go. One CD for binaries and system-dependent stuff and another for
> > system-independent things like fonts and sources files...
> once we have 2 CDs, we pretty much forget the mounting of the disk,
> dont we? or we assume that you always install binaries on your HD?
Yes, I would assume that binaries are almost always installed on the HD.
Running a large binary off a CD must be really painfull. Still, for
infrequently used programs...
> 2 CDs doubles the cost, doesnt it? i am not against it, but it is
> moderately critical that the price is low.
Two CDs are more expensive than one, but I doubt it doubles the price.
What's everyone's notion of an ideal price for this disk, anyway?
> gTeX? and all those crummy previewers? my experience is that people
> *complain* about the choice on CTAN and say "we just want the
> best/what everyone else has". i dunno. we just need to play this by
> ear, with no set rules
Yep.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net. The
90 Sherman Street | proof is left as an exercise for your kill-file."
Cambridge, MA 02140 |
(617) 354-5800 |
================================================================================
Archive-Date: Mon, 13 Dec 1993 13:12:51 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 13 Dec 1993 19:21:14 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9312131821.AA16784@risc1.rug.nl>
To: TeX-CD@SHSU.edu, norm@ora.com
Subject: Re: TeX cd plans
I like the idea of a dubble cd-set too, given that the software runs and enjoys some po
popularity. It is noo problem to pumt the CD full with some codes---if we forget
about the market---the challenge is to provide useful, etc AND documented
materials. That will make us more and more modest and realistic.
---Kees---
================================================================================
Archive-Date: Wed, 15 Dec 1993 12:02:38 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 15 Dec 1993 13:02:06 -0500
From: "K. Berry" <kb@cs.umb.edu>
Message-ID: <199312151802.AA19534@terminus.cs.umb.edu>
To: spqr@ftp.tex.ac.uk
CC: tex-cd@shsu.edu
Subject: Re: TeX cd plans
Reply-To: TeX-CD@SHSU.edu, kb@cs.umb.edu
I thought all of CTAN was about 1GB. In that case, one CD (660MB,
right?) ought to be plenty of room, I would think.
my experience is that people
*complain* about the choice on CTAN and say "we just want the
best/what everyone else has".
I wholeheartedly concur; the CD does not need to offer zillions of
choices of pretty-much-equivalent programs just because they exist.
let's distribute it organized by typeface because
that is a *huge* improvement over the old way...
The *production* font organization (what dirs tex & friends look in at
runtime) is independent of the fonts get installed. For installation,
I'd guess that people will either say ``I want the standard font set for
my LJ 4'' or they will say ``I want the standard fonts and these extra
fonts old-english, tengwar, and utopia'', i.e., by typeface.
> Ones that will be extremely painful to write, debug, and have them work
> in all the trillions of environments people will be using them in!
we'd probably have to give them all Perl as part of their binary kit.
Uniformly using Perl will help somewhat, but it's hardly a panacea.
There's going to be a lot real effort involved in writing in the
installation scripts.
================================================================================
Archive-Date: Wed, 15 Dec 1993 12:21:03 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 15 Dec 1993 13:19:27 -0500
From: "K. Berry" <kb@cs.umb.edu>
Message-ID: <199312151819.AA19568@terminus.cs.umb.edu>
To: spqr@ftp.tex.ac.uk
CC: tex-cd@shsu.edu
Subject: Re: TeX cd plans
Reply-To: TeX-CD@SHSU.edu, kb@cs.umb.edu
> Sparc means both SunOS and (shudder) Solaris?
you tell me. does Solaris run Sunos binaries?
Only if they are dynamically linked and meet various other restrictions
I forget. Distributing dynamically linked binaries would be a big lose,
imho, both because people are running lots of different versions of
SunOS and *certainly* because the same X libraries aren't available
everywhere.
> I don't see any need for separate directories here. I would just have
> `formats'.
yes. why do we always make them different?
Gosh, I don't know. I remember having a separate mf/ directory back in
the days when we used pxp and pc to compile the Pascal sources directly!
Just history.
Anyway, Pierre's and my recommended hierarchy (and the next web2c) will
have them combined.
the huge directory search is going to take
time and memory for them,
I don't care if everyone automatically searches subdirectories, but
``organizing'' the font files so that several thousand PK's are in one
directory is, imho, not the way to go.
> - exchangable format files (one per country for all machines?)
> That would also ease the process of making the installation painless.
> I am afraid that the fixed length arrays of TeX makes format files
> not exchangable.
what *is* the expert opinion on this?
I don't think format files are interchangeable among implementations,
nor can they be reasonably be made so. We'd all have to agree on the
same array sizes for the different platforms, for one thing. Also, web2c
at least doesn't use the unmodified code in tex.web, but dumps things
slightly differently to make writing and reading faster. Also to allow
more 255 hyphenation opcodes (or something like that, anyway, trie_hyph
dumping is also modified).
================================================================================
Archive-Date: Wed, 15 Dec 1993 13:13:39 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 15 Dec 93 18:29:07 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312151829.AA00781@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: TeX kit no-no
References: <199312151819.AA19568@terminus.cs.umb.edu>
It seems that the term `TeX-kit' is a trademark, so we cannot use it.
Yes, my reaction was an incredulous laugh too, but if thats the way it
is....
I suggest we start using the term `TeX Collection' - how do we go
about resgitering it as a trade mark?
sebastian
================================================================================
Archive-Date: Wed, 15 Dec 1993 13:23:17 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <9312151922.AA03711@aquarius.cpb.nl>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: TeX kit no-no
Date: Wed, 15 Dec 93 20:22:46 +0100
From: J.J.Winnink@cpb.nl
Reply-To: TeX-CD@SHSU.edu, J.J.Winnink@CPB.NL
> It seems that the term `TeX-kit' is a trademark, so we cannot use it.
> Yes, my reaction was an incredulous laugh too, but if thats the way it
> is....
>
> I suggest we start using the term `TeX Collection' - how do we go
> about resgitering it as a trade mark?
>
> sebastian
If trade marking a term like `TeX Collection' prevents us from problems
in the future i think it a reasonable sugestion.
________________________________________________________________________________
Jos Winnink
Central Planning Bureau
Applied Mathematics & Computer Science Dept.
v Stolkweg 14
P.O. BOX 80510
2508 GM The Hague
The Netherlands
internet: jos.winnink@cpb.nl
X-400: /C=nl/ADMD=400net/PRMD=surf/O=cpb/S=winnink/G=jos/
Telephone (+31) 70 338 3339
Telefax (+31) 70 338 3350
================================================================================
Archive-Date: Wed, 15 Dec 1993 13:26:13 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 15 Dec 1993 14:24:57 -0500
From: "K. Berry" <kb@cs.umb.edu>
Message-ID: <199312151924.AA19864@terminus.cs.umb.edu>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
CC: tex-cd@shsu.edu
Subject: Re: TeX kit no-no
Reply-To: TeX-CD@SHSU.edu, kb@cs.umb.edu
It seems that the term `TeX-kit' is a trademark, so we cannot use it.
By whom and for what? If it has nothing to do with our TeX, we can still
use it.
I suggest we start using the term `TeX Collection' - how do we go
about resgitering it as a trade mark?
My uninformed guess is that you have to do this separately in each
country, i.e., much hassle and probably money. I don't think it's worth
it. Just getting a term into common use is probably enough for our
purposes, after all; I doubt anyone would muscle in and sue TUG or whatever.
(I really hate the little TM's and R's after every other word in
technical books these days ... aren't there enough lawyers in the world
without us feeding a couple more?)
================================================================================
Archive-Date: Wed, 15 Dec 1993 13:36:57 CST
Sender: CTAN-Mgr@SHSU.edu
Date: 15 Dec 1993 14:35:43 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TeX-CD@SHSU.edu, BNB@MATH.AMS.ORG
Subject: Re: TeX kit no-no
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <755984143.190571.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
who's got "TeX-kit" registered as a trademark, and where?
re registering a trademark in the u.s., it's usually useful to
make a trademark search first; i don't know who would do that,
but i can find out. then there's an application to a government
office, accompanied by a fee (which i think may be several $100;
again, i can find out); they do their own search of existing
names, and may or may not accept the application (but you don't
get your money back). if it's approved, the information in the
application is listed in the federal register, and public
comments are invited for a period of 60 or 90 days. if that
passes without any adverse comments, then the registration is
complete. it's usually a good idea to include a logo design
in the application -- that's a better way of distinguishing
the product than just words.
however, ...
"TeX" was refused registration because honeywell already had
"TEX" registered. "collection" is just an ordinary word, and
there's considerable resistance to registering names made of
ordinary words. i'm not sure that "TeX Collection" is "catchy"
enough to be approved -- notice the addition of the hyphen in
"TeX-kit"; i'm sure that's the reason for its inclusion.
and finally, all this is best done by a lawyer. i was involved
peripherally in the registration of the trademark "afii" (for
the association for font information interchange) several years
ago. i believe the total cost was upwards of $500, and the
logo is *very* fancy (the artwork was donated). there were no
challenges. costs go up if there are, of course.
i don't know what the rules are about trademarks registered in
one country being recognized in others, but that should probably
be checked also.
-- bb
================================================================================
Archive-Date: Wed, 15 Dec 1993 15:19:59 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 15 Dec 1993 15:18:36 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, kb@cs.umb.edu
Message-ID: <009770E6.203BFBA0.4369@SHSU.edu>
Subject: Re: TeX cd plans
I know that this isn't TeX CD specific, but as I've seen this a few times
now (and my interest on this is much larger than you can imagine):
> > Ones that will be extremely painful to write, debug, and have them work
> > in all the trillions of environments people will be using them in!
> we'd probably have to give them all Perl as part of their binary kit.
>
> Uniformly using Perl will help somewhat, but it's hardly a panacea. There's
> going to be a lot real effort involved in writing in the installation
> scripts.
Does anyone know of a Perl port to VMS? If so, where can I get it?
--George
================================================================================
Archive-Date: Thu, 16 Dec 1993 14:44:26 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 16 Dec 93 20:36:30 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312162036.AA12244@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: TeX cd plans
References: <199312151802.AA19534@terminus.cs.umb.edu>
"K. Berry" writes:
> I thought all of CTAN was about 1GB. In that case, one CD (660MB,
> right?) ought to be plenty of room, I would think.
not quite. we dont include that many Unix binaries, and a lot of stuff
is compresed. IF we have a mountable disk, as opposed to something
that *has* to be used with an intsall script, i anticipate some
problems.
> Uniformly using Perl will help somewhat, but it's hardly a panacea.
> There's going to be a lot real effort involved in writing in the
> installation scripts.
>
i thought about this, and it made me feel ill. even if one did write a
monster Perl story, it would still look tacky for Windows users. i
think we just have to allocate each platform to one person, and ask
them to produce a solution, and take it. forget consistency, in this
area, if the functionality is there
sebastian
================================================================================
Archive-Date: Thu, 16 Dec 1993 14:46:35 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 16 Dec 93 20:39:46 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312162039.AA12261@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: TeX cd plans
References: <199312151819.AA19568@terminus.cs.umb.edu>
>
> Only if they are dynamically linked and meet various other restrictions
> I forget. Distributing dynamically linked binaries would be a big lose,
> imho, both because people are running lots of different versions of
> SunOS and *certainly* because the same X libraries aren't available
> everywhere.
X libraries are a *pain*! ok static binaries it is, and both solaris
and sunos
> Anyway, Pierre's and my recommended hierarchy (and the next web2c) will
> have them combined.
whats your joint timetables? seems like you are already doing half the
work. we ought to converge
> I don't care if everyone automatically searches subdirectories, but
> ``organizing'' the font files so that several thousand PK's are in one
> directory is, imho, not the way to go.
i think we are all happy to organize PKs in meaningful subdirs. its
the tfms and the style files that are more tricky for most
implementations
sebastian
================================================================================
Archive-Date: Thu, 16 Dec 1993 14:55:12 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 16 Dec 93 20:47:38 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312162047.AA12273@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: TeX kit no-no
References: <199312151924.AA19864@terminus.cs.umb.edu> <9312151829.AA00781@ftp.tex.ac.uk>
"K. Berry" writes:
> It seems that the term `TeX-kit' is a trademark, so we cannot use it.
>
> By whom and for what? If it has nothing to do with our TeX, we can still
> use it.
Mitch Pfeffer. the story does sound extraordinary, but since he wants
to play it that way, why make waves.
>
> I suggest we start using the term `TeX Collection' - how do we go
> about resgitering it as a trade mark?
>
> My uninformed guess is that you have to do this separately in each
> country, i.e., much hassle and probably money. I don't think it's
i wasnt entirely being serious about registering it... just because
other people act unfriendly, we neednt join them
but there *is* a lot to be said for having a nice agreed term for what
we are talking about. Collection isnt ideal, but i havent found a
better. it should be The TeX Collection of course.
sebastian
================================================================================
Archive-Date: Thu, 16 Dec 1993 15:26:30 CST
Sender: CTAN-Mgr@SHSU.edu
Date: 16 Dec 1993 16:23:28 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TeX-CD@SHSU.edu, BNB@MATH.AMS.ORG
Subject: Re: TeX kit no-no
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <756077008.16061.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
kit -- no, taken
collection -- descriptive, but boring
here are some other possibilities, compliments of roget's:
suite
outfit
two more that i enjoyed, but don't think would be universally
appreciated:
congeries
impedimenta
happy holidays, guys.
-- bb
================================================================================
Archive-Date: Sat, 18 Dec 1993 06:27:42 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 17 Dec 93 13:21:48 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9312171321.AA20892@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: TeX kit no-no
References: <199312171231.AA19406@terminus.cs.umb.edu>
"K. Berry" writes:
> As for name, why not the ``TeX CD''?
i guess because we want the same name for ftp, disk and tape sets?
s
================================================================================
Archive-Date: Sat, 18 Dec 1993 07:32:16 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 17 Dec 1993 07:31:52 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU
Message-ID: <199312171231.AA19406@terminus.cs.umb.edu>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: TeX kit no-no
As for name, why not the ``TeX CD''?
================================================================================
Archive-Date: Sun, 19 Dec 1993 07:50:35 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Sun, 19 Dec 1993 14:50:12 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9312191350.AA10439@risc1.rug.nl>
To: TeX-CD@shsu.edu
Dear friends,
If we like the words TeX-Kit but alas it has been taken already,
then the obvious and more suited name should be useful
TeX&METAfont-kit
After all there will be a lot of fonts in there, and
I like to give credit to METAfont too.
Best wishes, ---Kees---
================================================================================
Archive-Date: Mon, 20 Dec 1993 02:40:50 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 20 Dec 1993 08:33:01 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Reply-To: TeX-CD@SHSU.edu, FRAMBACH@ECO.RUG.NL
Subject: Re:
To: TeX-CD@SHSU.edu
Message-ID: <MAILQUEUE-101.931220083301.352@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
This is an automatic reply to your message that contained
no SUBJECT field.
Because my time is valuable I don't want to spend it guessing
what a message is about.
Next time, please supply a SUBJECT field, and I will read your
message.
Erik Frambach
Archive-Date: Thu, 06 Jan 1994 16:30:44 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 6 Jan 94 22:12:37 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401062212.AA25386@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: happy new year, etc
1) its nice to see the New Year starting with good news, that the latest
emTeX beta supports sub-directory searching. given this, is everyone
happy to make one level of subdirectories the standard way to proceed
for the new kit? this means that:
- macros can have a directory for each distinct package
- fonts can be stored by typeface
this latter means that you'd store .tfm, .vf, etc files for a typeface
all in the same directory. but then why not? the PKs are then a
problem, if we have (eg)
fonts/malvern/300dpi/mal10.pk
fonts/cyrillic/600dpi/foo12.pk
because it would mean that the configuration file has to list both
malvern and cyrillic (etc etc) in its list (until/if the drivers all
have subdirectory searching too)
does anyone object to this basic assumption, that we can and should
drop monolithic directories forever?
2) are we agreed that we should create an intermediate type
structure? ie it *could* be used directly, by just copying the
whole setup onto a hard disk, but is also structured with different
packages/fonts etc clearly isolated in their own directories so
that one could write sensible install scripts for different
environments. to me, its less important that we have identical
installation procedures for all the platforms now, than that we
have an agreed contents that can act as a reliable basis for as
many setups as we want to write. what i am thinking is that we can
offer (eg) emTeX+4AllTeX as a canned option, working with the
support stuff, but if Y&Y want to sell the CD with a setup script
for their own product, thats equally fine.
3) In general, how should we proceed with our task? could the NTG people
describe how they'd like to structure the setup for MSDOS?
sebastian
================================================================================
Archive-Date: Fri, 07 Jan 1994 04:56:26 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401071055.AA09904@rw3.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Fri, 7 Jan 1994 11:55:46 MET
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: happy new year, etc
[ Sebastian Rahtz (Jan 6, 23:40):
> 1) its nice to see the New Year starting with good news, that the latest
> emTeX beta supports sub-directory searching. given this, is everyone
> happy to make one level of subdirectories the standard way to proceed
> for the new kit? this means that:
> - macros can have a directory for each distinct package
> - fonts can be stored by typeface
> this latter means that you'd store .tfm, .vf, etc files for a typeface
> all in the same directory. but then why not? the PKs are then a
> problem, if we have (eg)
> fonts/malvern/300dpi/mal10.pk
> fonts/cyrillic/600dpi/foo12.pk
> because it would mean that the configuration file has to list both
> malvern and cyrillic (etc etc) in its list (until/if the drivers all
> have subdirectory searching too)
>
> does anyone object to this basic assumption, that we can and should
> drop monolithic directories forever?
I am very sorry but I don't understand what you mean here:
1) what exacty does the `emTeX beta supports sub-directory searching' do?
2) what `configuration file' are you talking about?
I am not very lucky with these scattered PK fonts around. I think grouping
PK fonts can best be done in some restricted hierarchy:
- on a per system basis
FLI vs. one single directory vs. subdirectories
- on a per printer basis
300dpi vs. 600dpi
If automatic font generation could be installed on all systems we only need
to supply TFM and VF fonts. Because generation of CMR fonts via METAFONT is
slow (70 seconds per font on my 486DXclone) these fonts can better be
supplied as prefabricated sets. Type1 fonts, provided this are clean
PFA/PFB fonts and no GSF fonts, can be rendered within 4 seconds per font
using ps2pk. Gsftopk (on UNIX) renders GSF fonts in about 10 seconds per
font.
But perhaps I have missed your point.
--Piet
================================================================================
Archive-Date: Fri, 07 Jan 1994 06:46:54 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 7 Jan 1994 13:45:44 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9401071245.AA17341@risc1.rug.nl>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: happy new year, etc
CC: e.h.m.frambach@eco.rug.nl, w.dol@lei.agro.nl
Let us look at that, for MS-DOS. Erik, Wietse?
---Kees---
================================================================================
Archive-Date: Fri, 07 Jan 1994 10:59:14 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 7 Jan 94 16:49:13 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401071649.AA05447@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: Re: happy new year, etc
References: <199401071055.AA09904@rw3.urc.tue.nl>
Piet Tutelaers writes:
>
> I am very sorry but I don't understand what you mean here:
> 1) what exacty does the `emTeX beta supports sub-directory searching' do?
it means you can sey
SET TEXINPUTS=\tex\macros!
and it will search in \tex\macros\foo, \tex\macros\bar,
and \tex\macros\foobar with no further ado.
> 2) what `configuration file' are you talking about?
config.ps or lj.cnf, for instance. where one gives the directory root
of .pk files
> I am not very lucky with these scattered PK fonts around. I think grouping
> PK fonts can best be done in some restricted hierarchy:
> - on a per system basis
> FLI vs. one single directory vs. subdirectories
> - on a per printer basis
> 300dpi vs. 600dpi
the problem is the lack of modularity. it would be very nice to have
(for instance) the AMS package all in its own hierarchy, to be deleted
or added as needed, without having to install it in various places
(yes, we could have the equivalent of emTeX's .REM files, i suppose)
>
> If automatic font generation could be installed on all systems we only need
> to supply TFM and VF fonts. Because generation of CMR fonts via METAFONT is
> slow (70 seconds per font on my 486DXclone) these fonts can better be
> supplied as prefabricated sets. Type1 fonts, provided this are clean
> PFA/PFB fonts and no GSF fonts, can be rendered within 4 seconds per font
> using ps2pk. Gsftopk (on UNIX) renders GSF fonts in about 10 seconds per
agreed, CM and DC fonts should be prebuilt at 300dpi and 600dpi. we
*could* supply PKs for stuff like Utopoia and Charter too.
sebastian
================================================================================
Archive-Date: Fri, 07 Jan 1994 14:08:21 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <9401072001.AA03499@aquarius.cpb.nl>
To: TeX-CD@SHSU.edu
Subject: Re: happy new year, etc
Date: Fri, 07 Jan 94 21:01:02 +0100
From: J.J.Winnink@cpb.nl
Reply-To: TeX-CD@SHSU.edu, J.J.Winnink@CPB.NL
> Piet Tutelaers writes:
> >
> > I am very sorry but I don't understand what you mean here:
> > 1) what exacty does the `emTeX beta supports sub-directory searching' do?
> it means you can sey
> SET TEXINPUTS=\tex\macros!
> and it will search in \tex\macros\foo, \tex\macros\bar,
> and \tex\macros\foobar with no further ado.
>
The new beta version (texb9.zip) of emTeX has this feature built in. And it
is a nice way to organize things, although filenames have to be different,
otherwise you can't tell which file is used, a (sub)directory search order is
not defined. Prepending file's belonging to a package with a prefix could
solve this problem, but with 8.3 filenames? Using a 3 character postfix for a
package?
> > If automatic font generation could be installed on all systems we only need
> > to supply TFM and VF fonts. Because generation of CMR fonts via METAFONT is
> > slow (70 seconds per font on my 486DXclone) these fonts can better be
> > supplied as prefabricated sets. Type1 fonts, provided this are clean
> > PFA/PFB fonts and no GSF fonts, can be rendered within 4 seconds per font
> > using ps2pk. Gsftopk (on UNIX) renders GSF fonts in about 10 seconds per
> agreed, CM and DC fonts should be prebuilt at 300dpi and 600dpi. we
> *could* supply PKs for stuff like Utopoia and Charter too.
I agree with thi
________________________________________________________________________________
Jos Winnink
Central Planning Bureau
Applied Mathematics & Computer Science Dept.
v Stolkweg 14
P.O. BOX 80510
2508 GM The Hague
The Netherlands
internet: jos.winnink@cpb.nl
X-400: /C=nl/ADMD=400net/PRMD=surf/O=cpb/S=winnink/G=jos/
Telephone (+31) 70 338 3339
Telefax (+31) 70 338 3350
================================================================================
Archive-Date: Fri, 07 Jan 1994 15:08:23 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 7 Jan 94 20:50:57 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401072050.AA06465@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: happy new year, etc
References: <9401071649.AA05447@ftp.tex.ac.uk> <9401072001.AA03499@aquarius.cpb.nl>
J.J.Winnink@cpb.nl writes:
> The new beta version (texb9.zip) of emTeX has this feature built
> in. And it is a nice way to organize things, although filenames
and i say, lets assume we use this
> have to be different, otherwise you can't tell which file is
> used, a (sub)directory search order is not defined. Prepending
> file's belonging to a package with a prefix could solve this
> problem, but with 8.3 filenames? Using a 3 character postfix for
> a package?
my opinion is that this is not really a problem. firstly, how many
duplicate names are there, really? secondly, you can give an explicit
set of directories to TEXINPUTS to get round a special problem (like
adding in, or not, latex2e at the moment). i've never had a duplicate
name problem under Unix - has anyone else suffered?
sebastian
================================================================================
Archive-Date: Mon, 10 Jan 1994 05:57:52 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 10 Jan 1994 12:41:29 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Subject: Re: happy new year, etc
To: TeX-CD@SHSU.edu
Reply-To: TeX-CD@SHSU.edu, TeX-CD@shsu.edu
Message-ID: <MAILQUEUE-101.940110124129.256@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
> > it means you can sey
> > SET TEXINPUTS=\tex\macros!
> > and it will search in \tex\macros\foo, \tex\macros\bar,
> > and \tex\macros\foobar with no further ado.
> >
> The new beta version (texb9.zip) of emTeX has this feature built in. And it
> is a nice way to organize things, although filenames have to be different,
> otherwise you can't tell which file is used, a (sub)directory search order is
> not defined. Prepending file's belonging to a package with a prefix could
> solve this problem, but with 8.3 filenames? Using a 3 character postfix for a
> package?
Yes, emTeX beta 9 has this feature, and, as with any new version, it has
some bugs. Some of them are serious!
Though I agree that subdirectory searching is useful, I think we should
stick to programs of which we _most_definitely_know_ that they work!
So I say let's use beta 8. This one is known to work very well, at least
I know of no bugs at all.
Besides, emTeX may be able to search subdirectories, but what about the
TeX compilers on all the other platforms? I think we should try to get
as much uniformity as possible.
The same goes for other programs. Let's use the programs that are _known_
to work well _now_. No promesses, no regrets.
As for a directory set-up for fonts: structuring by font family is fine,
but does it actually work on all platforms, given the current drivers?
Here is a good test: try to get automatic font generation to work.
Yes, I'm very conservative in this matter. That is because we cannot expect
the people who will use the cd to be hackers who will spend a day or so
to get everything to work properly. Most of them probably bought the cd
because it makes things easy! And so it should.
Let's also not make things too difficult for ourselves. New versions take
much time to test. This cd should be out this year...
Erik Frambach
================================================================================
Archive-Date: Tue, 11 Jan 1994 15:31:15 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 11 Jan 94 21:21:57 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401112121.AA02601@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: happy new year, etc
References: <MAILQUEUE-101.940110124129.256@eco.rug.nl>
Erik Frambach writes:
> Yes, emTeX beta 9 has this feature, and, as with any new version, it has
> some bugs. Some of them are serious!
> Though I agree that subdirectory searching is useful, I think we should
> stick to programs of which we _most_definitely_know_ that they
> work!
well, i agree in principle, but Eberhard does has a reputation for
very solid betas. i'd be surprised if beta9 isnt as solid as beta 8
very soon
> Besides, emTeX may be able to search subdirectories, but what about the
> TeX compilers on all the other platforms? I think we should try to get
> as much uniformity as possible.
well, Unix obviously does it. so does VMS. Macs are weird anyway.
VM/CMS is impossible for all sorts of reasons. what does that leave?
Amiga and Atari, and i just dont rate their popularity highly enough
to work down to their level
> The same goes for other programs. Let's use the programs that are _known_
> to work well _now_. No promesses, no regrets.
its a good principle. but we should also be *slightly*
forward-looking. give people a point to look up at?
> As for a directory set-up for fonts: structuring by font family is fine,
> but does it actually work on all platforms, given the current
but if it works for half the users, and the other half have to use an
install script to get things in place, surely the advantages of a
clean modular setup are huge? most people will use a selective install
anyway, after all (ticking boxes for macros and fonts)
> Here is a good test: try to get automatic font generation to work.
I am assuming Piet's mtpk will do the job...
> the people who will use the cd to be hackers who will spend a day or so
> to get everything to work properly. Most of them probably bought the cd
> because it makes things easy! And so it should.
i fear that we cannot win. few people will want to copy the whole CD
to their hard disk, so they'll need a nice interface to decide what to
copy. once we are in that, we can install it on their disks in massive
one-level directories if need be. but ifthe base disk is not clean,
we cant make it look clean for people who *do* hack teh disk directly
sebastian
================================================================================
Archive-Date: Tue, 11 Jan 1994 18:13:32 CST
Sender: CTAN-Mgr@SHSU.edu
From: Paul Taylor <pt@doc.ic.ac.uk>
Reply-To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Date: Wed, 12 Jan 1994 00:12:03 +0000
To: TeX-CD@SHSU.edu, spqr@ftp.tex.ac.uk
Subject: subdirectory searching in TeX
Message-ID: <"swan.doc.i.604:12.00.94.00.12.08"@doc.ic.ac.uk>
I think it's about time someone put the case AGAINST subdirectory
searching. (Maybe if Tomas Rokicki is on this list he could back me up.)
If you want your personal standalone PC to make a full directory listing
of its entire 100 megabyte disk every time you start TeX up, that's fine
by me - use subdirectory searching.
But I don't want several hundred users throughout Imperial College doing
that to my gigabyte disk, thrashing that and the Ethernet into the bargain.
Before long it will be common to cross-mount filesystems over the InterNet.
Careless use of sibdirectory searching will lead to floods of satelite
traffic just because you mis-typed artical.sty.
"This is fanciful, because the searching would be limited to relevant
TeX directories".
Nonsense. Somebody referred to the "ticking boxes" way of installing
things. Naive users tick *all* the boxes to be sure of not being left out
of any of the fun. They'll add whole filesystems to the search paths
to make sure TeX can find things.
I suggest using the MakeTeXTeX hook in TeX/web2c, which I'm sure emTeX
could easily emulate, to fetch files in an orderly fashion from the
achive or CD and put them in a cache directory, using a directory listing
provided in a file in the archive.
Paul
================================================================================
Archive-Date: Wed, 12 Jan 1994 03:59:47 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 12 Jan 1994 10:41:58 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Subject: Re: happy new year, etc
To: TeX-CD@SHSU.edu
Reply-To: TeX-CD@SHSU.edu, E.H.M.Frambach@eco.rug.nl
Message-ID: <MAILQUEUE-101.940112104157.480@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
[...]
> > Yes, emTeX beta 9 has this feature, and, as with any new version, it has
> > some bugs. Some of them are serious!
> > Though I agree that subdirectory searching is useful, I think we should
> > stick to programs of which we _most_definitely_know_ that they
> > work!
> well, i agree in principle, but Eberhard does has a reputation for
> very solid betas. i'd be surprised if beta9 isnt as solid as beta 8
> very soon
Mattes already announced beta 10, because of bugs in beta 9.
Looking forward is fine, but how far?
In other words, how much time is there to decide what we will do?
> I am assuming Piet's mtpk will do the job...
We need to test!
> > the people who will use the cd to be hackers who will spend a day or so
> > to get everything to work properly. Most of them probably bought the cd
> > because it makes things easy! And so it should.
> i fear that we cannot win. few people will want to copy the whole CD
> to their hard disk, so they'll need a nice interface to decide what to
> copy. once we are in that, we can install it on their disks in massive
> one-level directories if need be. but ifthe base disk is not clean,
> we cant make it look clean for people who *do* hack teh disk directly
Yes, the biggest challenge is to provide a nice interface for all platforms.
I think many people will copy (almost) all to their harddisk, simply because
a CD is read-only. That can be a big problem for e.g. font and format
generation, updates of files, hard coded configuration files...
Am I too pessimistic?
Erik Frambach
================================================================================
Archive-Date: Wed, 12 Jan 1994 09:45:13 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 12 Jan 94 15:08:56 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401121508.AA14201@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: happy new year, etc
References: <MAILQUEUE-101.940112104157.480@eco.rug.nl>
Erik Frambach writes:
> Mattes already announced beta 10, because of bugs in beta 9.
> Looking forward is fine, but how far?
> In other words, how much time is there to decide what we will do?
my preferred solution is:
- get everything on the CD in its own subdirectories
- write install scripts (one in perl for Unix and DOS, one Windows,
one Mac) which copy stuff to hard disk. by default they copy all
to the same inputs or tfm or whatecer directory, but will
optionally put in sepratae directories. in the former case, they
write `remove' files
- people who want to can run emTeX betatest or web2c subdir
serarching, but it wont be the default
does that sound reasonable?
i'd like to put together a*real* list of contents to comment on, and
then we several people can start on the isnstall scripts...
> I think many people will copy (almost) all to their harddisk, simply because
> a CD is read-only. That can be a big problem for e.g. font and format
> generation, updates of files, hard coded configuration files...
and speed!
> Am I too pessimistic?
slightl;y :-}
sebastian
================================================================================
Archive-Date: Wed, 12 Jan 1994 17:23:28 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401122317.AA21773@rw3.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Thu, 13 Jan 1994 00:17:31 MET
To: TeX-CD@SHSU.edu
Subject: Late night thoughts
Maintaining TeX on multivendor platforms (for example on
UNIX:SUN,HP,SGI,...) is quite a complicated matter because of the
differences between these closely related systems. It is clear that
maintaining TeX on multi OS platforms (MSDOS, MSWindows, OS/2,
UNIX, VAX-VMS, etc.) is even more complex. The wish to bring a
CD-ROM that suits all these different OS-es is therefore easier
said than done!
The only way we can cooperate between all these different platforms is by
choosing portable standards. What do we mean with portable? Should it run
straight of the box on all systems? I am afraid we can't unless we accept
modulo `MSDOS' solutions. This means that all non-MSDOS users will suffer
from the same limitations as MSDOS does. But if we don't choose a modulo
MSDOS standard what else do we choose?
Thanks to UNIX and the INTERNET we now have a lot of file servers that
offer TeX archives. So now and then you see VAX-VMS archives but I think
these are a minority nowadays. So my suggestion is to choose the UNIX TeX
tree as a defacto standard. How is this UNIX TeX tree defined? The basic
structure of this UNIX TeX tree can be very simple (although the actual
standard defined by web2c is different!):
TEXROOT/sub/subsub/subsubsub (maximum depth 3)
---------------------------------------------
TEXROOT/bin
TEXROOT/fonts/tfm
TEXROOT/fonts/vf
TEXROOT/fonts/pk300
TEXROOT/fonts/pk600
TEXROOT/fonts/mffaces/cm
TEXROOT/fonts/mffaces/dc
TEXROOT/fonts/t1faces/mathtime
TEXROOT/fonts/t1faces/resident
TEXROOT/formats
TEXROOT/macros/ams
TEXROOT/macros/babel
TEXROOT/macros/bib
TEXROOT/macros/dvips
TEXROOT/macros/etc
TEXROOT/macros/foiltex
TEXROOT/macros/index
TEXROOT/macros/latex
TEXROOT/macros/nfss
TEXROOT/macros/ntg
TEXROOT/macros/patterns
TEXROOT/macros/pictex
TEXROOT/macros/plain
TEXROOT/macros/tugboat
TEXROOT/macros/web
TEXROOT/man
TEXROOT/mf
TEXROOT/mf/bases
TEXROOT/mf/macros
This is my favourite TeX structure. TEXROOT is a directory which contains
all TeX related programs (like MF). Within this TeX tree the following
rules are obeyed:
- no directory name should be longer than 8 characters
- directory names should not contain extensions
- directory names should contain only lowercase characters and digits
- no directories are allowed below level three
- all files within a directory should be of the same `nature' (so no
mixture of TFM and .sty files in one directory)
- directories containing subdirectories (like macros) should be
searched as if it would be one single directory; this means that no
double names are allowed
- directories should not contain subsubdirectories (no recursive path
search heuristics)
- font directories may contain subdirectories to hold PK fonts
that otherwise can't be stored (to overcome the MSDOS extension limit
of 3), for example cmr10.300pk is stored as fonts/pk300/cmr10.pk.
Why all TeX related material in one TEXROOT?
- to avoid that we have to digg around in order to find our complete TeX
collection
- allows to have two diffent versions at the same time.
Why all TeX executables in the same TeX tree?
For a long time I kept my execuatbles in /usr/local/bin. But when you have
to install a new version it is very difficult to find out which programs in
/usr/local/bin are TeX related and which are not.
The TEXROOT should be movable.
Sometimes we grow out of our disk space. Then we may have to move TeX
to another disk. But most TeX programs use hard wired paths. Some
UNIX systems allow to have system wide environment variables (similar
to VAX-VMS). If all file references would be made via the TEXROOT
environment variable changing from disk would be merely a question
of redefining this TEXROOT. (On EmTeX Eberhard Mattes already has defined
EMTEXDIR with a similar meaning!)
Why should we allow that macros (styles or inputs) are divided in
subdirectories?
I think there is no other reason than maintainability. Having all babel
stuff in one directory makes it easier to update the fast changing babel
stuff than when you have all these babel related material in one single
directory. On the longer term we could develop a package `metafore' to
handle this maintenance problem more definitely. Eberhard Mattes has
implemented a simple minded package idea that allows to install a package
and to de-install it. I think a foolproof package system should offer
operations like:
- installing
- updating
- verifying
- de-installing
- ...
Why don't we allow recursive subdirectory search and mixed directories?
The only reason to want them is again maintainability. It allows to group
fonts on a per typeface basis, something like:
TEXROOT/fonts/funnyface/tfm
TEXROOT/fonts/funnyface/vf
TEXROOT/fonts/funnyface/pk300
TEXROOT/fonts/funnyface/pk600
But to handle it we need recursive subdirectory search for TFM, VF
files. Isn't that a too high price? If we would have a standard TeX
file structure distributing the Utopia package like:
TEXROOT/tfm/putr.tfm
TEXROOT/tfm/rputr.tfm
TEXROOT/vf/putr.vf
TEXROOT/macros/dvips/utopia.sty
is not too bad. And if I get my MTPK package finished generating
the PK-fonts for your printer/previewer is not really difficult. All what
is needed is a DVI file that references all font sizes.
It was nice to hear that emTeX has implemented a path heuristic but it was
unpleasant to see that it is different from what Karl has choosen in web2c.
Aren't we one TeX family?
A portable TeX file structure is not necessary a file structure that
runs on every box but one that can easily be installed on every box! It
should become the CTAN standard. Then creating a CD-ROM is just a
question of putting everything on CD-ROM! Appropriate client/server
installation programs can handle differences between different
architectures.
--Piet
================================================================================
Archive-Date: Thu, 13 Jan 1994 16:13:45 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 13 Jan 1994 16:13:10 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Message-ID: <009787B7.8D7DB5E0.26155@SHSU.edu>
Subject: RE: Late night thoughts
On Thu, 13 Jan 1994 00:17:31 MET, P.T.H.Tutelaers@urc.tue.nl (Piet
Tutelaers) posted an interesting hierarchy (being away for a week or so
hasn't helped my mail load, this is among the first I have looked at since
"Late night thoughts" was such an intriguing topic). He ends with:
> A portable TeX file structure is not necessary a file structure that runs
> on every box but one that can easily be installed on every box! It should
> become the CTAN standard. Then creating a CD-ROM is just a question of
> putting everything on CD-ROM! Appropriate client/server installation
> programs can handle differences between different architectures.
Which I totally agree with! I also believe that everyone involved in the
CTAN effort, including the TUG Technical Working Group which was involved
in its conception, would also agree. The trick is evolving the structure
such that it properly boils down to something useful (you don't even want
to know how much of a trick it was to boil down the then-existing archives
into a maintainable and managable CTAN hierarchy!). If and when a more
portable standard is created (and, yes, some will not like the end result
for a variety of personal and political reasons, but that's something else
altogether), I can assure you that it will migrate into the CTAN since
that's where the project is hopefully headed, among other places.
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
Archive-Date: Fri, 14 Jan 1994 06:04:35 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Fri, 14 Jan 94 11:54:57 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401141154.AA03085@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: Late night thoughts
References: <199401122317.AA21773@rw3.urc.tue.nl>
Piet Tutelaers writes:
> UNIX, VAX-VMS, etc.) is even more complex. The wish to bring a
> CD-ROM that suits all these different OS-es is therefore easier
> said than done!
we have to try... it is our sacred duty ....
> modulo `MSDOS' solutions. This means that all non-MSDOS users will suffer
> from the same limitations as MSDOS does. But if we don't choose a modulo
> MSDOS standard what else do we choose?
viz-a-viz filenames, yes. i can live with that. but what else?
> TEXROOT/sub/subsub/subsubsub (maximum depth 3)
agreed, not too many subdirts
> TEXROOT/bin
> TEXROOT/fonts/tfm
> TEXROOT/fonts/vf
this is the battle, isnt it. do we preinstall tfms from their sources,
or leave with their family.
> TEXROOT/fonts/pk300
> TEXROOT/fonts/pk600
> TEXROOT/fonts/mffaces/cm
> TEXROOT/fonts/mffaces/dc
> TEXROOT/fonts/t1faces/mathtime
> TEXROOT/fonts/t1faces/resident
i see no reason to distinguihs mf from t1. or is this for mtpk?
> TEXROOT/mf
> TEXROOT/mf/bases
> TEXROOT/mf/macros
i dont agree with this bit. as Karl said, why not put .bas files in the
same place as .fmt files?
> to VAX-VMS). If all file references would be made via the TEXROOT
> environment variable changing from disk would be merely a question
> of redefining this TEXROOT. (On EmTeX Eberhard Mattes already has defined
> EMTEXDIR with a similar meaning!)
i hope Karl is listening ....
> directory. On the longer term we could develop a package `metafore' to
> handle this maintenance problem more definitely. Eberhard Mattes has
> implemented a simple minded package idea that allows to install a package
> and to de-install it. I think a foolproof package system should offer
you dont adress the issue, however, of whether the CD itself should be
coimposed of your structure, or whether the structure should be built
at install time froma modular CD?
> But to handle it we need recursive subdirectory search for TFM, VF
> files. Isn't that a too high price? If we would have a standard TeX
is it? if it works for pks, why not tfms?
> file structure distributing the Utopia package like:
> TEXROOT/tfm/putr.tfm
> TEXROOT/tfm/rputr.tfm
> TEXROOT/vf/putr.vf
> TEXROOT/macros/dvips/utopia.sty
gasp. where is T1put.fd :-}
sebastian
================================================================================
Archive-Date: Sat, 15 Jan 1994 08:51:13 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401151407.AA05707@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Sat, 15 Jan 1994 15:07:02 MET
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: Late night thoughts
[ Sebastian Rahtz (Jan 14, 13:10):
> > TEXROOT/fonts/pk300
> > TEXROOT/fonts/pk600
> > TEXROOT/fonts/mffaces/cm
> > TEXROOT/fonts/mffaces/dc
> > TEXROOT/fonts/t1faces/mathtime
> > TEXROOT/fonts/t1faces/resident
> i see no reason to distinguihs mf from t1. or is this for mtpk?
I see. Efficiency! On the long term I would like to put my PostScript fonts
there where *all* PS applications can find them. Now I have to install them
separately for GhostScript, dvips, X11, etc.
> > TEXROOT/mf
> > TEXROOT/mf/bases
> > TEXROOT/mf/macros
> i dont agree with this bit. as Karl said, why not put .bas files in the
> same place as .fmt files?
No problem if we *all* put these format files in one directory.
> > directory. On the longer term we could develop a package `metafore' to
> > handle this maintenance problem more definitely. Eberhard Mattes has
> > implemented a simple minded package idea that allows to install a package
> > and to de-install it. I think a foolproof package system should offer
> you dont adress the issue, however, of whether the CD itself should be
> coimposed of your structure, or whether the structure should be built
> at install time froma modular CD?
I think we have no other choice, at the moment, than putting all CTAN stuff
on the CD and making smart scripts that know how to install this CTAN stuff
on all supported architectures. On the longer term we can try to
convince people to use one standard TeX structure. Aren't we too late?
> > But to handle it we need recursive subdirectory search for TFM, VF
> > files. Isn't that a too high price? If we would have a standard TeX
> is it? if it works for pks, why not tfms?
>
> > file structure distributing the Utopia package like:
> > TEXROOT/tfm/putr.tfm
> > TEXROOT/tfm/rputr.tfm
> > TEXROOT/vf/putr.vf
> > TEXROOT/macros/dvips/utopia.sty
> gasp. where is T1put.fd :-}
I have not had time to look at laTeX2e stuff ...
>
It turns out that recursive path searching is indeed the hot discussion.
Paul Taylor has given some reasons why he was definetly AGAINST this
feature (ticking boxes). People can easily misuse this feature.
I will think how my Utopia package would be without the need to have
recursive subdirectory. Perhaps somebody else can show us why he per se
needs it.
--pt
================================================================================
Archive-Date: Sat, 15 Jan 1994 12:03:50 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Sat, 15 Jan 94 17:57:27 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401151757.AA12654@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: re: Latye night thoughts
Piet Tutelaers writes:
> I see. Efficiency! On the long term I would like to put my PostScript fonts
> there where *all* PS applications can find them. Now I have to install them
> separately for GhostScript, dvips, X11, etc.
hmm. i take the point
> I think we have no other choice, at the moment, than putting all CTAN stuff
> on the CD and making smart scripts that know how to install this CTAN stuff
> on all supported architectures. On the longer term we can try to
but the difference will be that we `expand' packages (ie make .sty
files from .doc, and build .tfm files), and have everything
uncompressed, so that people *can* just do a `diskcopy' and run?
> convince people to use one standard TeX structure. Aren't we too late?
no, lets not give up so easily!
>
> I will think how my Utopia package would be without the need to have
> recursive subdirectory. Perhaps somebody else can show us why he per se
> needs it.
>
sorry, who is `he' in this sentence?
sebatsian
------- End of forwarded message -------
================================================================================
Archive-Date: Sat, 15 Jan 1994 12:43:31 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401151842.AA06222@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Sat, 15 Jan 1994 19:42:47 MET
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: re: Latye night thoughts
[ Sebastian Rahtz (Jan 15, 19:05):
> Piet Tutelaers writes:
> > I think we have no other choice, at the moment, than putting all CTAN stuff
> > on the CD and making smart scripts that know how to install this CTAN stuff
> > on all supported architectures. On the longer term we can try to
> but the difference will be that we `expand' packages (ie make .sty
> files from .doc, and build .tfm files), and have everything
> uncompressed, so that people *can* just do a `diskcopy' and run?
OK. In that case you have to make disk images for every system you want to
support. Perhaps that is a good idea. BUT your CD will contain a lot of
double things.
Will that be
> > convince people to use one standard TeX structure. Aren't we too late?
> no, lets not give up so easily!
> >
> > I will think how my Utopia package would be without the need to have
> > recursive subdirectory. Perhaps somebody else can show us why he per se
> > needs it.
> >
> sorry, who is `he' in this sentence?
He is `the somebody'. I expected you as being pro `recursive
subdirectories'.
--pt
================================================================================
Archive-Date: Sun, 16 Jan 1994 05:48:04 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Sun, 16 Jan 94 11:41:35 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401161141.AA01168@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: re: Latye night thoughts
References: <199401151842.AA06222@rwa.urc.tue.nl>
Piet Tutelaers writes:
> > uncompressed, so that people *can* just do a `diskcopy' and run?
>
> OK. In that case you have to make disk images for every system you want to
> support. Perhaps that is a good idea. BUT your CD will contain a lot of
sorry, i didnt mean *literally* diskcopy. more xcopy | cp -r | `drag'n'drop'
> He is `the somebody'. I expected you as being pro `recursive
> subdirectories'.
>
i am pro recursive subdirectories because a) it helps me understand my
hard disk, and b) it helps me update/install/delete packages.but can i
make it clear that i now vote for
- meaningful subdirectories on the CD
- install scripts to fixed directories
- remove files
- Paul Taylor' fetching/caching
in practice for this project
sebastian
================================================================================
Archive-Date: Mon, 17 Jan 1994 05:14:20 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 17 Jan 1994 09:43:21 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Subject: Re: Late night thoughts
To: TeX-CD@SHSU.edu
Reply-To: TeX-CD@SHSU.edu, tex-cd@shsu.edu
Message-ID: <MAILQUEUE-101.940117094320.416@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
Some remarks on the directory structure:
> TEXROOT/bin
We keep true TeX & MetaFont programs in TEXROOT. So I guess you mean that
other programs, such as DVIDVI, WP2LaTeX, TGRIND, BM2font, GhostScript
will reside in `bin'. OK, but let's define at least some subdirectories,
e.g. for GhostScript and other large and more or less standard programs.
Updating wil become easier.
> TEXROOT/fonts/pk300
> TEXROOT/fonts/pk600
I thought we had agreed on using the printer mode as subdirectory name?
You may have more printers with identical resolution.
E.g. TEXROOT/fonts/lj
TEXROOT/fonts/dj
TEXROOT/fonts/ljIV
TEXROOT/fonts/FAX
So a laserjet 10pt cmr10 pk-file will be TEXROOT/fonts/lj/cm/300dpi/cmr10.pk
We need this number of subdirectories. I don't if we should use `/lj/cm'
or `/cm/lj'. You could even argue that it should be `/lj/300dpi/cm' but
that will be hard or impossible to configure in emTeX.
> TEXROOT/fonts/t1faces/mathtime
> TEXROOT/fonts/t1faces/resident
`mathtime' is the _name_ of a (set of) font(s), whereas `resident' refers
to(?) a _class_ of fonts -- the fonts that are resident in your printer.
I don't think we want this distiction. Suppose I have two or three different
printers with different sets of resident fonts?
> TEXROOT/macros/dvips
Let's make it `TEXROOT/macros/ps', it need not be specific for dvips.exe
as people might think, though it _is_ for PostScript.
> TEXROOT/man
I suppose that is an abbreviation of `manual' (Unix style). Why not use
`TEXROOT/doc'. This directory may or may not contain true manual pages,
it certainly will contain non-man documentation.
Erik Frambach
================================================================================
Archive-Date: Mon, 17 Jan 1994 12:33:59 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 17 Jan 94 18:11:10 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401171811.AA14622@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: Late night thoughts
References: <MAILQUEUE-101.940117094320.416@eco.rug.nl>
Erik Frambach writes:
> Some remarks on the directory structure:
> > TEXROOT/bin
> We keep true TeX & MetaFont programs in TEXROOT. So I guess you mean that
> other programs, such as DVIDVI, WP2LaTeX, TGRIND, BM2font, GhostScript
> will reside in `bin'. OK, but let's define at least some subdirectories,
> e.g. for GhostScript and other large and more or less standard programs.
is there any point distinguishing binaries of eg pktopx from bm2font?
a more useful distinction would be to separate out a hackers directory
of binaries (like pktopx) which Joe Users never ever ever uses
> E.g. TEXROOT/fonts/lj
> TEXROOT/fonts/dj
> TEXROOT/fonts/ljIV
> TEXROOT/fonts/FAX
> So a laserjet 10pt cmr10 pk-file will be TEXROOT/fonts/lj/cm/300dpi/cmr10.pk
> We need this number of subdirectories. I don't if we should use `/lj/cm'
> or `/cm/lj'. You could even argue that it should be `/lj/300dpi/cm' but
> that will be hard or impossible to configure in emTeX.
can emtex be configured to use the mode name in its serach path? so
if 300, then mode = lj, so look in lj/
> > TEXROOT/man
> I suppose that is an abbreviation of `manual' (Unix style). Why not use
> `TEXROOT/doc'. This directory may or may not contain true manual pages,
> it certainly will contain non-man documentation.
>
i agree. anything that looks like unix is a turn off for some people.
`etc' and `man' are two examples!
sebastian
================================================================================
Archive-Date: Tue, 18 Jan 1994 05:10:27 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401181058.AA10122@rc6.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Tue, 18 Jan 1994 11:58:54 MET
To: TeX-CD@SHSU.edu
Subject: Re: Late night thoughts
[ Erik Frambach (Jan 17, 12:21):
> Some remarks on the directory structure:
> > TEXROOT/bin
> We keep true TeX & MetaFont programs in TEXROOT. So I guess you mean that
> other programs, such as DVIDVI, WP2LaTeX, TGRIND, BM2font, GhostScript
> will reside in `bin'. OK, but let's define at least some subdirectories,
> e.g. for GhostScript and other large and more or less standard programs.
> Updating wil become easier.
The decision by EM to put all these executables in TEXROOT is not what
other people do (did you ever try do do a `dir TEXROOT'?). For example
BORLANDC (\borlandc\bin), WATCOMC (\watcom\bin) and MatLab on UNIX all put
there binaries into one subdirectory. Just for convenience.
sr> is there any point distinguishing binaries of eg pktopx from bm2font?
sr> a more useful distinction would be to separate out a hackers directory
sr> of binaries (like pktopx) which Joe Users never ever ever uses
In my opinion all end-users programs should be in TEXROOT/bin. Tools that
are not directly used (like cs.exe in my MTPK package) should be put in its
own directory. MTPK uses:
TEXROOT/mtpk.bat (I would prefer TEXROOT/bin/mtpk.bat)
TEXROOT/mtpk/cs.exe
mtpk.pl
etc.
Regarding GhostScript, a tool that can be used outside TEX, I would prefer
to install it in its own directory.
>
> > TEXROOT/fonts/pk300
> > TEXROOT/fonts/pk600
> I thought we had agreed on using the printer mode as subdirectory name?
> You may have more printers with identical resolution.
> E.g. TEXROOT/fonts/lj
> TEXROOT/fonts/dj
> TEXROOT/fonts/ljIV
> TEXROOT/fonts/FAX
> So a laserjet 10pt cmr10 pk-file will be TEXROOT/fonts/lj/cm/300dpi/cmr10.pk
> We need this number of subdirectories. I don't if we should use `/lj/cm'
> or `/cm/lj'. You could even argue that it should be `/lj/300dpi/cm' but
> that will be hard or impossible to configure in emTeX.
I think most TeX versions can be installed to cope with that. Using the
modedef prevents clashes between 300 blackwriters and 300 white writers.
I agree that `modedef names' are better.
> > TEXROOT/fonts/t1faces/mathtime
> > TEXROOT/fonts/t1faces/resident
> `mathtime' is the _name_ of a (set of) font(s), whereas `resident' refers
> to(?) a _class_ of fonts -- the fonts that are resident in your printer.
> I don't think we want this distiction. Suppose I have two or three different
> printers with different sets of resident fonts?
That is indeed a problem. Normally resident fonts are not needed except
when you want to build PK fonts for your previewer. I think the only
neat method is the one used by ATM (MSDOS) or DPS (UNIX). What we need
is a library that contains a portable interface so that the
installation and lookup of PS resources is easy (one font per platform
and not per application). Dvips provides some hooks (psfonts.map) to cope
with different resident font sets on a printer basis. But this is only a
dvips solution. GhostScript has its own bag of tricks etc.
> Let's make it `TEXROOT/macros/ps', it need not be specific for dvips.exe
> as people might think, though it _is_ for PostScript.
OK.
> > TEXROOT/man
> I suppose that is an abbreviation of `manual' (Unix style). Why not use
> `TEXROOT/doc'. This directory may or may not contain true manual pages,
> it certainly will contain non-man documentation.
Another difficult point! There is no standard for online documentation. The
man was indeed the UNIX `manual'. How do we handle documenation? Is the
TeXinfo system portable to other platforms? I have seen some texinfo stuff
with EMX/gcc and DJGPP/gcc. UNIX still uses troff for online manuals
although some people prefer texinfo.
--Piet
================================================================================
Archive-Date: Tue, 18 Jan 1994 05:10:33 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 18 Jan 1994 12:05:38 +0100
From: nils@exp-math.uni-essen.de (Nils Rennebarth)
Message-ID: <9401181105.AA28091@hertha.exp-math.uni-essen.de>
To: TeX-CD@SHSU.edu
Subject: Re: Late night thoughts
Reply-To: TeX-CD@SHSU.edu, nils@exp-math.uni-essen.de
CC:
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
A group of people is putting together a TeX-package for the
Debian distribution of Linux. Now the discussion about different
path's for different classes of binaries conflicts with the
already at length discussed standards for the rest of the
distribution. To be precise:
- We already decided to put (this is a Unix system) binaries
in /usr/bin
That means: there won't even be binaries in TEXROOT/bin or whatever.
The reason was: One standard PATH should be enough for the average
user, and this one should be short, e.g. /bin:/usr/bin:/usr/local/bin
Maintaining changing PATH's or even telling users to put
/this/path/for/that/utility in their own PATH if they want a
certain functionality, is not manageable on bigger sites.
See the discussion of the FSSTND-channel of the Linux discussion
list.
The upshot of all this seems to be:
You may distribute the CD with binaries in different directories,
but there must be an installation script that puts them in the
place expected by the existing system.
And even on MSDOS I hate seeing mammouth PATH's with entry for
every utility you own. Upgrading binaries often isn't such a
problem, cause most of the time you just replace the old one by
a new one with the same name (There are exceptions, of course).
Please consider this when putting together a TeX-CD
Nils
================================================================================
Archive-Date: Tue, 18 Jan 1994 07:12:27 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 18 Jan 1994 09:08:46 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Subject: Re: directory structure
To: TeX-CD@SHSU.edu
Reply-To: TeX-CD@SHSU.edu, TeX-CD@SHSU.edu
Message-ID: <MAILQUEUE-101.940118090846.384@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
> > > TEXROOT/bin
> > We keep true TeX & MetaFont programs in TEXROOT. So I guess you mean that
> > other programs, such as DVIDVI, WP2LaTeX, TGRIND, BM2font, GhostScript
> > will reside in `bin'. OK, but let's define at least some subdirectories,
> > e.g. for GhostScript and other large and more or less standard programs.
> is there any point distinguishing binaries of eg pktopx from bm2font?
> a more useful distinction would be to separate out a hackers directory
> of binaries (like pktopx) which Joe Users never ever ever uses
My idea was to separate large packages to make updating easier. Some other
programs consist of only one or two files. It's hard to keep track of what
files belong to what package.
My name used to be Joe User but I had to change it into Joe Superuser.
Deciding which programs are for hackers only will not be easy either.
> can emtex be configured to use the mode name in its serach path? so
> if 300, then mode = lj, so look in lj/
Yes, it can (non-emTeXers: skip the rest):
set MODE=lj
set TEXROOT=t:\fonts
set DVIDRVFONTS=%TEXROOT%\%MODE%
dviscr /fm=%MODE% /pf={$DVIDRVFONTS:@Rrdpi\,}@f.{pk,pxl} ...
Now dviscr will use the first one it finds in this list:
T:\FONTS\LJ\300DPI\fontname.pk
T:\FONTS\LJ\300DPI\fontname.pxl
.\300DPI\fontname.pk
.\300DPI\fontname.pxl
The /fm parameter enables automatic font generation. This technique is
implemented in 4TeX, so I know it really works. It also works with DVIPS
though the environment settings are different of course.
Erik Frambach
================================================================================
Archive-Date: Tue, 18 Jan 1994 10:07:24 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401181605.AA29211@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Tue, 18 Jan 1994 17:05:15 MET
To: TeX-CD@SHSU.edu, nils@exp-math.uni-essen.de
Subject: Re: Late night thoughts
[ Nils Rennebarth (Jan 18, 12:41):
> A group of people is putting together a TeX-package for the
> Debian distribution of Linux. Now the discussion about different
> path's for different classes of binaries conflicts with the
> already at length discussed standards for the rest of the
> distribution. To be precise:
> - We already decided to put (this is a Unix system) binaries
> in /usr/bin
> That means: there won't even be binaries in TEXROOT/bin or whatever.
>
> The reason was: One standard PATH should be enough for the average
> user, and this one should be short, e.g. /bin:/usr/bin:/usr/local/bin
> Maintaining changing PATH's or even telling users to put
> /this/path/for/that/utility in their own PATH if they want a
> certain functionality, is not manageable on bigger sites.
> See the discussion of the FSSTND-channel of the Linux discussion
> list.
I agree with `One standard PATH should be enough for the average user'. I
disagree with:
- /usr/bin (keep things separate from standard UNIX, for example
/usr/local/bin!)
- I still prefer TEXROOT/bin. But to prevent that end-users need to add
yet another path element to their PATH I make links for each
TEXROOT/bin/executable to one in /usr/local/bin. For this purpose I
wrote two scripts LINK/UNLINK that can automatically make these
symbolic links. But we have to realise that not all computers do have
symbolic links. (See my versions of LINK/UNLINK at the end).
- Having all related TeX executables in one directory allows users to
work with a new test version if they add this NEWTEXROOT/bin to
their PATH. And if you decide to make that version official the
updating/replacing is very simply. With programs scattered around
this is a very tiresome and painfull exercise.
- what we in fact need is a good package management system. Because TeX
consists of so many tools it would certainly be a good test case. As
long as we don't have such a system we will have to work with `some
workaround' solutions. Putting executables in a TEXROOT/bin directory
is such a simple minded workaround which I prefer above having a lot of
scattered programs in /usr/local/bin (or even worse in /usr/bin).
> Nils
]
--Piet
NB.: Next scripts still experimental!!!
------------------ linkkit.shar ----------------------
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: LINK UNLINK
# Wrapped by rcpt@wsinfo06 on Tue Jan 18 16:58:52 1994
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f LINK -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"LINK\"
else
echo shar: Extracting \"LINK\" \(1576 characters\)
sed "s/^X//" >LINK <<'END_OF_LINK'
X#!/bin/sh
X# File: LINK (don't make it executable, run it with `sh LINK')
X# Purpose:
X# Create for each program a link in /usr/local/bin
X# - This allows us to have all TeX-executables and manual pages
X# together
X# - the UNLINK script removes all these links
X# Author: Piet Tutelaers (rcpt@urc.tue.nl)
X# Version: Aug. 1993
X
X# The directory which is hardwired into (some) TeX binaries
XTEXROOT=/usr/local/lib/tex-3.141; export TEXROOT
X
XBIN=/usr/local/bin
XTEXBIN=${TEXROOT}/bin
Xexport BIN TEXBIN
X
XLN="ln -s"
X#RUN= # choose this if you WANT to execute the script!
XRUN=echo # choose this if you DON'T WANT to execute the script!
X
Xcd ${TEXBIN}
Xfor PROG in *
Xdo
X if test -x ${BIN}/${PROG}
X then echo ${PROG} already exists!
X else
X if test -x ${PROG}
X then
X $RUN $LN ${TEXBIN}/${PROG} ${BIN}/${PROG}
X else
X echo "${PROG}: no executable (skipped)"
X fi
X fi
Xdone
X
XMAN=/usr/local/man
XTEXMAN=${TEXROOT}/man
Xexport MAN TEXMAN
X
X# Create for each existing manual page a link in /usr/local/man
X# - This allows us to have all TeX-manuals together
X# - the de-link script removes all these links
X
Xcd ${TEXMAN}
Xfor MANDIR in man?
Xdo
X if test ! -d ${MAN}/${MANDIR}
X then echo ${MAN}/${MANDIR} does not exist!
X exit 1
X else
X for MANUAL in ${MANDIR}/*
X do
X if test -r ${MAN}/${MANUAL}
X then echo ${MAN}/${MANUAL} does already exists!
X else $RUN $LN ${TEXMAN}/${MANUAL} ${MAN}/${MANUAL}
X fi
X done
X fi
Xdone
X
Xecho Now run makewhatis to update whatis database
END_OF_LINK
if test 1576 -ne `wc -c <LINK`; then
echo shar: \"LINK\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f UNLINK -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"UNLINK\"
else
echo shar: Extracting \"UNLINK\" \(1325 characters\)
sed "s/^X//" >UNLINK <<'END_OF_UNLINK'
X#!/bin/sh
X# File: LINK (don't make it executable, run it with `sh UNLINK')
X# Purpose:
X# Remove all links in /usr/local/bin that points to a corresponding
X# program in $TEXROOT/bin.
X# Remove all links in /usr/local/man/man? that points to corresponding
X# manual pages in $TEXROOT/man.
X# The LINK script build the links.
X# Author: Piet Tutelaers (rcpt@urc.tue.nl)
X# Version: Aug. 1993
X
X# The directory which is hardwired into (some) TeX binaries
XTEXROOT=/usr/local/lib/tex-3.141; export TEXROOT
X
XBIN=/usr/local/bin
XTEXBIN=${TEXROOT}/bin
Xexport BIN TEXBIN
X
XRM=rm
X#RUN= # choose this if you WANT to execute the script!
XRUN=echo # choose this if you DON'T WANT to execute the script!
X
Xfor P in `find $BIN \( -type l -a ! -type d \) -print`
Xdo
X PROG=`basename $P`
X if test -x ${TEXBIN}/${PROG}
X then
X $RUN $RM ${BIN}/${PROG}
X else
X echo "Link for ${PROG} not removed (skipped)"
X fi
Xdone
X
XMAN=/usr/local/man
XTEXMAN=${TEXROOT}/man
Xexport MAN TEXMAN
X
X# And now the manual pages
X
Xfor M in `find $MAN \( -type l -a ! -type d \) -print`
Xdo
X MANUAL=`expr "$M" : "^.*\(man[1-8]\/.*\)"`
X if test -f ${TEXMAN/${MANUAL}
X then
X $RUN $RM ${MAN}/${MANUAL}
X else
X echo "Link for ${MANUAL} not removed (skipped)"
X fi
Xdone
X
Xecho Now run makewhatis to update whatis database
END_OF_UNLINK
if test 1325 -ne `wc -c <UNLINK`; then
echo shar: \"UNLINK\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of shell archive.
exit 0
================================================================================
Archive-Date: Tue, 18 Jan 1994 12:40:50 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 18 Jan 1994 12:39:13 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: tex-cd@SHSU.edu
Message-ID: <00978B87.7DDB9F20.19189@SHSU.edu>
Subject: Directory paths/logicals/environment variables
On Tue, 18 Jan 1994 12:05:38 +0100, nils@exp-math.uni-essen.de (Nils
Rennebarth) posted:
> A group of people is putting together a TeX-package for the Debian
> distribution of Linux. Now the discussion about different path's for
> different classes of binaries conflicts with the already at length
> discussed standards for the rest of the distribution. To be precise:
>
> - We already decided to put (this is a Unix system) binaries
> in /usr/bin
> That means: there won't even be binaries in TEXROOT/bin or whatever.
>
> The reason was: One standard PATH should be enough for the average user,
> and this one should be short, e.g. /bin:/usr/bin:/usr/local/bin Maintaining
> changing PATH's or even telling users to put /this/path/for/that/utility in
> their own PATH if they want a certain functionality, is not manageable on
> bigger sites. See the discussion of the FSSTND-channel of the Linux
> discussion list.
>
> The upshot of all this seems to be:
> You may distribute the CD with binaries in different directories, but there
> must be an installation script that puts them in the place expected by the
> existing system.
>
> And even on MSDOS I hate seeing mammouth PATH's with entry for every
> utility you own. Upgrading binaries often isn't such a problem, cause most
> of the time you just replace the old one by a new one with the same name
> (There are exceptions, of course).
>
> Please consider this when putting together a TeX-CD
Or, ..... this may be a case where how we handle quite a few of these
related issues on VMS may be insightful. Whether or not this can be
implemented elsewhere, I can't say (and I truly hope those of you on other
platforms can tell me if this can or cannot be done on other systems).
The path name which has been proposed as a global solution has been along
the lines of TEXROOT/whatever/and/subdirectories where TEXROOT is defined
as something meaningful w.r.t. a physical directory specification which is
possibly searchpathable. Why not point everything into logically
meaningful environment specifications for each specific operating system?
Especially if an intended-to-be-installed-from CD instead of a
run-it-directly-from CD distribution is to be made, the installation script
(and subsequent startup things to define locally) allow us to create
system-specific installations from an exceedingly generic CD file structure
which could even use CD directory names such as 1,2,3,...
>From P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers) message of Thu, 13 Jan
1994 00:17:31 MET which started this thread:
> The TEXROOT should be movable.
> Sometimes we grow out of our disk space. Then we may have to move TeX
> to another disk. But most TeX programs use hard wired paths. Some
> UNIX systems allow to have system wide environment variables (similar
> to VAX-VMS). If all file references would be made via the TEXROOT
> environment variable changing from disk would be merely a question
> of redefining this TEXROOT. (On EmTeX Eberhard Mattes already has defined
> EMTEXDIR with a similar meaning!)
There are hard wired paths in more TeX-related programs currently than I
care to think about. What I am proposing is that some well-specified set
of expected-on-every-platform logicals (or environment variables or
whatever your OS calls them) be defined such that hard wires are even less
desirable than now.
> On the longer term we can try to
> convince people to use one standard TeX structure. Aren't we too late?
My guess is that those programs which are popular and commonly used can be
altered to meet standard requirements if they indeed provide a consistent
and well-specified setup. Note also that, if followed, the ``just how hard
wired is this?'' dimension of porting to other platforms is eliminated.
Are we too late? If it is possible to improve upon what already exists, I
would certainly hope not or we're talking about a dying product (which I
hope TeX is not). If we are facing a bunch of developers who are resistant
to change because it's not the way they do things in their personal
environment or on their personal OS and they are too hard headed to see the
advantages of the change, it's clear that the developers aren't developing
a very dynamic program in the sense of portability which underlies the
entire Knuthian concept of TeX.
Also from Piet's post:
> Why all TeX related material in one TEXROOT?
> - to avoid that we have to digg around in order to find our complete TeX
> collection
> - allows to have two diffent versions at the same time.
Using different VMS logicals here for TEX_EXE and TEX_INPUTS, both on
different devices from one another, I can easily reduce searching for
specific components at any one time which makes component management much
easier. I can find my entire TeX collection by including all TeX-related
directories into a single logical if I need to; I trust that it would work
elsewhere (so long as a logical will accept and translate another logical
it should anyway). I can also have any number of versions available at any
time by simply changing the logical to point where I want it to.
So,.... instead of this TEXROOT/.../ approach, why not use a family of
logically defined directory path specifications (which can each hopefully
be traversed as searchpaths)? I know that I'm adequately technically
ignorant to be capable of defining all possible logicals which might be
necessary, but from a quick and dirty perusal of our out-of-date TeX
installation on the machine I happen to be on right now, it would appear
that we could define:
TEXEXE -- executable binaries (possiby TEXBIN is a better name?)
TEXFMT -- formats
TEXFONTS -- fonts
TEXHELP -- documentation, help, `man' pages, etc.
TEXMACRO -- macros intended for \input (possibly TEXINPUT is a
better name?)
This might or might not be the minimal set of logicals -- I'm not looking
for flames since I don't make any claims to knowledge of how to efficiently
split everything which TeX can possibly handle, although comment and
criticism are welcomed.
This way users, system managers, and program developers place their files
wherever they want on their own system so long as the logical TEXEXE has
meaning for an environment on their machine. One very real benefit if this
can be done is that it it meets and exceeds the concern:
> The TEXROOT should be movable.
> Sometimes we grow out of our disk space. Then we may have to move TeX
since TEXEXE can properly coexist with TEXFMT even if they are on different
physical devices/drives. SHSU would be up stink creek if it weren't for
this since our policy is that all system-wide executable binaries exist
within a given directory hierarchy on a given physical device and there is
inadequate room on that drive to support fonts, styles, etc., on it. This
policy isn't going to change any time soon and I darned well would think
more than twice if I were asked to propose changing it because some program
was adequately mis-written and apparently brain dead to make me have to
even think about where I physically have to place files. In other words,
we can grow out of our disk space, but not necessarily have to move off of
the existing disk so much as adding another disk. Is this in conflict with
my earlier statement about change, dying products, and hard headedness?
No. Our policy is explicitly limited to one and only one *physical*
device for one and only one class of files which can (and do!) have many
system-wide or user-specified logical meanings.
For example, in the generic case I proposed above, use TEXEXE (or TEXBIN or
whatever) for everyone and allow (more precisely, require) that to be
locally defined so that instead of TEXROOT/bin being where the TeX et al.
binaries exist, they instead exist in whatever I define TEXEXE to be.
Hence, Unix users can put their binaries in /usr/bin/, /bin/,
/usr/local/bin/, /myowndevice/lord-knows-how-I-decided-on-this-spec/, or
any (searchpath) combination of them, while VMS users can use
SYS1:[TEX.EXE] or SYS$COMMON:[SYSEXE] or any (searchpath) combination of
them, while MS-DOS users can use C:\TEX\BINARY\ or S:\MYEXE\ or any
(searchpath) combination of them.
Also, if TEXMACRO were defined within a hierarchy unique from, say, TEXEXE,
and searchpathing allowed, it reduces some (but admittedly not all) of Paul
Taylor's "ticking" concern as the scope of the searchpath becomes a
function of wat kind of file one is looking for. However, I have to admit
that all hell would break loose if logicals indirectly pointing to
themselves were introduced, but that is an installation-specific concern
which a little forethought in how things are defined come into play -- a
no-brainer will cause havoc anywhere.
Sorry for the rambling; I sincerely tried to get down to the basics and may
have missed the boat altogether.
Regards, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
Archive-Date: Tue, 18 Jan 1994 15:13:24 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 18 Jan 1994 15:10:38 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: tex-cd@SHSU.edu
Message-ID: <00978B9C.A54C2920.20203@SHSU.edu>
Subject: RE: Directory paths/logicals/environment variables (fwd)
I don't know if this was indeed intended as a completely private reply or
not (it came in as one, but the information is just tooooooooo good not to
pass it along; apologies in advance to bnb if this was not intended for
public consumption).
--George
***************************************************************************
Date: 18 Jan 1994 15:47:40 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Subject: Re: Directory paths/logicals/environment variables
In-reply-to: <00978B87.7DDB9F20.19189@SHSU.edu>
To: bed_gdg@SHSU.EDU
Message-ID: <758926060.912656.BNB@MATH.AMS.ORG>
regarding logical names, the following are already defined in
tex.web:
TeXinputs: "Input files that can't be found in the user's area
may appear in a standard system area called TEX_area."
TeXfonts: "Font metric files whose areas are not given explicitly
are assumed to appear in a standard system area called
TEX_font_area. These system area names will, of course,
vary from place to place."
TeXformats: "We shall use the global variable TEX_format_default to
supply the text for default system areas and extensions
related to format files." (pool files also go here)
it seems silly to me to not take advantage of this existing structure,
shortening the names as necessary because of system limitations.
"help" (or "doc") and "exe" (or "bin") are reasonable additions.
-- bb
================================================================================
Archive-Date: Tue, 18 Jan 1994 16:04:04 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 18 Jan 94 21:53:58 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401182153.AA27774@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: RE: Directory paths/logicals/environment variables (fwd)
References: <00978B9C.A54C2920.20203@SHSU.edu>
"George D. Greenwade" writes:
> regarding logical names, the following are already defined in
> tex.web:
> TeXinputs: "Input files that can't be found in the user's area
> may appear in a standard system area called TEX_area."
> TeXfonts: "Font metric files whose areas are not given explicitly
> are assumed to appear in a standard system area called
> TEX_font_area. These system area names will, of course,
> vary from place to place."
> TeXformats: "We shall use the global variable TEX_format_default to
> supply the text for default system areas and extensions
> related to format files." (pool files also go here)
>
> it seems silly to me to not take advantage of this existing structure,
sorry, but here i think we should *not* follow Knuth. it may have been
appropriate for when he put out TeX, but now I think we start with a
clean sheet and do whats best for the 1990s....
sebastian
================================================================================
Archive-Date: Wed, 19 Jan 1994 05:28:27 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 19 Jan 1994 06:27:41 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU
Message-ID: <199401191127.AA11824@terminus.cs.umb.edu>
To: P.T.H.Tutelaers@urc.tue.nl, TeX-CD@SHSU.edu
Subject: Re: Late night thoughts
I vote *against* having a directory `ps' instead of `dvips'.
People might want more than one dvi-to-postscript translator installed.
I also vote *against* calling a directory with man pages in it `doc'.
(On Unix systems.) I think it is preferable to follow established
conventions, even when they are arguably wrong, and vary among systems,
than to impose your own conventions.
So this message isn't wholly negative: I think George's suggestion
of different paths for everything is the right one. Isn't that
what implementations do now?
================================================================================
Archive-Date: Wed, 19 Jan 1994 08:21:58 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 19 Jan 1994 13:12:53 MET+1
From: Erik Frambach <FRAMBACH@eco.rug.nl>
Subject: Re: Late night thoughts
To: TeX-CD@SHSU.edu
Reply-To: TeX-CD@SHSU.edu, E.H.M.Frambach@eco.rug.nl
Message-ID: <MAILQUEUE-101.940119131253.288@eco.rug.nl>
Content-Transfer-Encoding: 7BIT
> I vote *against* having a directory `ps' instead of `dvips'.
> People might want more than one dvi-to-postscript translator installed.
This directory contains MACROS for using PostScript in TeX, e.g. a
style file called TIMES.STY and PSTRICKS.STY.
If I have more dvi-to-ps translators I would not like to have copies of
these styles in each directory. I don't see any problem in having macros
for all dvi-to-ps translators in one directory. Identical file names
perhaps? They are already forbidden.
> I also vote *against* calling a directory with man pages in it `doc'.
> (On Unix systems.) I think it is preferable to follow established
> conventions, even when they are arguably wrong, and vary among systems,
> than to impose your own conventions.
Right now we are deciding on the names of directories _on_the_CD_, not your
local disks. The CD will run on any platform; the installation script
may do some platform specific naming of files and directories when it
installs things on your local disks.
> So this message isn't wholly negative: I think George's suggestion
> of different paths for everything is the right one. Isn't that
> what implementations do now?
Some do, some don't, some can't.
Erik Frambach
================================================================================
Archive-Date: Wed, 19 Jan 1994 08:56:49 CST
Sender: CTAN-Mgr@SHSU.edu
From: Paul Taylor <pt@doc.ic.ac.uk>
Reply-To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Date: Wed, 19 Jan 1994 14:56:08 +0000
To: tex-cd@SHSU.edu
Subject: an off the shelf TeX package
Message-ID: <"swan.doc.i.575:19.00.94.14.56.13"@doc.ic.ac.uk>
There are four things which (presumably) it is the business of this
list to consider:
(1) provision of virtex and other program binaries in easy to use
form for a variety of operating systems and architectures,
(2) a basic library of macros, fonts etc
(3) the organisation of a comprehensive TeX CR-ROM
(4) the organisation of the international TeX archive.
It seems to me that those who have made specific suggestions about the
organisation of things have confused (2) and (3). I consider that they are
quite separate, and that there is a proprity for designing and providing
a public domain off the shelf TeX implementation.
That is, something that people can get from the archive (or a CD) in the form
of a .tar.Z or comparable compressed directory image, plug in and use.
First let me comment on (3) and (4). I consider that any argument which
applies to one applies equally to the other, since in practice the access
times and capacities are the same. There is already enough confusion
around in the TeX world without creating an arbitrary difference between
the directory structure of the archive and that of a CD.
The two should be the same.
Let's agree on a way of organising the ftp archive, and let the CD be
a snapshot of that.
We had a discussion about directory searching by subroutines of the virtex
and other programs versus installation scripts. I've already argued for
the latter and got some support, but let me point out something else which
actually applies more or less equally to both. If the subroutine or script
picks up the file "article.sty", say, from whatever directory happens to
contain it then
we might just as well not have had a directory structure
in the first place. Consider the analogy of FORTRAN subroutine names
or BITNET site names. Very sensibly the InterNet has a hierarchical
structure, with the result that you can call your machine or yourself
whatever you like. That is, until some Little Hitler in a university
computing service dictates that usernames must be compatible across
campus, and we're back to square one. I suppose this is an argument for
including directory names (within the ftp or cd archive) as part of the
names of packages when input by TeX.
I have to confess that I haven't yet implemented a general installation
script for TeX macros, but I have done it for fonts. My version of
MakeTeXPK searches (a listing of) the archive for the directores in
which the metafont source lies and adds them to MFINPUTS before calling
metafont. So for example if MakeTeXPK is asked for kdgr8.432pk it
seraches for *kdgr*.mf and adds the directory in which this is found,
tex-archive/fonts/greek/kd/mf, to the path so that metafont will later
pick up the accent, digit, upper and lower files. Kostis has appended
is initials to all of these filenames now, but this method would have
ensured that his Greek upper.mf rather than Knuth's Latin version
was used. I don't know how you could do this with TeX macro files,
because it's not possible to predict before virtex starts which
directories will be needed.
Turning to point (2), I have a concrete proposal for the design of
an off the shelf package. For the past three years I have been
maintaining such a package, which has been used by a couple of hundred
machines around Imperial College as well as by colleagues elsewhere
and myself when I've been on academic visits. We observed that most of
the files in the PK directory were NEVER USED and deleted them. Other
files have been added to the collection by monitoring usage of a central
archive which appears on the search paths after the local package.
We have added other programs and libraries as seemed appropriate,
including the systems language perl because no two machines seem to
have the same shell program.
Building of this package is partially automated. In particular the list
of files is maintained in /tex/local-copy/pedigree. The package itself
is available in the directory /tex/local-copy at theory.doc.ic.ac.uk.
It hasn't been updated for LaTeX2e yet.
I do encourage you to look at (the design of) my package, because I think
such a thing should be provided "officially" in the ftp archive and on
the CD. I have wasted too much of my life fighting complex installation
scripts such as those for web2c and LaTeX2e, and trying to work out from
the archive which is the up to date version of epsf.sty and everything
else for local installation - I think there should be a TeX implementation
which people can "plug in and type go".
Paul
================================================================================
Archive-Date: Wed, 19 Jan 1994 10:03:20 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Wed, 19 Jan 1994 10:01:43 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, E.H.M.Frambach@eco.rug.nl
Message-ID: <00978C3A.A7E1E460.25127@SHSU.edu>
Subject: Re: Late night thoughts
On Wed, 19 Jan 1994 13:12:53 MET+1, Erik Frambach <FRAMBACH@eco.rug.nl>
posted:
> > So this message isn't wholly negative: I think George's suggestion
> > of different paths for everything is the right one. Isn't that
> > what implementations do now?
> Some do, some don't, some can't.
Which ones can't? The do's we can retrofit if another approach differs
from the present one; the don't's we can design so that when installed,
they become do's. The can't's possibly can't be touched or may provide
some insightful guidelines on how to design the approach for those that
will.
On another topic, Sebastian's point about starting with a clean slate is
well taken since we really are starting from scratch. If we take the
position that we are indeed starting as if this were a new product and take
that approach in lieu of taking the stance that we are constrained by some
(possibly bad) past decision(s), I think we can design a better product.
My concern here, though, is if we can use an already established standard
(which just happens to be Knuthian) and it wasn't a bad past decision but
can be further extended to provide the functionality that we are seeking,
we may be better off and better accepted. In short, whatever standard is
developed needs to work, needs to work right, needs to be functionally
portable insofar as present technologies allow, and needs to be designed to
be accepted not because it's different but because of all the other "needs
to be's" above. If our collective experience with TeX provides insights as
to the limitations of the Knuthian approach and we have (or can) figure out
a better way of doing things, then by all means we need to supercede Knuth.
Note that the standard against which I judge is "Knuthian" and explicitly
not "Unixian", "DOSian", nor "VMSian". I don't give a rat's arse about how
someone tweaked something to run on a platform nor that platform's unique
attributes which someone feels should be ported to other platforms.
Instead, I think that the concern should be how a given family of programs
(TeX, et al.) can be packaged to work consistently across a variety of
unique platforms. A serious mistake is made whenever the installation of
one program requires another program, which relies on yet another program
and those programs really have very little to do with one another (my
unabashed view of the Unix approach, which is virtually required on that
platform) -- a mistake large enough to shy users away from even trying the
product since just its installation is a pain in the rear. Our trick is to
design it so it is a single package, similar to Mattes' emTeX creation, but
installable everywhere.
--George
================================================================================
Archive-Date: Wed, 19 Jan 1994 12:56:23 CST
Sender: CTAN-Mgr@SHSU.edu
Date: 19 Jan 1994 13:51:18 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TeX-CD@SHSU.edu, BNB@MATH.AMS.ORG
Subject: Re: Late night thoughts
To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
Message-ID: <759005478.218657.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
the point i was trying to make when i sent george the message
containing the excerpts from tex.web, and he forwarded to this
list, was that there is already in tex a (minimum) differentiation
between types of files that are expected to be read in, and these
can be segregated into different areas. at a local level, of
course, one can always choose to lump all .tfm, .fmt, .sty and
pool files into one area, and direct all the logicals to that
same area, but i don't think that's a smart move for an archive,
whether on disk or cd-rom. in fact, i prefer a much more
highly differentiated structure, with search lists defined to
tailor the different areas for different uses.
i clearly didn't explain very well what i meant, so i'll try
again. i consider the three areas defined in tex.web (TeXfonts,
TeXformats, TeXinputs) to be a minimum for structuring, and i
hope nobody is tempted to use a flatter structure.
-- bb
================================================================================
Archive-Date: Sat, 22 Jan 1994 15:35:06 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401222134.AA11221@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Sat, 22 Jan 1994 22:34:03 MET
To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Subject: Re: an off the shelf TeX package
[ Paul Taylor (Jan 19, 16:04):
> Turning to point (2), I have a concrete proposal for the design of
> an off the shelf package. For the past three years I have been
> maintaining such a package, which has been used by a couple of hundred
> machines around Imperial College as well as by colleagues elsewhere
> and myself when I've been on academic visits. We observed that most of
> the files in the PK directory were NEVER USED and deleted them. Other
> files have been added to the collection by monitoring usage of a central
> archive which appears on the search paths after the local package.
> We have added other programs and libraries as seemed appropriate,
> including the systems language perl because no two machines seem to
> have the same shell program.
>
> Building of this package is partially automated. In particular the list
> of files is maintained in /tex/local-copy/pedigree. The package itself
> is available in the directory /tex/local-copy at theory.doc.ic.ac.uk.
> It hasn't been updated for LaTeX2e yet.
>
> I do encourage you to look at (the design of) my package, because I think
> such a thing should be provided "officially" in the ftp archive and on
> the CD. I have wasted too much of my life fighting complex installation
> scripts such as those for web2c and LaTeX2e, and trying to work out from
> the archive which is the up to date version of epsf.sty and everything
> else for local installation - I think there should be a TeX implementation
> which people can "plug in and type go".
>
> Paul
]
I have looked at your `design'. But I must confess that I don't
understand what you have automated and how a CTAN archive can
"officially" provide it for other users.
What I understand:
a) you advocate to provide binaries instead of sources
b) you advocate to provide scripts that install formats given initex/virtex,
format macros, hyphenation patterns, etc
c) you suggest to use perl as the platform independant programming shell
d) end-users should not need to use any environment variable.
But what I do not understand:
e) how do you distuingish between workstation/fileserver stuff in a system
independant way?
Each environment has its typical problems. Your environment consists of
many UNIX boxes of different flavour probably connected to several
fileservers. I maintain TeX on many SUN workstations connected to
several different fileservers. At the moment I maintain TeX on one
fileserver. We manually update all other fileservers on a regular
basis. We are studying how we can mirror the TeX stuff to other
fileservers with `rdist' (a Berkeley tool for remote distribution).
--Piet
================================================================================
Archive-Date: Sun, 23 Jan 1994 07:05:47 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401231304.AA15362@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Sun, 23 Jan 1994 14:04:31 MET
To: TeX-CD@SHSU.edu
Subject: TEXROOT *and* other TEXenvironments
In my attempt to define a standard platform independant TeX structure
I have used TEXROOT to represent the directory that contains it.
At this moment I only know three TeX implementations that use such
a flexible environment variable (or logical disk) to dynamically
determine the base of its tree. The new beta9 version of emTeX uses
EMTEXDIR, DECUS TeX for VAX-VMS uses TEX_ROOT ('appl:[tex.]' on
our computer) and AmigaDOS (commercial version of Tom Rokicki) uses
the logical disk `TEX:'.
The EMTEXDIR option of emTeX can be used in defining other environments if
used in batch files (not on the command line):
set EMTEXDIR=c:\emtex
set TEXINPUT=%EMTEXDIR%\macros
With EMTEXDIR emTeX users can easily move their TeX tree from the
c: drive to the d: drive. On UNIX we have to recompile all programs
unless we are willing to use `symbolic links'. Suppose you have
installed TeX in /usr/local/lib/tex and want to move it to /usr/tex.
Then you have to make /usr/local/lib/tex a symbolic link to /usr/tex.
Otherwise programs looking for the hardwired /usr/local/lib/tex/mystuff
can't find `mystuff'.
It would be nice if all future TeX implementations use TEXROOT as
the standard environment for the root of the TeX tree. Perhaps this
TEXROOT should even be implemented as a search path allowing things like:
setenv TEXROOT ~/tex:
with the meaning ``look first in the user's ~/tex directory and if
you don't find it there look in the system's default directories''.
This would allow users on multi-user platforms to have their private
fonts, macros, configuration files, etc. On MSDOS systems NOVELL
users could say:
set TEXROOT=c:\tex;
with a similar meaning. We have had some discussion already how
we can standarize the directory names within this TEXTREE. And what
directory search heuristics are needed/wanted.
Most implementations use environments to locate TeX stuff. To
provide end-users the opportunity to use different versions. With
a searchable TEXROOT path all these different environment names can
be replaced by one. But then end-users need to use the same
directory names within their private ~/tex directory. But perhaps
we need to keep a *minimal* set of environments for:
TEXMACROS (macros for all TeX derivates)
TEXFORMATS (a natural place for formats/base/pool files)
TEXFONTS (tfm files)
TEXPKS (pk fonts)
They can be implemented in such a way that they default to the
standard directories from the TEXROOT (so TEXFONTS defaults to
`~/tex/fonts/tfm:' on UNIX, or `c:\tex\fonts\tfm;' on MSDOS) but
can be overruled when a user wish whatever directories he
likes to work with.
I think the only way we can provide a standard TeX structure across
different OS'es is by implementing one that runs on all these
platforms and will be accepted as the defacto TeX standard. In my
perl version of MTPK I implemented a `plug-in mtpk module' to
simplify the integration of MTPK into existing DVI drivers (prerelease
is available on ftp.urc.tue.nl:pub/tex/mtpk????.zip). We have to
do the same for the standard CTAN structure. And this can only
succeed if implementors on powerfull systems (UNIX, VMX) are willing
to use portable TeXniques so that the less powerfull systems can
follow. Are we willing to do that? (Karl please give your opinion.)
I think TEXROOT is a valuable environment variable if we are going
to distribute platform dependant binaries. Together with Paul Taylor
I think we have to do that for all UNIX platforms (provided there
is somebody who wants to share his executables with others).
-Piet
================================================================================
Archive-Date: Sun, 23 Jan 1994 13:36:13 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Sun, 23 Jan 94 14:33:32 EST
From: karl@owl.HQ.ileaf.com (Karl Berry)
Message-ID: <9401231933.AA19466@owl.HQ.Ileaf.COM>
To: tex-cd@shsu.edu
Subject: TEXROOT
Reply-To: TeX-CD@SHSU.edu, karl@cs.umb.edu
In my attempt to define a standard platform independant TeX structure
I have used TEXROOT to represent the directory that contains it.
[...]
follow. Are we willing to do that? (Karl please give your opinion.)
Yes, I am willing.
Implementing TEXROOT (and runtime configuration files) for web2c (i.e.,
kpathsea) is the next TeX project on my list, and has been for months.
Making TEXROOT a path, instead of just a directory, I'm not sure about.
I'm inclined to think that a user's config file and/or environment
variables, together with :: expanding into the system directories, is
enough to allow clean specifications.
I slightly prefer the name `TEXMFROOT', but I won't put up a fuss about it.
================================================================================
Archive-Date: Sun, 23 Jan 1994 17:03:27 CST
Sender: CTAN-Mgr@SHSU.edu
From: Paul Taylor <pt@doc.ic.ac.uk>
Reply-To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Date: Sun, 23 Jan 1994 23:01:22 +0000
To: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers), TeX-CD@SHSU.edu
Subject: Re: an off the shelf TeX package
Message-ID: <"swan.doc.i.566:23.00.94.23.01.28"@doc.ic.ac.uk>
A brief answer because I'm typing this from home over a modem
and we have to pay for local calls in Britain.
> a) you advocate to provide binaries instead of sources
Not instead, as well as. I believe a sun4 binary for emacs is provided
as well as the sources and makefiles.
b) you advocate to provide scripts that install formats given initex/virtex,
format macros, hyphenation patterns, etc
No, we were discussing how to find metafont and tex macro files from
the archive. I advocate providing a script which would fetch these
on demand and put them in a cache structure.
> I have looked at your `design'. But I must confess that I don't
understand what you have automated and how a CTAN archive can
> "officially" provide it for other users.
I have put together a package of macros, fonts and various other things
that seem appropriate for a complete text processing system.
The origins of these are documented in a file (/tex/local-copy/pedigree)
which is part of a script for rebuilding this package. It isn't yet
converted to LaTeX2e and contains some non-standard stuff which would
have to be reconsidered. The rebuilding takes things directly from the
archive and therefore guarantees that things are up to date. What I
propose is that such a package be built (periodically and automatically)
on the archive itself and provided in .tar.Z and other archive formats.
The directory structure is a flat one, as I prefer.
I don't understand your last question:
e) how do you distuingish between workstation/fileserver stuff in a system
independant way?
Paul
================================================================================
Archive-Date: Sun, 23 Jan 1994 17:06:05 CST
Sender: CTAN-Mgr@SHSU.edu
From: Paul Taylor <pt@doc.ic.ac.uk>
Reply-To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Date: Sun, 23 Jan 1994 23:05:21 +0000
To: TeX-CD@SHSU.edu
Subject: TEXROOT
Message-ID: <"swan.doc.i.829:23.00.94.23.05.27"@doc.ic.ac.uk>
I support the suggestion that an environment variable TEXROOT
be provided by virtex, dvips and other programs in addition
to the other more specific ones. I suggest that some syntax
such as a leading + in the path components of TEXINPUTS etc
be expanded to the value of TEXROOT.
This would enable users without root access to install TeX and
its libraries in their own directories with the minimum of change.
(I did suggest this to Karl Berry once before.)
Paul
================================================================================
Archive-Date: Mon, 24 Jan 1994 05:15:14 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 1994 06:14:59 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU
Message-ID: <199401241114.AA27691@terminus.cs.umb.edu>
To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Subject: Re: TEXROOT
Rather than ad hoc defining another special character,
I prefer that TEXROOT be expanded in the same way as
other variables (on Unix) --
with $TEXROOT.
That's how I intend my code to work, anyway, in the absence
of convincing arguments to the contrary :-)
I'm already committed to no %-specifiers in paths,
since ${var} can do everything they can.
There were lots of examples in this in the `HIER' file
I posted here a while back, which had Pierre's and my
default dir structure for Unix.
-------
I'm not sure how far this discussion is moving us towards
actually having a CD. We can debate directory structures
forever. There will never be one that is acceptable to everyone,
because different people and different sites have different needs.
Therefore, I'd vote that the structure on the CD itself
just be something reasonable and easy to install from,
and let it go at that.
================================================================================
Archive-Date: Mon, 24 Jan 1994 06:18:33 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 94 11:57:39 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401241157.AA11082@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: TEXROOT
References: <199401241114.AA27691@terminus.cs.umb.edu>
"K. Berry" writes:
> Rather than ad hoc defining another special character,
> I prefer that TEXROOT be expanded in the same way as
> other variables (on Unix) --
> with $TEXROOT.
>
> That's how I intend my code to work, anyway, in the absence
> of convincing arguments to the contrary :-)
I'm convinced, for one
> There were lots of examples in this in the `HIER' file
> I posted here a while back, which had Pierre's and my
> default dir structure for Unix.
i never got this, can you report to just me?
> Therefore, I'd vote that the structure on the CD itself
> just be something reasonable and easy to install from,
> and let it go at that.
quite. i think we all agree that the CD should have separate
directories for each `package' like a font or a style, not unlike the
current CTAN, and we'll need heavy duty install and use scripts. I
think Paul Taylor's system is an install-time option ("shall i build a
list of all the files and their locations so that you can run dynamic
file fetching and caching?"); it obviously makes sense if the CD and
CTAN are identical at various points in the tree, so that your
MakeTeXTeX or whatever can switch to network access if you have a
connection.
and it has to be said that lots of people dont have networks. gasp! i
dont, for one (i read mail on a phone line that costs me money).
sebastian
================================================================================
Archive-Date: Mon, 24 Jan 1994 07:40:19 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 1994 07:40:01 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, karl@cs.umb.edu
Message-ID: <00979014.B023F040.22316@SHSU.edu>
Subject: RE: TEXROOT
On Sun, 23 Jan 94 14:33:32 EST, karl@owl.HQ.ileaf.com (Karl Berry) posted:
> In my attempt to define a standard platform independant TeX structure
> I have used TEXROOT to represent the directory that contains it.
> [...]
> follow. Are we willing to do that? (Karl please give your opinion.)
>
> Yes, I am willing.
>......
> I slightly prefer the name `TEXMFROOT', but I won't put up a fuss about it.
Again, I may be showing a great degree of technical incompetence, but
shouldn't the names not exceed 8 characters if this is to be truly a
platform-independent approach? If so, TEXFMTROOT is 9 chars (although I'm
not stuck on any name, per se, I was under the impression that the project
was to allow as many similarities as not). Also, from
P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers) post of Sun, 23 Jan 1994
14:04:31 MET:
> TEXFORMATS (a natural place for formats/base/pool files)
while precisely what I would want would need another name, such as TEXFMT
or similar, wouldn't it?
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
Archive-Date: Mon, 24 Jan 1994 07:48:53 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 1994 07:48:18 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Message-ID: <00979015.D847B4C0.22377@SHSU.edu>
Subject: Re: an off the shelf TeX package
On Sun, 23 Jan 1994 23:01:22 +0000, Paul Taylor <pt@doc.ic.ac.uk> posted:
> I have put together a package of macros, fonts and various other things
> that seem appropriate for a complete text processing system. The origins of
> these are documented in a file (/tex/local-copy/pedigree) which is part of
> a script for rebuilding this package. It isn't yet converted to LaTeX2e and
> contains some non-standard stuff which would have to be reconsidered. The
> rebuilding takes things directly from the archive and therefore guarantees
> that things are up to date. What I propose is that such a package be built
> (periodically and automatically) on the archive itself and provided in
> .tar.Z and other archive formats.
Alright, I'll jump in with a position I've taken elsewhere, so I may as
well do it here. I would truly appreciate a package which provided
putatively up-to-date files directly from a known-to-be-good archive site.
Indeed, I might even go so far as to assert that the package be built or
re-built on a monthly or shorter basis. What I vehemently disagree with is
having to support multiple archive set formats as the ZIP utilities from
the Info-ZIP group are about as platform-independent as you can get -- I
see no reason why every site under every implementation of every OS which
is supported shouldn't support this as their primary archiving tool and we
use it -- period.
--George/sig
================================================================================
Archive-Date: Mon, 24 Jan 1994 15:45:53 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401242128.AA27210@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Mon, 24 Jan 1994 22:28:13 MET
To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU, pt@DOC.IC.AC.UK
Subject: Re: TEXROOT
[ "K. Berry" (Jan 24, 12:18):
> Rather than ad hoc defining another special character,
> I prefer that TEXROOT be expanded in the same way as
> other variables (on Unix) --
> with $TEXROOT.
>
> That's how I intend my code to work, anyway, in the absence
> of convincing arguments to the contrary :-)
> I'm already committed to no %-specifiers in paths,
> since ${var} can do everything they can.
I never suggested to use %TEXROOT% as MSDOS people have to do! Of course
UNIX people will use $TEXROOT or ${TEXROOT}.
> There were lots of examples in this in the `HIER' file
> I posted here a while back, which had Pierre's and my
> default dir structure for Unix.
>
I invite you to explain to the CTAN/CD-ROM folks:
- what is the current HIERARCHY of web2c?
- can this structure be (re)defined so that it will be the defacto standard
for *all* OS'es for now and forever? Eliminating differences that are
not essential but pure historical (inputs vs. macros etc.).
- is TEXROOT a good method to distribute binaries?
- can we standarize the names of TeX environments? So every TeX tool does
use the same name for the same thing (even on UNIX we have no standard:
TEXPKS for dvips, XDVIFONTS for xdvi).
> -------
>
> I'm not sure how far this discussion is moving us towards
> actually having a CD. We can debate directory structures
> forever. There will never be one that is acceptable to everyone,
> because different people and different sites have different needs.
> Therefore, I'd vote that the structure on the CD itself
> just be something reasonable and easy to install from,
> and let it go at that.
]
We already agreed more or less that the CD-ROM would be a mirror of the
CTAN archives. So having a good CTAN basic TeX structure is of vital
importance. Not only for the CD-ROM but also for the future of TeX. What we
try to achieve is that the maintenace of TeX on different platforms is as
easy as possible ...
--Piet
================================================================================
Archive-Date: Mon, 24 Jan 1994 15:50:02 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 94 20:49:11 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401242049.AA16017@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu
Subject: Re: an off the shelf TeX package
References: <"swan.doc.i.566:23.00.94.23.01.28"@doc.ic.ac.uk>
Paul Taylor writes:
> No, we were discussing how to find metafont and tex macro files from
> the archive. I advocate providing a script which would fetch these
> on demand and put them in a cache structure.
with respect, we shouldnt have been discussing this.
...
> propose is that such a package be built (periodically and automatically)
> on the archive itself and provided in .tar.Z and other archive formats.
CTAN would love it. you write the script, and we'll run it once a
week, and tell everyone to pick up the result.
but we should get back to this CD. it seems to me that the once ideal
notion of a single structure useable by everyone is out. but lets at
least go a half way house - lets have a structure like
macros
latex
seminar
babel
chess
plain
changebars
lollipop
fonts
cm
tfm
pk
etc, so that *some* people can use it directly. or are just going to
take the CTAN structure as is, with whatever small mods are needed? in
that case theres nothing to do except write install scripts..
anyone want to comment on the *content*? everything?
sebastian
================================================================================
Archive-Date: Mon, 24 Jan 1994 16:11:27 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401242210.AA27290@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Mon, 24 Jan 1994 23:10:20 MET
To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU, karl@cs.umb.edu
Subject: RE: TEXROOT
[ "George D. Greenwade" (Jan 24, 14:47):
> On Sun, 23 Jan 94 14:33:32 EST, karl@owl.HQ.ileaf.com (Karl Berry) posted:
> > In my attempt to define a standard platform independant TeX structure
> > I have used TEXROOT to represent the directory that contains it.
> > [...]
> > follow. Are we willing to do that? (Karl please give your opinion.)
> >
> > Yes, I am willing.
> >......
> > I slightly prefer the name `TEXMFROOT', but I won't put up a fuss about it.
I am afraid I missed the reaction with `Yes, I am willing'. George can you
send me that reaction?
> Again, I may be showing a great degree of technical incompetence, but
> shouldn't the names not exceed 8 characters if this is to be truly a
> platform-independent approach? If so, TEXFMTROOT is 9 chars (although I'm
> not stuck on any name, per se, I was under the impression that the project
> was to allow as many similarities as not). Also, from
> P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers) post of Sun, 23 Jan 1994
> 14:04:31 MET:
> > TEXFORMATS (a natural place for formats/base/pool files)
> while precisely what I would want would need another name, such as TEXFMT
> or similar, wouldn't it?
It is no `technical incompetence' from you but an oversight from me. TEXFMT
is OK for me. I don't see any need for a separate METAFONT tree. Please let
us make one TEX tree.
--Piet
================================================================================
Archive-Date: Mon, 24 Jan 1994 16:39:42 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401242233.AA27340@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Mon, 24 Jan 1994 23:33:18 MET
To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU, pt@DOC.IC.AC.UK
Subject: Re: an off the shelf TeX package
[ "George D. Greenwade" (Jan 24, 14:55):
> On Sun, 23 Jan 1994 23:01:22 +0000, Paul Taylor <pt@doc.ic.ac.uk> posted:
> > I have put together a package of macros, fonts and various other things
> > that seem appropriate for a complete text processing system. The origins of
> > these are documented in a file (/tex/local-copy/pedigree) which is part of
> > a script for rebuilding this package. It isn't yet converted to LaTeX2e and
> > contains some non-standard stuff which would have to be reconsidered. The
> > rebuilding takes things directly from the archive and therefore guarantees
> > that things are up to date. What I propose is that such a package be built
> > (periodically and automatically) on the archive itself and provided in
> > .tar.Z and other archive formats.
>
> Alright, I'll jump in with a position I've taken elsewhere, so I may as
> well do it here. I would truly appreciate a package which provided
> putatively up-to-date files directly from a known-to-be-good archive site.
> Indeed, I might even go so far as to assert that the package be built or
> re-built on a monthly or shorter basis. What I vehemently disagree with is
> having to support multiple archive set formats as the ZIP utilities from
> the Info-ZIP group are about as platform-independent as you can get -- I
> see no reason why every site under every implementation of every OS which
> is supported shouldn't support this as their primary archiving tool and we
> use it -- period.
>
> --George/sig
]
I fully agree that zip is a better platform independant foarmat than
the UNIX tar.Z or tar.gz. Tar is an old fashioned `tape archiver'. But
many UNIX people think they can't work without it. Tar is a standard
UNIX tool while zip has to be installed from the sources (because it is
not standard). For the same reason some prefer Bourne-shell as a
programming shell above perl.
Perhaps CTAN can distribute binaries of zip/unzip/perl for all kinds of
UNIX? Is there already a reliable perl for VMS?
--Piet
================================================================================
Archive-Date: Mon, 24 Jan 1994 17:20:45 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 1994 17:14:02 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
CC: pt@doc.ic.ac.uk
Message-ID: <00979064.E082B1E0.26285@SHSU.edu>
Subject: Re: an off the shelf TeX package
On Mon, 24 Jan 1994 23:33:18 MET, P.T.H.Tutelaers@urc.tue.nl (Piet
Tutelaers) posted:
> I fully agree that zip is a better platform independant foarmat than the
> UNIX tar.Z or tar.gz. Tar is an old fashioned `tape archiver'. But many
> UNIX people think they can't work without it. Tar is a standard UNIX tool
> while zip has to be installed from the sources (because it is not
> standard). For the same reason some prefer Bourne-shell as a programming
> shell above perl.
>
> Perhaps CTAN can distribute binaries of zip/unzip/perl for all kinds of
> UNIX? Is there already a reliable perl for VMS?
Sorry to belabor this point, but.... gzip (which you identify above) is
also not a default package -- if you want *true* Unix (which I am by no
means suggesting), you'd want .tar.Z. If you're willing to say "Unix folks
will do gzip" then you can equally well say "Unix folks will do ZIP".
Binaries for ZIP/UNZIP are specifically not provided as the Info-ZIP team
wants their package to be buildable wherever it is used. The CTAN simply
mirrors their authoritative host on quest.jpl.nasa.gov. For Unix and gcc,
it is (or should be) "make"able as it comes out of the wrapper. Binaries
are only provided for machines which do not usually "make" files -- such as
DOS, OS/2, Mac, Amiga, and VMS (where C is not a distributed default
compiler). This can certainly be discussed by the Info-ZIP team, but it
transcends the mission of the tools/info-zip/ in its present structure.
Finally, if anyone can point me to a working (not necressarily reliable,
simply working) VMS version of perl, please, please please do so. I really
need this and can't find it anywhere.
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
Archive-Date: Mon, 24 Jan 1994 17:50:47 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Mon, 24 Jan 94 23:31:25 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9401242331.AA16867@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
Subject: Re: an off the shelf TeX package
if we can give people tex binraies, we can giuve them zip binaries.
lets get real here, guys!
sebastian
================================================================================
Archive-Date: Mon, 24 Jan 1994 19:30:42 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <199401250118.AA00462@rwa.urc.tue.nl>
From: P.T.H.Tutelaers@urc.tue.nl (Piet Tutelaers)
Reply-To: TeX-CD@SHSU.edu, P.T.H.Tutelaers@URC.TUE.NL
Date: Tue, 25 Jan 1994 02:18:32 MET
To: TeX-CD@SHSU.edu
Subject: TEXFORMATS OK on MSDOS!
MSDOS accepts names like TEXFORMATS or LONGENVIRONMENTNAME. You can
also assign long values. So we don't need to restrict ourselves to
TEXFMT. The total environmental space is default limited to 512 bytes
but can be enlarged (I don't know the upperlimit).
I couldn't resist to bring this good news before I am going to my bed!
--Piet
================================================================================
Archive-Date: Tue, 25 Jan 1994 02:26:23 CST
Sender: CTAN-Mgr@SHSU.edu
Message-ID: <9401250822.AA26584@aquarius.cpb.nl>
To: TeX-CD@SHSU.edu
Subject: Re: TEXFORMATS OK on MSDOS!
Date: Tue, 25 Jan 94 09:22:18 +0100
From: J.J.Winnink@cpb.nl
Reply-To: TeX-CD@SHSU.edu, J.J.Winnink@CPB.NL
Piet Tutelaers writes:
> To: TeX-CD@SHSU.edu
> Subject: TEXFORMATS OK on MSDOS!
>
> MSDOS accepts names like TEXFORMATS or LONGENVIRONMENTNAME. You can
> also assign long values. So we don't need to restrict ourselves to
> TEXFMT. The total environmental space is default limited to 512 bytes
> but can be enlarged (I don't know the upperlimit).
As far a i know the upperlimit for the environment space in MSDOS is
32 Kbytes so that's not a serious restriction
________________________________________________________________________________
Jos Winnink
Central Planning Bureau
Applied Mathematics & Computer Science Dept.
v Stolkweg 14
P.O. BOX 80510
2508 GM The Hague
The Netherlands
internet: jos.winnink@cpb.nl
X-400: /C=nl/ADMD=400net/PRMD=surf/O=cpb/S=winnink/G=jos/
Telephone (+31) 70 338 3339
Telefax (+31) 70 338 3350
================================================================================
Archive-Date: Tue, 25 Jan 1994 05:41:28 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 25 Jan 1994 06:41:01 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU
Message-ID: <199401251141.AA23741@terminus.cs.umb.edu>
To: bed_gdg@SHSU.edu
Subject: RE: TEXROOT
CC: tex-cd@shsu.edu
My message suggested TEXMFROOT instead of TEXROOT, so as to
include the often-left-out Metafont.
I never suggested TEXFMTS or TEXFMT or whatever for anything.
That environment variable in web2c is TEXFORMATS (and there's also MFBASES).
It's true that TEXMFROOT is longer than 8 characters, but I don't think
there is a limitation, even in MS-DOG, of 8 chars on envvar names.
Piet, I know you didn't suggest a special character to mean TEXROOT,
but Paul did. (A leading + to mean expand into $TEXROOT.) This is what
I was responding to.
I'm not bothering to quote any of this since it's obvious none of
us read quoted material anyway :-)
(Also, like Sebastian, I pay money to read mail...)
K
================================================================================
Archive-Date: Tue, 25 Jan 1994 09:15:36 CST
Sender: CTAN-Mgr@SHSU.edu
From: Paul Taylor <pt@doc.ic.ac.uk>
Reply-To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Date: Tue, 25 Jan 1994 15:14:31 +0000
To: TeX-CD@SHSU.edu, spqr@ftp.tex.ac.uk
Subject: Re: an off the shelf TeX package
Message-ID: <"swan.doc.i.221:25.00.94.15.14.38"@doc.ic.ac.uk>
> CTAN would love it. you write the script, and we'll run it once a
> week
I think I can do that, but I am nervous about taking on responsibility
alone for something that is going to be used heavily.
It's bad enough doing it for IC. Let's discuss it privately.
> but we should get back to this CD. it seems to me that the once ideal
I made the mistake of writing too long a message before,
but I did say that I think the CD and the FTP archive should have
exactly the same structure, without specifying what that should be.
When you propose that the CD should have such and such a structure,
not being identical to that of the FTP archive, it is incumbent upon
you to explain WHY SHOULD THERE BE A DIFFERENCE?
I claim that any argument which applies to one applies equally to
the other, and thatto make them different creates unnecessary extra
new confusion.
Paul
================================================================================
Archive-Date: Tue, 25 Jan 1994 11:31:35 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 25 Jan 1994 12:31:10 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TeX-CD@SHSU.edu, kb@CS.UMB.EDU
Message-ID: <199401251731.AA26495@terminus.cs.umb.edu>
To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Subject: Re: an off the shelf TeX package
I agree with Paul here in principle -- no need to start from
scratch at designing the cd structure when we already
put so much time into doing the ctan structure.
My opinion is that it's time to try writing a real install script
or two, assuming the cd is a mirror of ctan, and see what problems
happen. Then there will some real data instead of just hypotheses.
(I know it's easy for me to say this, since I'm not the one
who's going to write the scripts, but still, imho ...)
================================================================================
Archive-Date: Tue, 25 Jan 1994 13:40:38 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Tue, 25 Jan 1994 13:40:13 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, pt@DOC.IC.AC.UK
Message-ID: <00979110.2C56CF60.31793@SHSU.edu>
Subject: Re: an off the shelf TeX package
A few people have been unilaterally added to the list TeX-CD@SHSU.edu. I
apologize for the invasion of bandwidth space on these people and sincerely
hope that they understand my motive in doing this. Briefly, what one group
determines impacts what another group may be pursuing, which in turn
impacts others, etc., etc., ad nauseum. If all are working toward similar
or parallel goals (which I think we are -- the betterment of TeX) but all
are following paths which do not, at some point, coincide with one another,
we've got a real problem. It is my contention that the CTAN, for better or
worse, by virtue of its being the collection point for everyone's work
effort is, by definition, that point of coincidence. Regardless of what
discussions ensue, I feel that it is incumbent on me, in my capacity as
Chair of the TUG Technical Working Group on TeX Archive Guidelines (among
other things), to ensure that how things proceed on the CTAN are toward the
betterment of TeX.
The enlargement of this list is for the purpose of getting some congruence
in where a few items are (or appear to be) heading at the moment. For all
who have been discussing items about the directory structure of the
LaTeX2.09/2e/3 with a plethora of cc's through the address CTAN@SHSU.edu,
welcome; to those who have been cc'ed via that list, this list, or some
other venue, or who have replied through some venue on which directories
for a CD, the CTAN, etc., was the focus, welcome. Most importantly,
everyone involved in all the discussions I am able to trace is included on
this list for now; thus, no one should need to go through the cc ritual any
longer -- hopefully, this is the appropriate audience, at a single address,
to come to a basic working hypothesis. The subscriber list is attached
below my sig so you can see who is involved here. If you know of someone I
have inadvertantly omitted and who should be included, please tell me and
we can get them here, too.
If we can get the developers of underlying packages (such as the LaTeX3
team and company) together with the developers of installation or
implementation kits (such as the CD group; would love to add someone
involved in the emTeX project, UnixTeX, DECUS, or elsewhere involved in
platform setups) together with the archivists (such as the CTAN
coordinators) together with the users (all of us, plus a few million
others), possibly -- just possibly -- some agreed-upon basic standards can
be derived.
My hope is that we can ultimately grab things off the net from wherever
package developers wish to place them and get them properly cataloged in
the CTAN so their efforts may be useful in the least painful fashion. From
the CTAN, it simply becomes a problem of propagation into the installation
kit distributions. The trick, at least as I naively see it, is to let
everyone involved have a clue about what the others are after -- and
possibly why they are after it. If we can preemptorily get a good working
arrangement in place now, we may very possibly save ourselves a lot of work
in the future by identifying existing limitations.
There has been some discussion on TeX-CD recently along the lines of:
> I'm not sure how far this discussion is moving us towards
> actually having a CD. We can debate directory structures
> forever. There will never be one that is acceptable to everyone,
> because different people and different sites have different needs.
(Mon, 24 Jan 1994 06:14:59 -0500, "K. Berry" <kb@cs.umb.edu>)
which I completely understand and basically agree with. My concern is
possibly impossible to achieve -- a generalized structure which is largely
platform-independent serving as a base for all installations on all
platforms, using a consistently-named set of environment variables/
logicals/paths/whatever-your-OS-calls-them to achieve most system-related
calls associated with the package/kit/installation. This would allow, as a
base, users and maintainers (increasingly becoming synonyms) to easily
migrate from one machine or OS to another. I am neither disallowing nor
discouraging site-specific tweaks to suit site-specific needs by any means,
especially on multi-user platforms or on platforms used by heavy-duty or
guru-type users (as many of you are).
What I, as quasi-naive Joe User (where my TeXnical skills really are, in
all honesty), am hoping to see is a very good to excellent product with an
acceptable learning curve for usage. Moreover, if I can learn it on one
platform, I'd really like to be able to use most of my knowledge -- not
just the concepts, but the keybarding aspects, as well -- on another
platform if I have to. Admittedly, platforms vary in what they can do and
how they do it; thus, in my view, it is the responsibility of the software
to make me as ignorant of the difference in operating system as it possibly
can.
> When you propose that the CD should have such and such a structure, not
> being identical to that of the FTP archive, it is incumbent upon you to
> explain WHY SHOULD THERE BE A DIFFERENCE?
>
> I claim that any argument which applies to one applies equally to the
> other, and thatto make them different creates unnecessary extra new
> confusion.
(Tue, 25 Jan 1994 15:14:31 +0000, Paul Taylor <pt@doc.ic.ac.uk>)
I would hope that the design of the CTAN is a workable one for both
archiving, maintenance, and usage. Quite possibly, this is an impossible
dream. Thus, how and where we archive things together with how TeX, et
al., and CTAN users will eventually reference them is the crux of nearly
all discussions I've seen. The CTAN is merely one structure -- it is
malleable and can be changed as needed to benefit a broader base than it
was originally intended to (basically, ftp users).
Can we move on with a CD project as things stand at the moment? Certainly!
Copy everything, write a few scripts for each platform, take into account
some bizzarities for the archive as it now stands compared as to how it can
be used on an operating system (recursiveness, how and where things get
cataloged, if paths can be supported, what environment names and space to
use, etc.) and get it out relatively quickly. Alternately, if we spend the
(admittedly boring) time now and get the underlying CTAN modified to assist
in everyone's goals and at least tentatively agree on a few basic
standards, the CD project (and others) may be slowed slightly, but the
long-term benefit to all projects should be well received. If for no other
reason than assisting in maintenance of the CD over time, airing of these
issues now is time well spent.
The better TeX-related things are constructed (from the CTAN, to the CD, to
the documentation of things on the CTAN/CD, to the ease of installation and
usage), the better the end product; the better the end product, the more
likely to be well-accepted by the end-user audience; the more well-accepted
by the end-user audience, the better for TeX.
Regards, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
P. O. Box 2118 FAX: (409) 294-3612
Sam Houston State University Internet: bed_gdg@SHSU.edu
Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
TeX-CD subscribers as of 25-JAN-1994 13:38:53
Include:
SIGNOFF TeX-CD
in the body of a mail message to LISTSERV@SHSU.edu to remove yourself from
this list.
"George D. Greenwade" <bed_gdg@SHSU.EDU>
"Barbara Beeton" <BNB@MATH.AMS.ORG>
"Christina Thiele" <cthiele@CCS.CARLETON.CA>
"Sebastian Rahtz" <spqr@FTP.TEX.AC.UK>
"Kees van der Laan" <cgl@RISC1.RUG.NL>
"Norman Walsh" <norm@ORA.COM>
rcpt@URC.TUE.NL
"K. Berry" <kb@CS.UMB.EDU>
"Patricia Monohon" <monohon@TUG.ORG>
"Joachim Lammarsch" <X33@VM.URZ.UNI-HEIDELBERG.DE>
"Michel Lavaud" <lavaud@CENTRE.UNIV-ORLEANS.FR>
"Paul Taylor" <pt@DOC.IC.AC.UK>
"Nils Rennebarth" <nils@EXP-MATH.UNI-ESSEN.DE>
"Rainer Schoepf" <schoepf@SC.ZIB-BERLIN.DE>
"Chris Rowley" <C.A.ROWLEY@OPEN.AC.UK>
"Alan Jeffrey" <alanje@COGS.SUSSEX.AC.UK>
"Frank Mittelbach" <MITTELBACH@MZDMZA.ZDV.UNI-MAINZ.DE>
"Joachim Schrod" <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
"David Carlisle" <carlisle@CS.MAN.AC.UK> (NOMAIL)
"Piet Tutelaers" <P.T.H.Tutelaers@URC.TUE.NL>
"Erik Frambach" <FRAMBACH@ECO.RUG.NL>
"Michael Goossens" <GOOSSENS@CERNVM.CERN.CH>
"Jos. Winnink" <J.J.Winnink@CPB.NL>
Archive-Date: Thu, 10 Feb 1994 11:45:29 CST
Sender: CTAN-Mgr@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TeX-CD@SHSU.edu, schrod@ITI.INFORMATIK.TH-DARMSTADT.DE
Message-ID: <9402101743.AA15432@spice.iti.informatik.th-darmstadt.de>
Subject: In need of more directories...
To: tex-cd@shsu.edu (TeX CD-kit discussion)
Date: Thu, 10 Feb 1994 18:43:59 +0100 (MEZ)
Content-Type: text
Hi,
since this list exists, I thought I should utilize it... :-)
I would like to get some comments on the name for two directories:
1. The directory where sources for LaTeX modules are put.
2. The directory where user manuals for LaTeX modules are put.
(For those, who haven't read it: `module' is my proposal for a term
that encompasses both `document class' and `LaTeX package'.) In the
text below, I orient myself along the document HIER that is
distributed in the kpathsea directory of the web2c documentation.
Ad 1:
Modules are sometimes created with the doc package of Frank, or
with my MAKEPROG system, or with some *WEB system. Then the source
should still be available for the end user, it often has the
information how to configure, adapt, or extend the module. Where do we
put them?
In latex/src/? In latexsrc/?
Ad 2:
Modules (good ones ;-) are accompanied by user manuals. They are
often in LaTeX or DVI form, sometimes the DVI file may be extracted
from the source (as in the stuff from the LaTeX core team). Where do
we put these documentation files?
In latex/doc/? In latexdoc/?
The background:
I'm writing the Generic Local Guide (GLG), a template that can be
transformed in a Local Guide by a (TeX) system administrator. In this
document, I assume that such directories exist or may exist. I want
to include proposal(s) how these directories are to be named -- that
may be a chance to advertise a canonical installation. So I would be
interested in your opinion.
Those who doesn't know it already, but who are interested in the
GLG, can fetch a prerelease from ftp.th-darmstadt.de:pub/tex/latex/,
the file is named genguide-<version>.tar.gz. I'm interested in
comments. (You'll notice that it's not yet finished, 'though...)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 10 Feb 1994 14:39:38 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 10 Feb 1994 14:37:53 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TeX-CD@SHSU.edu, bed_gdg@SHSU.EDU
To: TeX-CD@SHSU.edu, schrod@ITI.INFORMATIK.TH-DARMSTADT.DE
Message-ID: <00979DAA.E12357A0.12590@SHSU.edu>
Subject: RE: In need of more directories...
On Thu, 10 Feb 1994 18:43:59 +0100 (MEZ), Joachim Schrod
<schrod@iti.informatik.th-darmstadt.de> posted:
> I would like to get some comments on the name for two directories:
>
> 1. The directory where sources for LaTeX modules are put.
> 2. The directory where user manuals for LaTeX modules are put.
>
> (For those, who haven't read it: `module' is my proposal for a term that
> encompasses both `document class' and `LaTeX package'.) In the text below,
> I orient myself along the document HIER that is distributed in the kpathsea
> directory of the web2c documentation.
>
> Ad 1:
> Modules are sometimes created with the doc package of Frank, or
> with my MAKEPROG system, or with some *WEB system. Then the source
> should still be available for the end user, it often has the
> information how to configure, adapt, or extend the module. Where do we
> put them?
> In latex/src/? In latexsrc/?
>
> Ad 2:
> Modules (good ones ;-) are accompanied by user manuals. They are
> often in LaTeX or DVI form, sometimes the DVI file may be extracted
> from the source (as in the stuff from the LaTeX core team). Where do
> we put these documentation files?
> In latex/doc/? In latexdoc/?
>
> The background:
> I'm writing the Generic Local Guide (GLG), a template that can be
> transformed in a Local Guide by a (TeX) system administrator. In this
> document, I assume that such directories exist or may exist. I want
> to include proposal(s) how these directories are to be named -- that
> may be a chance to advertise a canonical installation. So I would be
> interested in your opinion.
> Those who doesn't know it already, but who are interested in the
> GLG, can fetch a prerelease from ftp.th-darmstadt.de:pub/tex/latex/,
> the file is named genguide-<version>.tar.gz. I'm interested in
> comments. (You'll notice that it's not yet finished, 'though...)
Hmmmm. I see the question and understand it, I think, but.... As the
archive is now structured, file sets (packages for creating styles in 2.09
lingo) reside in common directories, such as
macros/latex2e/contrib/supported/psnfss/
with all files -- sources, documentation, readme's, etc. -- all residing
within their own subdirectories. I'm making a very heroic assumption here,
but aren't users supposed to get the whole package when they retrieve it
(as the Mainz packages, for example, have been distributed for years)?
While I would love to be able to say "all documentation generated by the
packages should be <here>" and "all sources should be <there>" and actually
have everything <here> and <there>, is that something which can be ensured
without making the module-creating packages (such as doc and makeprog) an
awful lot smarter? Or, as usual, have I missed the point here?
--George
Archive-Date: Thu, 10 Mar 1994 12:02:23 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 10 Mar 94 16:04:43 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Message-ID: <9403101604.AA27877@ftp.tex.ac.uk>
To: tex-cd@shsu.edu
Subject: tex cd againe?
I have been very tied up and have not pursued this properly. but i
gather the 4TeX group are producing a CD anyway? is this right?
anything they need help with?
sebastian
================================================================================
Archive-Date: Thu, 10 Mar 1994 15:43:40 CST
Sender: CTAN-Mgr@SHSU.edu
Date: Thu, 10 Mar 1994 22:34:59 +0100
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9403102134.AA17447@risc1.rug.nl>
To: TeX-CD@SHSU.edu, spqr@FTP.TEX.AC.UK
Subject: Re: tex cd againe?
CC: e.h.m.frambach@eco.rug.nl, ntg@nic.surfnet.nl, w.dol@lei.agro.nl
Yes, the 4AllTeX people produce a cd for various reasons.
One is to hand it out at the course which is the day after our 9 June
meeting. NTG's board have agreed to support the effort, and to make
it a Dutch/NTG CD Rom, with as kernel 4AllTeX, and as extra specialDutch
things like some MAPS-s and some other specifics.
The experience gained can be worthwhile for the international CD-ROM to come.
At the moment it is not clear to me what will be precisely on it,
but I would like the TeXbook and METAfont book too.
Personally, I persuade the 4AllTeX guys to include my BLUes trilogy too, next
to some other work of us Dutchies.
MHO, and all respect, this does not conflict with the international CD.
I will forward yuor message for if they need any help. I'm not so
knowledgeable about the technical aspects of the CD drive, have not used
other than listening to music, even lack a drive connected to my PC. (Mac).
Best wishes, and hope to see you anyways at the EuroTeX'94?
---Kees---
Archive-Date: Wed, 13 Apr 1994 05:13:46 CST
Sender: owner-tex-cd@SHSU.edu
Date: Wed, 13 Apr 1994 12:14:30 +0200
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9404131014.AA26565@risc1.rug.nl>
To: tugbd-l@irlearn.ucd.ie
Subject: CD-ROM preliminary ToC, the 4AllTeX CD-ROM
CC: TeX-CD@shsu.edu
Hieronder volgt een voorlopige inhoudsopgave van de NTG 4allTeX CD.
Overigens is het misschien aardig te weten dat 4TeX op de CD gebruik maakt
van de nieuwste versies van emTeX (3c-beta11), dvidrv (1.5a), dvips (5.54)
en Qedit (3.0). Vandaar dat het versienummer 3.20 zal zijn.
\ams TeX/LaTeX stuff of American Mathimatical Society
\ams\amsfonts -, fonts
\ams\amsfonts\doc -, -, documentation
\ams\amsfonts\cmfonts -, -, Computer Modern fonts
\ams\amsfonts\cyrillic -, -, Cyrillic fonts
\ams\amsfonts\euler -, -, Euler fonts
\ams\amsfonts\euex -, -, Euler extended fonts
\ams\amsfonts\symbols -, -, symbol fonts
\ams\amsfonts\dpi300 -, -, PK files
\ams\amsfonts\dpi329 -, -, -
\ams\amsfonts\dpi360 -, -, -
\ams\amsfonts\dpi432 -, -, -
\ams\amsfonts\dpi518 -, -, -
\ams\amsfonts\dpi622 -, -, -
\ams\amsfonts\dpi746 -, -, -
\ams\amsfonts\tfm -, -, font metrics
\ams\amslatex -, AMS LaTeX
\ams\amslatex\doc -, documentation
\ams\amslatex\fontsel -, font selection scheme
\ams\amslatex\inputs -, LaTeX input files
\ams\amslatex\tfm -, font metrics for extra AMS LaTeX fonts
\ams\amstex21 -, AMS TeX
\ams\amstex21\amstex -, input files
\ams\amstex21\doc -, documentation
\ams\amstex21\tfm -, fonts metrics for extra AMS fonts
\bbs bulletin board information and programs
\biblio bibliographies on TeX etc. in bibTeX format
\distrib the 4allTeX distribution set
\distrib\disk01 -
\distrib\disk02 -
\distrib\disk03 -
\distrib\disk04 -
\distrib\disk05 -
\distrib\disk06 -
\distrib\disk07 -
\distrib\disk08a -
\distrib\disk08b -
\distrib\disk09 -
\distrib\disk10 -
\distrib\disk11 -
\distrib\disk12 -
\distrib\disk13 -
\distrib\disk14 -
\distrib\disk15 -
\distrib\disk16 -
\distrib\disk17 -
\distrib\disk18 -
\distrib\disk19 -
\distrib\disk20 -
\distrib\disk21 -
\distrib\disk22 -
\distrib\disk23 -
\distrib\disk24 -
\distrib\disk25 -
\distrib\disk26 -
\distrib\disk27 -
\distrib\disk28 -
\distrib\disk29 -
\distrib\latex2e -
\dviutils utility programs to manipulate DVI files
\emtex complete 4TeX Workbench, ready to run
\emtex\btexfmts -, big TeX format files
\emtex\texfmts -, format files
\emtex\btm -, btm files directory
\emtex\btm\convert -, -, conversions
\emtex\btm\utils -, -, utilities
\emtex\compiler -, TeX compilers
\emtex\doc -, documentation on TeX, LaTeX, style files etc.
\emtex\dll -, OS/2 dynamic link libraries
\emtex\formats -, input files for generating TeX format files
\emtex\formats\dc -, -, using DC fonts
\emtex\metafont -, Metafont
\emtex\metafont\bmfbases -, -, big format files
\emtex\metafont\mfbases -, -, format files
\emtex\metafont\mfinput -, -, input files
\emtex\metafont\mfinput\dc -, -, using DC fonts
\emtex\metafont\mfjob -, -, job files
\emtex\prndest -, printer en viewer types and destinations
\emtex\ps -, PostScript DVI driver
\emtex\ps\fonts -, -, fonts
\emtex\ps\reencode -, -, alternative font encodings
\emtex\spell -, spell-checker
\emtex\texfonts -, fonts in PK format
\emtex\texfonts\nosubst -, alternative font substitution
\emtex\texfonts\vf -, virtual fonts
\emtex\texinput -, input files, style files etc.
\emtex\texinput\babel -, Babel styles
\emtex\texinput\elsevier -, Elsevier styles
\emtex\texinput\kluwer -, Kluwer styles
\emtex\texinput\springer -, Springer styles
\emtex\texinput\nfss -, new font selection scheme input files
\emtex\texinput\ps -, PostScript style files
\emtex\texsampl -, TeX and LaTeX samples
\emtex\tfm -, font metrics
\emtex\utils -, utility programs
\emtex\utils\commerc -, -, commercial software
\emtex\utils\commerc\tse -, -, -, TSE editor macros
\emtex\utils\commerc\tse\doc -, -, -, -, documentation
\emtex\utils\commerc\tse\mac -, -, -, -, macros
\emtex\utils\commerc\tse\src -, -, -, -, sources
\emtex\utils\commerc\tse\ui -, -, -, -, user interface files
\emtex\utils\emx -, -, EMX dos extender
\emtex\utils\ghostscr -, -, GhostScript PostScript interpreter
\emtex\utils\rsx -, -, RSX dos extender
\emtex\utils\rsx\bin -, -, -, programs
\emtex\utils\rsx\doc -, -, -, documentation
\emtex\utils\rsx\fpu_emu -, -, -, coprocessor emulator
\emtex\utils\sharewar -, -, shareware
\emtex\utils\sharewar\4dos -, -, -, 4DOS replacement for command.com
\emtex\utils\sharewar\gws -, -, -, Graphics Work Station
\emtex\utils\sharewar\qedit -, -, -, Qedit 2.10 ascii editor plus macros
\emtex\utils\sharewar\qedit3 -, -, -, Qedit 3.00 ascii editor plus macros
\emtex\utils\source -, -, sources of utility programs
\gnuplot GNUplot plotting program
\gnuplot\demo -, demo programs
\gnuplot\doc -, documentation
\gnuplot\history -, history
\introduc introduction texts to TeX and LaTeX
\introduc\cwi -, CWI `Publiceren met LaTeX'
\introduc\horak -, Horak's examples
\introduc\horak\mfsource -, -, Metafont sources
\introduc\knuth -, Knuth's TeXbook and Metafont book
\litprog Literate Programming
\litprog\cweb -, CWEB
\litprog\cweb\examples -, -, examples
\maps NTG's MAPS of recent years
\ntg NTG Public Relations set
\ntg\4tex -, intro to 4TeX
\ntg\bridge -, macros for typesetting Bridge
\ntg\horak -, Horak's examples
\ntg\introtex -, introduction to TeX
\ntg\math -, mathematics in TeX
\ntg\music -, typesetting music in TeX
\ntg\schaak -, typesetting Chess in TeX
\ntg\tables -, typesetting tables in TeX
\ntg\watistex -, Van der Laan's `What is TeX and Metafont all about'
\polish Polish TeX package MEX
\polish\eminst -, installation of emTeX
\polish\istyles -, style files
\polish\mexinfo -, info on MEX package
\polish\mexlamex -, Polish LaTeX
\polish\plfonts -, Polish fonts
\polish\tfm -, font metrics of Polish fonts
\polish\epsonfx -, Epson FX PK file
\polish\epsonfx\192dpi -, -
\polish\epsonfx\216dpi -, -
\polish\epsonfx\240dpi -, -
\polish\epsonfx\263dpi -, -
\polish\epsonfx\288dpi -, -
\polish\epsonfx\346dpi -, -
\polish\epsonfx\415dpi -, -
\polish\epsonfx\498dpi -, -
\polish\epsonfx\597dpi -, -
\polish\fax -, FAX PK files
\polish\fax\163dpi -, -
\polish\fax\184dpi -, -
\polish\fax\204dpi -, -
\polish\fax\223dpi -, -
\polish\fax\245dpi -, -
\polish\fax\294dpi -, -
\polish\fax\353dpi -, -
\polish\fax\423dpi -, -
\polish\fax\508dpi -, -
\polish\hplaser -, HP Laserjet PK files
\polish\hplaser\240dpi -, -
\polish\hplaser\270dpi -, -
\polish\hplaser\300dpi -, -
\polish\hplaser\329dpi -, -
\polish\hplaser\360dpi -, -
\polish\hplaser\432dpi -, -
\polish\hplaser\518dpi -, -
\polish\hplaser\622dpi -, -
\polish\hplaser\746dpi -, -
\polish\hplaser4 -, HP Laserjet IV PK files
\polish\hplaser4\1037dpi -, -
\polish\hplaser4\1244dpi -, -
\polish\hplaser4\1493dpi -, -
\polish\hplaser4\480dpi -, -
\polish\hplaser4\540dpi -, -
\polish\hplaser4\600dpi -, -
\polish\hplaser4\657dpi -, -
\polish\hplaser4\720dpi -, -
\polish\hplaser4\864dpi -, -
\polish\lqlores -, EPSON LQ lores PK files
\polish\lqlores\144dpi -, -
\polish\lqlores\162dpi -, -
\polish\lqlores\180dpi -, -
\polish\lqlores\197dpi -, -
\polish\lqlores\216dpi -, -
\polish\lqlores\259dpi -, -
\polish\lqlores\311dpi -, -
\polish\lqlores\373dpi -, -
\polish\lqlores\448dpi -, -
\psutils PostScript utility programs
\russian Russian (Cyrillic) font package
\russian\mfinput -, Metafont sources
\russian\mfjob -, job files
\russian\tfm -, fonts metrics
\russian\epsonfx -, EPSON FX PK files
\russian\epsonfx\240dpi -, -
\russian\epsonfx\263dpi -, -
\russian\epsonfx\288dpi -, -
\russian\epsonfx\346dpi -, -
\russian\epsonfx\415dpi -, -
\russian\epsonfx\498dpi -, -
\russian\epsonfx\597dpi -, -
\russian\fax -, FAX PK files
\russian\fax\204dpi -, -
\russian\fax\223dpi -, -
\russian\fax\245dpi -, -
\russian\fax\294dpi -, -
\russian\fax\353dpi -, -
\russian\fax\423dpi -, -
\russian\fax\508dpi -, -
\russian\hplaser -, HP Laserjet PK files
\russian\hplaser\240dpi -, -
\russian\hplaser\270dpi -, -
\russian\hplaser\300dpi -, -
\russian\hplaser\329dpi -, -
\russian\hplaser\360dpi -, -
\russian\hplaser\432dpi -, -
\russian\hplaser\518dpi -, -
\russian\hplaser\622dpi -, -
\russian\hplaser\746dpi -, -
\russian\hplaser4 -, HP Laserjet IV PK files
\russian\hplaser4\1037dpi -, -
\russian\hplaser4\1244dpi -, -
\russian\hplaser4\1493dpi -, -
\russian\hplaser4\600dpi -, -
\russian\hplaser4\657dpi -, -
\russian\hplaser4\720dpi -, -
\russian\hplaser4\864dpi -, -
\russian\lqhires -, EPSON LQ hires PK files
\russian\lqhires\360dpi -, -
\russian\lqhires\394dpi -, -
\russian\lqhires\432dpi -, -
\russian\lqhires\518dpi -, -
\russian\lqhires\622dpi -, -
\russian\lqhires\746dpi -, -
\russian\lqhires\896dpi -, -
\salomon David Salomon's Advanced TeX course
\salomon\figures -, figures
\salomon\texts -, texts
\tex_nl TEX-NL mailing list archives of recent years
\texshell TeXshell, another popular integrated environment
\texshell\doc -, documentation
\texshell\doc\german -, -, in German
\vdlaan Kees van der Laan's articles on TeX
==== end ====
================================================================================
Archive-Date: Wed, 13 Apr 1994 05:32:22 CST
Sender: owner-tex-cd@SHSU.edu
Date: Wed, 13 Apr 1994 12:33:08 +0200
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9404131033.AA15004@risc1.rug.nl>
To: TeX-CD@shsu.edu
Subject: The last leads...
CC: tugbd-l@irlearn.ucd.ie
Dear Colleagues,
Some minutes ago I forwarded the preliminary ToC of the CD-ROM, and
we enjoy already some 50 reservations from NTG alone, with ukTUG
possibly another 50, TUG on sale/return basis another 40, and let us
say another 40 for EuroTeX'94. This makes that NTG is out of the riscs
zone.
In order to have a better idea of the number of copies involved
please inform me of the number needed certainly before 1 May, and preferably
before mid April.
The ukTUG and TUG reservations are still under discussion...
I hope that a similar UNIX CD-ROM will come off the grounds, and perhaps
some Dutchies are interested and have time to cooperate too.
>From 23 April onward I'm on my way to the GUST meeting and out of touch
until 6 May. During that time contact NTG@nic.surfnet.nl or Erik Frambach
directly (e.h.m.frambach@eco.rug.nl) (He is also on the board, so is Wietse
Dol, and therefore messages to NTG will reach them too.)
Hope, you will assist us in spreading this CD-ROM allover, and believe
it is a real nice working environment on top of emTeX.
The experience gained, will undoubtedly be available and hopefully
reused for the TeX and METAfont canonical set, whatever realization
that may eventually incarnate into.
Best wishes, and hope to hear from other lugs too how many copies
they like to reserve.
Best wishes, ---Kees---
================================================================================
Archive-Date: Wed, 13 Apr 1994 10:08:43 CST
Sender: owner-tex-cd@SHSU.edu
Date: Wed, 13 Apr 94 14:58:18 GMT
From: spqr@tex.ac.uk (Sebastian Rahtz)
Reply-To: TeX-CD@SHSU.edu, spqr@TEX.AC.UK
Message-ID: <9404131458.AA08786@ftp.tex.ac.uk>
To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Subject: Re: CD-ROM preliminary ToC, the 4AllTeX CD-ROM
References: <9404131014.AA26565@risc1.rug.nl>
a few comments :
i am a bit sad to see the AMS stuff not in the `canonical' layout
requested by the AMS. they made teh case strongly to CTAN that we
should mirror their setup exactly, whcih is no bad thing to do on this
CD too.
i'd also be interested to know whther you have a `compiled' latex2e on
there in the emtex setup. and what PostScript font metrics and setup
you are using. i'd remove nfss1 from there if it was me...
KVDL's articles seem to appear twice?
how about throwing in dviwindo?
is bm2font there?
how mcuh space do you have left? do you want more suggestions?
sebastian
================================================================================
Archive-Date: Wed, 13 Apr 1994 13:45:07 CST
Sender: owner-tex-cd@SHSU.edu
Date: Wed, 13 Apr 1994 18:30:43 +0200
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9404131630.AA13810@risc1.rug.nl>
To: TeX-CD@SHSU.edu, cgl@risc1.rug.nl, spqr@tex.ac.uk
Subject: Re: CD-ROM preliminary ToC, the 4AllTeX CD-ROM
CC: cgl@risc1.rug.nl
I will forward the message Sebastian. Good point about AMS set up!
My articles twice? I don't think so. But those which have
appeared in MAPSes will be twice, although the most recent versions
contain less errors, and are marked with tug.ppt proposal instead of
tugboat.sty or LaTeX for the MAPS. So if double the latter are improvements.
Best wishes, ---Kees---
================================================================================
Archive-Date: Thu, 14 Apr 1994 02:15:20 CST
Sender: owner-tex-cd@SHSU.edu
Date: Thu, 14 Apr 1994 09:16:03 +0200
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9404140716.AA27280@risc1.rug.nl>
To: spqr@ftp.tex.ac.uk
Subject: Reply from Wietse about your good suggestions and some more...
CC: TeX-CD@shsu.edu
In general: we are not planning to have a mirror of some kind. I.e. we want a
TeX version that will work and is userfriendly. Of course the availability of
all kind of nice programs is a (good) side-effect. So DVIWIN will be on board,
also BM2FONT (did you ever try to use 4TeX and graphics, see the article I
send to the Baskerville some time ago, also appeared in the MAPS).
I agree that we should try to immitate the AMS directory setup (what is the
crime if we don't???)
>KVDL's articles seem to appear twice?
Kees and his work is very precious to use, perhaps we are overdoing it a
bit...., we will try to get (only) one entry.
>i'd also be interested to know whther you have a `compiled' latex2e on
>there in the emtex setup. and what PostScript font metrics and setup
>you are using. i'd remove nfss1 from there if it was me...
This CD tries to reach something as perfection, however...
NFSS1 should be on it, i.e. it works and is well tested, many people will have
files written with NFSS1. I would only use NFSS2 in combination of LaTeX2e
(even better LaTeX 3). But I'am perhaps a bit ignorant because I do not have a
PS printer. Johannes Braams really tried to confince us that LaTeX2e should
not be on the CD (because it is the beta testversion and the official release
will be in june). So, we still think that it is not a good idea to have LaTeX2e
on the CD. Perhaps in time we change or mind.
Just keep sending the suggestions. As time and space permits we will see (the
CD-rom is already a collecters item).
Just remember us that we will send jou a complete filelist ASAP.
Greetings,
Wietse
PS Kees stuur jij het effen door naar sebastiaan, ik kon zo gauw het e-mail
nummer niet vinden.
+------------------------------------------------------------+
| Wietse Dol | e-mail: W.Dol@LEI.AGRO.NL|
+------------------------------------------------------------+
| Werk: | Prive: |
| Landbouw Economisch Instituut | |
| Conradkade 175 | Zonnedauwtuin 11 |
| 2517 CL Den Haag | 2317 MR Leiden |
| tel: 070-3308135 | tel: 071-210642 |
+------------------------------------------------------------+
D
================================================================================
Archive-Date: Sun, 17 Apr 1994 07:31:43 CST
Sender: owner-tex-cd@SHSU.edu
Date: Sun, 17 Apr 1994 14:32:21 +0200
From: cgl@risc1.rug.nl (Kees van der Laan)
Reply-To: TeX-CD@SHSU.edu, cgl@RISC1.RUG.NL
Message-ID: <9404171232.AA26436@risc1.rug.nl>
To: tex-nl@nic.surfnet.nl
Subject: For those still in doubt, (pr(preliminary, first set up) Preface 4AllTeX
CC: P.Taylor@rhbnc.ac.uk, TeX-CD@shsu.edu, cgl@risc1.rug.nl, irina@mir.msk.su, matwb@halina.univ.gda.pl, taupin@rsovax.ups.circe.fr, tugbd-l@irlearn.ucd.ie
Preface
4AllTeX{} started from the wish to reduce the fuss when installing
Mattes' ubiquitous em\TeX, possibly stimulated by NTG's call for
a PD PC \TeX{} \& \MF{} system `off-the-shelf.'
It has matured, and we can say that the authors have succeeded in
providing a Freeware/Shareware \TeX{} \& \MF{} environment,
`turn-key,' which has remained nevertheless flexible
for the advanced user for customization.
When demonstrated, I in particular liked the feature of
within context verifying marked up parts---just highlight the part and click.
Equally impressive is the incorporation of fonts: either it is just there
and can be used, or memory will be searched for a \PS{} version, or it will
be generated on the fly. Handy for the novice, for sure.
Perhaps best of all is how the `integrated environment' has been made
available. For example integration of pictures---be it in \PS, a bitmmap,
or\dots---in your document, is no longer a problem. It is just done
via the use of GhostScript. This has all been realized while obeying
Samelson's principle: `If you don't need a feature, it does not hinder,
you don't have to pay for the availability of things you don't use.'
These are just my top-three of the many goodies made available
at your fingertips, ready for use.
The dip in the development of the computers entering the homes---becoming
a system manager for PD software yourself---has been counteracted,
is no longer there for this computer-assisted writers' workbench.
Just execute the installation job, and start creating your documents.
And what about the service? First of all, the designers have chosen
for being conservative, not providing the latest hot items, which
generally are not yet reliable. In concrete terms this means that
\LaTeX2e is not yet there, because it has not been released.
Second, support has been channeled into a discussion list,
where users can help each other.
Third, for maintenance or extensions NTG envisions to bring out
once per year a floppy or so, with the newer developments.
Furthermore, there is always TUG's CTAN out there to be plucked,
for extensions of your own.
NTG is proud to host this project,
Kees van der Laan
President NTG
From owner-twg-tds@shsu.edu Tue, 10 May 1994 08:30:54 CST
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 10 May 1994 08:30:48 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: mike@inrs-telecom.uquebec.ca
CC: twg-tds@SHSU.edu, cthiele@ccs.carleton.ca
Message-ID: <0097E367.588ECFC0.113@SHSU.edu>
Subject: RE: New TWG on Directory Standards
I've already created <TWG-TDS@SHSU.edu> to accommodate the new Technical
Working Group on Directory Standards which Michael Ferguson has kindly
provided for the somewhat open-ended use stipulated in the attached
message. This is the first message posted to this list for the purpose of
including it in the official archives of the group. Presently subscribed
are Norm (co-owner of the list), Sebastian and me. In a following post to
Norm, I will provide instructions for maintenance. This list represents
the TWG and hence is not open to world subscription; it will require
explicit addition by either Norm or me. However, it is world postable --
anyone, subscriber or not, may post to the address <TWG-TDS@SHSU.edu>. The
purpose of this design is not to be exclusionary; instead, it is to provide
a level of quality control and consistency in communications among the TWG.
--George
===========================================================================
Date: Tue, 10 May 1994 08:30:35 -0400 (EDT)
From: "Michael J. Ferguson" <mike@inrs-telecom.uquebec.ca>
Subject: New TWG on Directory Standards
To: Norman Walsh <norm@ora.com>
CC: "George D. Greenwade" <bed_gdg@shsu.edu>, Sebastian Rahtz
<rahtz@dxcern.cern.ch>, spqr@ftp.tex.ac.uk, Christina Thiele
<cthiele@ccs.carleton.ca>
Message-ID: <Pine.3.05.9405100808.A21859-d100000@vimy>
Dear Norm,
After following the flurry of email activity over the last few days and
as Chair of the Technical Council I should like to invite you to form a
Technical Working Group (Standards) on "Directory Standards for TeX Software".
Please note, that the chair of a TWG has complete freedom in determining how
the TWG will function, and who will be members of such a TWG.
The current bylaws governing the "Technical Council" are as follows:
Article V: Section 2
Technical Council:
There shall be a Technical Council consisting of three members of the
\BoD{}, one of whom shall be appointed Technical Council
Chair. The primary purpose of the Technical Council shall be the study
of technical issues concerning \TeX, Metafont, and their auxiliary
support systems. The Council shall appoint Technical Working Groups to
make recommendations related to specific issues. After evaluation and
certification by the Council, the recommendations shall be brought to
the \BoD{} for formal recognition.
The Grand Wizard and the Wizard of Fonts
shall be permanent honorary members of the Technical Council.
The current membership of the Technical Council is
Michael Ferguson (Chair)
Yannis Haralambous
Sebastian Rahtz
Working Notes --- Michael Ferguson (Chair)
The primary intent of the Technical Council is to evaluate technical
issues, and recommend actions concerning TeX and its related systems, so
that a stable, consistent, and effective environment for document
preparation and production may be maintained. In order to carry out these
activities, the Council shall appoint Technical Working Groups to study an
issue, and to report its findings and recommendations to the Council. Any
recommendation will be subject to ``Certification'' by the Council before
being brought to the Board of Directors for ratification. The exact nature
of the Certification Process will be dependent upon the action recommended
and is a subject of further study.
There are three types of TWGs, Special Interest Group (SIG), Standards (STD),
and Independent Projects (IP). The SIGs are intended to service people with
special uses of TeX. Currently there are two SIGs, "TeX for the Disabled"
(Raman Chair) and "Visual Typesetting and Document Preparation" (Jonathan
Fine, Chair). The most visible and active Standards TWG is TWG-Archives.
Technical Working Groups:
A Technical Working Group shall consist of a Technical Working Group Chair,
Technical Working Group Members, and a Technical Council Liason.
-- The Technical Council Liason shall be a permanent member of the
Technical Council. The Liason shall be responsible for timely
reporting of Working Group activities, and for the deposition of
all Working Group Reports and Recommendations to the Council.
-- The Technical Working Group Chair shall be appointed by the Technical
Council. The Working Group Chair shall be solely responsible for the
study procedure and structure of the Working Group. All Technical
Working Group members shall serve at the discretion of the Working Group
Chair.
-- A Technical Working Group shall have a mandate to be determined by the
Technical Council.
-- Each Technical Working Group shall make a report of its activities at
each TUG Board of Director's meeting.
--------------------------------------------------------------------
The mandate of the new TWG is given below ... please feel free to modify it,
as necessary, to reflect the true purpose of the TWG
WG-94-07:
Title: TeX Directory Structures
Mandate: The primary purpose of this TWG is to identify a universal directory
structure for macros, fonts and other related TeX software so that
reccommendations can be made to all suppliers of TeX software.
Technical Working Group Chair: Norm Walsh
Technical Council Liason: Sebastian Rahtz
Yours,
Michael Ferguson
Technical Council Chair
----------------------------------------------------------
Prof. Michael J. Ferguson Tel: (514) 765-7834
INRS-Telecommunications FAX: (514) 761-8501
Univ. du Quebec Email: mike@vimy.inrs-telecom.uquebec.ca
16 Place du Commerce Home: (514) 486-3059
Verdun, Quebec H3E 1H6
Canada
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 May 1994 14:28:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 May 1994 15:28:17 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405171928.PAA25048@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Welcome to TWG-TDS
Reply-To: TWG-TDS@SHSU.edu
Welcome to the TWG-TDS mailing list.
This TUG Technical Working Group is charged with the task of determining
an implementation independent directory structure that TUG can promote
as a standard. Many of these issues, as we are all aware (and several
of you hinted privately in your responses to my invitation), have been
discussed before without concrete resolution. I hope that this time we
can reach a consensus and put these issues behind us.
With that in mind, here are some of the things that I've been thinking
about in drafting a proposal for a TeX Directory Structure (TDS).
1) We have to be practical. No matter what features we personally feel
are so obviously useful that failing to implement them makes us question
the sanity of the implementor, if the structure we arrive at is not
practically useful for existing TeXs, our recommendation is doomed.
2) On the flip side of the coin, there's no point wearing a straight-jacket.
If some features make a TDS easier to manage and simpler to use, I think
we should feel justified in recommending that vendors support those
features.
3) We have to accept the 8.3 filename limitation and slow machines. MS-DOS
running on slow PCs cannot be ignored.
4) We have to accept a directory hierarchy of limited depth. ISO-9660 CD-ROMs
can only go eight levels deep, and CDs are an important place where our
TDS can be implemented.
5) I work for O'Reilly and Associates. We're going to produce a CD of TeX
macros and fonts with the TDS. It's possible, I suppose, to argue that
I'm not entirely impartial. If you are concerned about my position,
I urge you to send email privately; let's try to keep politics out of
our decisions as much as is humanly possible.
With all that said, here's my first attempt at a proposal. Feel free to
empty both barrels ;-) This proposal addresses only the macros and fonts
directories. After, but not before, we get that squared away, let's broaden
the discussion to other implementation-independent files.
A PROPOSED DIRECTORY STRUCTURE FOR TEX MACROS AND FONTS
Norman Walsh Version 0.2
O'Reilly and Associates 17 May 94
90 Sherman Street
Cambridge, MA 02140
norm@ora.com
(617) 354-5800
------------------------------------------------------------------------------
The primary purpose of this proposal is to identify a universal directory
structure for macros and fonts, and other architecture independent files, that
the TWG can recommend to all vendors of TeX software.
A secondary purpose of this document is to identify the directory structure
for a CD-ROM that will be produced within the next few months. The fact that
this CD will be produced in the very near future means that a compromise
between proposed standards and existing technology may need to be reached.
(It's possible to argue that that compromise has no place in the TWG, but I
think it represents a concrete example for discussion.)
------------------------------------------------------------------------------
GENERAL ISSUES
1) The near-term use of this proposed standard will be on mountable CD-ROM
media, it is therefore necessary to keep in mind the limitations of that
medium. In particular, the ISO 9660 standard requires mono-case, 8.3
filenames with no more than eight levels of subdirectories.
2) Several free implementations of TeX now support recursive subdirectory
searching, while no commercial implementations do (to the best of my
knowledge). Question: is it time to simply expect that developers
implement recursive subdirectory searching?
3) In order to make a very large collection of files comprehensible, some
hierarchical subdirectory structure is necessary. Without subdirectory
searching, this structure is difficult to use; impossible, perhaps, on
some platforms (consider MS-DOS's limit of 128 characters in an environment
variable that might contain a list of subdirectories).
4) Automatic font generation is a big win. Unfortunately, many commercial
packages don't include MF.
------------------------------------------------------------------------------
MACROS
The current method of including TeX inputs seems to be placing them in a
small number of directories, pointed to by an environment variable formatted
analogous to the PATH variable. For example, macros might be placed in
E:\EMTEX\TEXINPUT
and
F:\TEX\STYLES
pointed to by
TEXINPUT=E:\EMTEX\TEXINPUT;F:\TEX\STYLES
(or /usr/local/lib/tex/inputs and /home/norm/tex/inputs, pointed to by
TEXINPUTS=/usr/local/lib/tex/inputs:~/tex/inputs)
This has the disadvantage of making it difficult to determine which input
files are associated with which macro packages, and may result in version
mismatches and other errors when a package is upgraded, especially if the
names of some files change.
To combat the maintainance problem, CTAN uses a very deep structure:
macros/latex/contrib/<package>
which is usable, if subdirectory searching is provided, although it may
be slow. The existence of hundreds of packages means that hundreds of
directories must be searched. On the other hand, this approach seems to
be the only way to segregate input files (and documentation) for particular
packages.
>>> Proposal: Macro files should be stored in a directory structure with
the following form:
/texmf/tex/<format>/<package>/<files>
format is "plain", "latex", "latex2e", etc. This makes it easy to
limit subdirectory searching to only those input files that might be
used by the format in question.
package is the name of the package, or primary style file. For example,
"verbatim" or "changebar".
>>> Compromise: Since recursive subdirectory searching may be slow in coming,
the following alternate form will be provided on the CD (IN ADDITION TO
the format described above):
/texmf/tex/<format>/<files>
It may also be wise to provide a script which can build the alternate
format from the proposed format automatically on a local medium.
------------------------------------------------------------------------------
FONTS
The current method of including TeX fonts seems to be placing them in a
small number of directories, pointed to by an environment variable formatted
analogous to the PATH variable. Within each directory, a directory exists
for each resolution. Actually, this is only the standard on MS-DOS (and
other?) platforms that have restrictive filename limitations. But since
ISO 9660 has exactly those limitations...
Like macros, fonts need to be stored in a hierarchical structure in order to
make maintainance possible.
>>> Proposal: Fonts should be stored in a directory structure like the
following:
For MF fonts:
/texmf/fonts/<source>/<typeface>/src
/texmf/fonts/<source>/<typeface>/tfm
/texmf/fonts/<source>/<typeface>/vf
/texmf/fonts/<source>/<typeface>/vpl
/texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
For PS fonts:
/texmf/fonts/<source>/<typeface>/afm
/texmf/fonts/<source>/<typeface>/tfm
/texmf/fonts/<source>/<typeface>/vf
/texmf/fonts/<source>/<typeface>/vpl
/texmf/fonts/<source>/<typeface>/glyphs/type1/<files>
/texmf/fonts/<source>/<typeface>/glyphs/pk/<dpi>/<files>
For PK files, then convention under UNIX has been .../pk/cx/cmr10.300pk
rather than .../pk/cx/300dpi/cmr10.pk, but there's no way to do that under
MS-DOS, or on a CD.
>>> Compromise: on the CD, PK and TFM files will ADDITIONALLY be provided
in the following structure:
/texmf/fonts/tfm
/texmf/fonts/<mode>/<dpi>/<files>
This structure flattens the source/typeface layer out, but it means that
existing implementations that don't provide subdirectory searching will
be able to use the fonts from the CD. The PK files can't be built in the
other tree anyway, so it seems like a fair compromise (especially since
KB's font naming scheme removes ambiguity from filenames). The TFM files
will be provided twice, but the PK files will only be provided in the
compromise structure on the CD.
------------------------------------------------------------------------------
ACKNOWLEDGEMENTS
In every major way, this proposal flows naturally from the work done by
Karl Berry and Pierre Mackay.
------------------------------------------------------------------------------
EOF
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 May 1994 14:59:11 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q3VDC-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 17 May 94 20:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Welcome to TWG-TDS
Damn, why is C-C C-C next to C-X C-X ...
As I was saying... Let me guess, ISO-9660 doesn't support aliases :-(
If we're only going to support one of the long form or the short form
for PKs, I'd rather have the long form, since it's easier to generate
the short from the long form than the other way round.
As a larger-scale question, do we envisage people using the CD-ROM by
copying the material they want onto the hard disk (in which case TeX
implementation limitations aren't so important) or getting files
directly off the CD-ROM?
Alan.
Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.susx.ac.uk
School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 May 1994 14:59:34 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q3V8f-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 17 May 94 20:49 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Welcome to TWG-TDS
A couple of niggles just to get started :-)
> /texmf/tex/<format>/<package>/<files>
> format is "plain", "latex", "latex2e", etc.
By the time any CD-ROM comes out, that'll be "latex209", "latex",
etc. :-)
> /texmf/fonts/<source>/<typeface>/vf
> /texmf/fonts/<source>/<typeface>/vpl
Presumbaly these two will be optional.
> /texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
Why have glyphs/pk? Why not just pk?
> /texmf/fonts/<source>/<typeface>/glyphs/type1/<files>
> /texmf/fonts/<source>/<typeface>/glyphs/pk/<dpi>/<files>
Again, why not just:
/texmf/fonts/<source>/<typeface>/pfa/<files>
/texmf/fonts/<source>/<typeface>/pfb/<files>
/texmf/fonts/<source>/<typeface>/pk/<dpi>/<files>
etc.
> The TFM files
> will be provided twice, but the PK files will only be provided in the
> compromise structure on the CD.
Urg, let me guess, CD
>------------------------------------------------------------------------------
>ACKNOWLEDGEMENTS
>In every major way, this proposal flows naturally from the work done by
>Karl Berry and Pierre Mackay.
>------------------------------------------------------------------------------
>EOF
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 02:06:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 1994 09:02:17 GMT+200
From: Erik Frambach <E.H.M.Frambach@eco.rug.nl>
Subject: Re: Welcome to TWG-TDS
To: TWG-TDS@SHSU.EDU
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <297628C6C3E@eco3.eco.rug.nl>
Content-Transfer-Encoding: 7BIT
[..]
> 4) We have to accept a directory hierarchy of limited depth. ISO-9660 CD-ROMs
> can only go eight levels deep, and CDs are an important place where our
> TDS can be implemented.
There is more to ISO-9660.
1. ONLY the characters A-Z, 0-9 and the underscore are allowed in
file names.
2. File name extension are like file names, but that the characters 0-9
are NOT allowed.
3. Directory names are like file names, but can NOT have extensions.
4. Features like file/directory linking and file attributes are unknown.
This is no real problem for the directory structure, but I would not like
to count the files on CTAN that do not comply to ISO-9660.
So, defining a TDS is fine, but after that, can we use it for a CD for
everyone? Can you compromise with ISO-9660?
You could put all files in e.g. zip files, but then I would be forced to
install everything on my own disk...
[..]
> 2) Several free implementations of TeX now support recursive subdirectory
> searching, while no commercial implementations do (to the best of my
> knowledge). Question: is it time to simply expect that developers
> implement recursive subdirectory searching?
Yes, it's time!
[..]
> /texmf/tex/<format>/<package>/<files>
>
> format is "plain", "latex", "latex2e", etc. This makes it easy to
> limit subdirectory searching to only those input files that might be
> used by the format in question.
Let's try to avoid redundancy: the word `tex' is redundant by definition.
What does `texmf' stand for? `TeX & Metafont', or TeX macro files? Is it
the root?
Where do we put <format> independent files?
Erik Frambach
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 12:27:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 1994 12:27:12 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097E9D1.B210EF40.52@SHSU.edu>
Subject: Re: Welcome to TWG-TDS
On Wed, 18 May 1994 09:02:17 GMT+200, Erik Frambach
<E.H.M.Frambach@eco.rug.nl> posted:
> > 4) We have to accept a directory hierarchy of limited depth. ISO-9660 CD-ROMs
> > can only go eight levels deep, and CDs are an important place where our
> > TDS can be implemented.
>
> There is more to ISO-9660.
> 1. ONLY the characters A-Z, 0-9 and the underscore are allowed in
> file names.
> 2. File name extension are like file names, but that the characters 0-9
> are NOT allowed.
> 3. Directory names are like file names, but can NOT have extensions.
> 4. Features like file/directory linking and file attributes are unknown.
> This is no real problem for the directory structure, but I would not like
> to count the files on CTAN that do not comply to ISO-9660.
> So, defining a TDS is fine, but after that, can we use it for a CD for
> everyone? Can you compromise with ISO-9660?
> You could put all files in e.g. zip files, but then I would be forced to
> install everything on my own disk...
At one point, Sebastian had worked up something to handle many of these
issues as there was an attempt to place everything on ftp.tex.ac.uk (Unix)
on the old tex.ac.uk (VMS). To do so required some manipulation and I
don't know if the issue was ever resolved. Items 1 and 3 are pretty much
the same limits faced with the Unix->VMS translation (plus the hyphen and
dollar sign, which are not used under ISO-9660) and extensions have the
same attributes as filenames. Possibly a scheme to translate non-compliant
names to be accepted by ISP-9660 can be derived from that.
One item worth mentioning -- I have seen a few authors change habits in
naming and file location based on how it ends up on the CTAN. I am not
recommending that we require ISO-9660 compliance for the CTAN, but I
imagine that if authors understand that their compliance means a ready-made
bigger audience for their efforts, they might not be so difficult to change
habits. No, not all hard-heads will change, and yes, a few items may
require non-compliant names to be compliant for some other reason -- but
getting the directories populated by 9660-compliant files once a known
structure is promulgated probably won't be all that hard. ZIP is a good
option for those not in compliance as it has a built-in algorithm for
platform-specific requirements, be it in names or file structure, where
those items matter.
What also might be nice (and this is a long way away probably) would be to
have ISO-9660 compliant files which could serve as drivers for each
platform -- built-in software interfaces, if you will -- so that the
limitations of the TDS don't become limitations of the platform. If this
interface could be achieved, ISO-9660 shouldn't be a problem for anything
if a driver is present.
> [..]
> > 2) Several free implementations of TeX now support recursive subdirectory
> > searching, while no commercial implementations do (to the best of my
> > knowledge). Question: is it time to simply expect that developers
> > implement recursive subdirectory searching?
> Yes, it's time!
This may be an area where a little goodwill might go a long way. Since
recursive searching is supported in the p.d. versions, might it be
worthwhile to share some insights with developers of the commercial
implementations if they might want it? Or is this so well documented that
it ought to have been done by now anyway? Or is this so implementation
specific that it really gets down to taking apart and rebuilding asically
from scratch?
> [..]
> > /texmf/tex/<format>/<package>/<files>
> >
> > format is "plain", "latex", "latex2e", etc. This makes it easy to
> > limit subdirectory searching to only those input files that might be
> > used by the format in question.
> Let's try to avoid redundancy: the word `tex' is redundant by definition.
> What does `texmf' stand for? `TeX & Metafont', or TeX macro files? Is it
> the root?
> Where do we put <format> independent files?
TeX and Metafont for texmf. I would assume format-independent files would
go to "generic" or somesuch if we followed the lead of the CTAN on this.
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 13:12:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q3mGk-000076C@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 18 May 94 15:06 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: Welcome to TWG-TDS
>Let's try to avoid redundancy: the word `tex' is redundant by definition.
>What does `texmf' stand for? `TeX & Metafont', or TeX macro files? Is it
>the root?
TeX and Metafont... Personally I'd rather just have tex (but then I
use MF fonts pretty rarely these days :-) Our tex directory has
subdirectories tex, mf, dvips, etc. etc. So the extra `tex' isn't
redundant (although it's a bit weird having to type
/local/tex/tex/inputs :-)
>Where do we put <format> independent files?
How many of them are there? If there's more than a dozen, we could
have an anyfmt directory, but I doubt there's that many. null.tex,
epsf.tex, fontinst.sty, er...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:20:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 94 14:21:06 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405181421.AA21491@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405171928.PAA25048@ruby.ora.com> <m0q3VDC-00005aC@csrj.crn.cogs.susx.ac.uk>
>
> As a larger-scale question, do we envisage people using the CD-ROM by
> copying the material they want onto the hard disk (in which case TeX
> implementation limitations aren't so important) or getting files
> directly off the CD-ROM?
>
I'd say both. I think we really want a runnable file system on the CD
if at all possible.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:21:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 94 14:23:30 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405181423.AA21528@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405171928.PAA25048@ruby.ora.com> <m0q3V8f-00005aC@csrj.crn.cogs.susx.ac.uk>
Alan Jeffrey writes:
> A couple of niggles just to get started :-)
>
> > /texmf/tex/<format>/<package>/<files>
>
> > format is "plain", "latex", "latex2e", etc.
>
> By the time any CD-ROM comes out, that'll be "latex209", "latex",
you *are* getting confident about release dates!
> > /texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
>
> Why have glyphs/pk? Why not just pk?
i agree
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:22:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 94 15:03:15 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405181503.AA21853@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <297628C6C3E@eco3.eco.rug.nl>
> This is no real problem for the directory structure, but I would not like
> to count the files on CTAN that do not comply to ISO-9660.
I would like to count them... I want to see the size of the problem,
so that we can solve this wretched business
> So, defining a TDS is fine, but after that, can we use it for a CD for
> everyone? Can you compromise with ISO-9660?
we have to, dont we?
> You could put all files in e.g. zip files, but then I would be forced to
> install everything on my own disk...
no, that just makes us the same as the Prime Time Freeware disk. I
think we are committed to an expanded structure
> Where do we put <format> independent files?
texmf/tex/generic, i guess.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:23:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 94 14:46:05 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405181446.AA21660@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405171928.PAA25048@ruby.ora.com>
> 1) The near-term use of this proposed standard will be on mountable CD-ROM
> media, it is therefore necessary to keep in mind the limitations of that
> medium. In particular, the ISO 9660 standard requires mono-case, 8.3
> filenames with no more than eight levels of subdirectories.
we should at least consider whether to use Rock Ridge extensions, to
at least get case sensitivity on thos OSes which want it (just Unix,
yes?)
> 2) Several free implementations of TeX now support recursive subdirectory
> searching, while no commercial implementations do (to the best of my
> knowledge). Question: is it time to simply expect that developers
> implement recursive subdirectory searching?
YES! Bob Harris has said he is willing to do it, and Karl's path
searching code is publicly available for people to examine and learn
from
> >>> Proposal: Macro files should be stored in a directory structure with
> the following form:
>
> /texmf/tex/<format>/<package>/<files>
the "/tex/" *is* slightly redundant, but it does distinguish it from
'mf'. in line with the avowed policy of using the Berry/Mackay scheme,
I say live with it until proved impossible.
i was initially against /<format>/ but I now agree it is worth having,
given the huge quantities of files. it makes sense to allow a `plain'
user an easy way to set up a command file to avoid the LaTeX tree
> >>> Compromise: Since recursive subdirectory searching may be slow in coming,
> the following alternate form will be provided on the CD (IN ADDITION TO
> the format described above):
>
> /texmf/tex/<format>/<files>
>
> It may also be wise to provide a script which can build the alternate
> format from the proposed format automatically on a local medium.
alternatively, have an install script which copies from
CD:<format>/<package>/* to HARDDISK:<format> for those who have to
have it that way.
> /texmf/fonts/<source>/<typeface>/src
> /texmf/fonts/<source>/<typeface>/tfm
> /texmf/fonts/<source>/<typeface>/vf
> /texmf/fonts/<source>/<typeface>/vpl
> /texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
i agree with Alan, the <glyphs>/ is not needed. and if one follows
Berry names, the <source>/ isnt needed either, since Berry promises
unique names (though i bet all the MF fonts are not done yet)
> >>> Compromise: on the CD, PK and TFM files will ADDITIONALLY be provided
> in the following structure:
>
> /texmf/fonts/tfm
> /texmf/fonts/<mode>/<dpi>/<files>
lets just consider that a moment. how does the user of web2c TeX
specify that fonts/foo/ptm/tfm is needed, but not fonts/tfm. does
TEXFONTS=fonts//tfm *avoid* the fonts/tfm directory? I am not sure.
> be able to use the fonts from the CD. The PK files can't be built in the
> other tree anyway, so it seems like a fair compromise (especially since
> KB's font naming scheme removes ambiguity from filenames). The TFM files
> will be provided twice, but the PK files will only be provided in the
> compromise structure on the CD.
i dont understand that. wht cant the PK files be built in the full
tree?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:28:02 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q3rCc-00004SC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 18 May 94 20:22 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
> > By the time any CD-ROM comes out, that'll be "latex209", "latex",
>you *are* getting confident about release dates!
Sorry, I meant `that may be'. Got to keep up appearances :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:39:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 1994 15:39:50 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405181939.PAA11333@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Runnable file systems
References: <199405171928.PAA25048@ruby.ora.com> <m0q3VDC-00005aC@csrj.crn.cogs.susx.ac.uk> <9405181421.AA21491@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 18 May 1994 at 14:21:06, Sebastian Rahtz wrote:
> >
> > As a larger-scale question, do we envisage people using the CD-ROM by
> > copying the material they want onto the hard disk (in which case TeX
> > implementation limitations aren't so important) or getting files
> > directly off the CD-ROM?
> >
> I'd say both. I think we really want a runnable file system on the CD
> if at all possible.
I think it's imperative that the provide a mountable, usable file system
if at all possible.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 14:54:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 1994 15:54:42 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405181954.PAA12550@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405171928.PAA25048@ruby.ora.com> <9405181446.AA21660@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 18 May 1994 at 14:46:05, Sebastian Rahtz wrote:
> > 1) The near-term use of this proposed standard will be on mountable CD-ROM
> > media, it is therefore necessary to keep in mind the limitations of that
> > medium. In particular, the ISO 9660 standard requires mono-case, 8.3
> > filenames with no more than eight levels of subdirectories.
> we should at least consider whether to use Rock Ridge extensions, to
> at least get case sensitivity on thos OSes which want it (just Unix,
> yes?)
Let's set rock ridge aside for the moment. Our first goal is a TDS. We
cannot *insist* on rock ridge or any other format since many OS's won't be
able to read it. Can you put a rock ridge disk in a Mac?
> > /texmf/fonts/<source>/<typeface>/src
> > /texmf/fonts/<source>/<typeface>/tfm
> > /texmf/fonts/<source>/<typeface>/vf
> > /texmf/fonts/<source>/<typeface>/vpl
> > /texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
> i agree with Alan, the <glyphs>/ is not needed. and if one follows
> Berry names, the <source>/ isnt needed either, since Berry promises
> unique names (though i bet all the MF fonts are not done yet)
The point of /source/ is to easily distinguish one vendor from another.
I guess we don't need it, but I think many users will be much more
comfortable with an /adobe/ directory and /public/ directory and
a /bitstream/ directory, etc.
Is there a good argument against it?
> > >>> Compromise: on the CD, PK and TFM files will ADDITIONALLY be provided
> > in the following structure:
> >
> > /texmf/fonts/tfm
> > /texmf/fonts/<mode>/<dpi>/<files>
> lets just consider that a moment. how does the user of web2c TeX
> specify that fonts/foo/ptm/tfm is needed, but not fonts/tfm. does
> TEXFONTS=fonts//tfm *avoid* the fonts/tfm directory? I am not sure.
I'm not sure either. Maybe the duplicate TFMs should be moved out of
/texmf.
> > be able to use the fonts from the CD. The PK files can't be built in the
> > other tree anyway, so it seems like a fair compromise (especially since
> > KB's font naming scheme removes ambiguity from filenames). The TFM files
> > will be provided twice, but the PK files will only be provided in the
> > compromise structure on the CD.
> i dont understand that. wht cant the PK files be built in the full
> tree?
Because if the PK files are in the full tree, they are useless to all
drivers that don't support subdirectory searching. For macro files, it's
reasonable to say that you should copy the macros onto your hard disk
until you have a "decent" TeX. Since the fonts are *huge*, I didn't think
that that was reasonable.
Note: this is another CD-ROM issue, and I think I shouldn't have mentioned
those in my proposal. For the TDS, PK files go in the full tree!
Cheers,
norm
---
Norman Walsh <norm@ora.com> | A successful tool is one that was used to do
Production Tools Specialist | something undreamed of by its author. -- S. C.
O'Reilly & Associates, Inc. | Johnson
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 May 1994 15:01:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 May 1994 16:01:50 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405182001.QAA13429@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Font directories...
References: <199405171928.PAA25048@ruby.ora.com> <m0q3V8f-00005aC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 17 May 1994 at 20:49, Alan Jeffrey wrote:
> > /texmf/fonts/<source>/<typeface>/vf
> > /texmf/fonts/<source>/<typeface>/vpl
>
> Presumbaly these two will be optional.
Sure. Some fonts won't have 'em.
> > /texmf/fonts/<source>/<typeface>/glyphs/pk/<mode>/<dpi>/<files>
>
> Why have glyphs/pk? Why not just pk?
>
> > /texmf/fonts/<source>/<typeface>/glyphs/type1/<files>
> > /texmf/fonts/<source>/<typeface>/glyphs/pk/<dpi>/<files>
>
> Again, why not just:
>
> /texmf/fonts/<source>/<typeface>/pfa/<files>
> /texmf/fonts/<source>/<typeface>/pfb/<files>
> /texmf/fonts/<source>/<typeface>/pk/<dpi>/<files>
>
> etc.
Well, what does everyone think? The KB/PM setup has the /glyph/ level
and I guess I just copied it. I think the simplification makes sense.
Comments?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 05:06:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 1994 06:06:27 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405191006.AA12415@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
Norm, I think the proposed compromises are, in general, good. I like the
idea of not requiring subdirectory searching; as a practical matter, few
implementations (just web2c and --recently-- emtex, right?) have it, so
assuming it right now seems inappropriate.
I think there is only one big problem here: cmr10.300pk vs.
dpi300/cmr10.pk. Yes, ISO restrict us to the latter. That means that
kpathsea programs (which is to say, web2c) won't work without changing
one definition (in kpathsea/tex-glyphs.c). The true dvips/xdvi would
also require changes (in the default definition of their %-style paths).
I'm not sure what other Unix (and maybe VMS? And any other long-name
operating system)-world drivers are in common use, but I bet they too
would need changes to the sources that come off the net. I predict that
will be an endless source of trouble.
Getting back to the Theoretically Correct Thing To Do, I am not at all
prepared to admit that dpi300/cmr10.pk is theoretically better than
cmr10.300pk. (In fact, I think it's worse.) Thus, I do not want to
change the Unix defaults just because of DOS (or TDS) limitations,
though I am ready to be swayed by a persuasive argument ... The default
in mf.web is cmr10.300pk, another factor to take into consideration.
I do hope to change my programs so that they will find fonts in both
forms, but I don't know when that will happen, and that won't help with
all the other programs out there that want cmr10.300pk, anyway.
So, what to do? I don't know. If you put non-ISO-conforming files on a
CD ROM does that screw up the whole CD for DOSish systems, or just the
directories with the bad files? If the latter, you could have the files
both ways.
Other comments:
1) Alan suggests that there's no point in glyphs/. I agree. This was in an
early version of the Pierre/Karl hierarchy, but then we couldn't see any
time you might want to search along a hypothetical ``TEXGLYPHS'' path.
So we tossed it. Save a directory level today.
2) I invented ``texmf'' (to pick up on Erik's question) because it was the
installation directory in /usr/local/lib. I didn't want to use ``tex''
because (1) most Unix sites were already using /usr/local/lib/tex (that
was a path in the previous defaults), and (2) it includes not just
TeX-proper stuff.
I think the name of the root of the tree is not something that should be
standardized. For example, suppose a CD was cut for, oh, Solaris, with
precompiled binaries on it. Its top-level would look like:
bin/
man/
... and what goes along with this? `lib', is my answer, not `texmf'.
(With the same `tex', `mf', `bibtex', `fonts', etc. subdirectories.)
We are trying to define the structure of a TeX library containing
implementation/platform-independent files. The root of the tree is gonna
vary from site to site.
3)
>>> Compromise: Since recursive subdirectory searching may be slow
in coming, the following alternate form will be provided on the
CD (IN ADDITION TO
Will there be enough space on a CD to provide duplicate forms of many
files? (Assuming you can't use (the non-ISO) hard links.)
4) About files that work under different formats: this is hard. I
finesse this problem now by simply searching the entire tex/ tree, so it
doesn't matter where the common files. However, since the latex folk in
their infinite wisdom are using the same names for incompatible files,
that's going to have to change; simplest way is to have the default path
be different for a latex2e binary than a latex209 binary, but in any
case, still search the entire tree afterwards: that way, it still
doesn't matter where you put the common files.
The problem with having a directory for them is that there is at least
one file (btxmac.tex) that works with amstex and plain, but doesn't work
with latex. And there are files (texnames.sty) that work with
all three. And I bet there are files (paths.sty?) that work with plain
and latex, but not amstex. But in any case, I think this won't matter
too much, since there are only a few files (or am I wrong here?) that
work even with just plain and latex.
To end on an irrelevancy:
vendors
Hey, I'm not a ``vendor'', I don't vend anything :-)
I'm not sure what I am (in any sense, but never mind...) ``supplier'', maybe.
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 07:05:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 1994 08:05:32 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405191205.IAA24711@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405191006.AA12415@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 19 May 1994 at 06:06:27, K. Berry wrote:
> Getting back to the Theoretically Correct Thing To Do, I am not at all
> prepared to admit that dpi300/cmr10.pk is theoretically better than
> cmr10.300pk. (In fact, I think it's worse.) Thus, I do not want to
> change the Unix defaults just because of DOS (or TDS) limitations,
> though I am ready to be swayed by a persuasive argument ... The default
> in mf.web is cmr10.300pk, another factor to take into consideration.
>
> [...]
>
> So, what to do? I don't know. If you put non-ISO-conforming files on a
> CD ROM does that screw up the whole CD for DOSish systems, or just the
> directories with the bad files? If the latter, you could have the files
> both ways.
I don't think you can put non-ISO conforming files on an ISO 9660 disk. Well,
maybe with an extension like Rock Ridge, but I've asked around here about that
(ORA used it for another CD) and it was an endless source of trouble. Most
UNIX kernels needed to be recompiled to recognize it, so installation was
highly non-trivial.
Speaking of practicalities again, the fonts are so large, particularly at high
resolutions, that I fear we cannot expect to put the fonts on the disk in two
different layouts.
> Other comments:
>
> 1) Alan suggests that there's no point in glyphs/. I agree. This was in an
> early version of the Pierre/Karl hierarchy, but then we couldn't see any
> time you might want to search along a hypothetical ``TEXGLYPHS'' path.
> So we tossed it. Save a directory level today.
/glyphs/ is out. (I'll post a revised proposal later today)
> [...]
> I think the name of the root of the tree is not something that should be
> standardized. For example, suppose a CD was cut for, oh, Solaris, with
> precompiled binaries on it. Its top-level would look like:
> [...]
The advantage to a standard root is that it reduces the likelyhood that
each vendor will put the input files under their own implementation-specific
directory. I envision Y&Y using /yytex/inputs as their root, emTeX using
/emtex/texinput as it's root, etc. The point of having an implementation
independent TDS is to make these files shareable.
How about saying that we recommend /texmf but that the choice of root is
ultimately left to the installer (with an explanation of why it shouldn't
fall under the implementation hierarchy)?
> 3)
> >>> Compromise: Since recursive subdirectory searching may be slow
> in coming, the following alternate form will be provided on the
> CD (IN ADDITION TO
>
> Will there be enough space on a CD to provide duplicate forms of many
> files? (Assuming you can't use (the non-ISO) hard links.)
Probably yes for the macros and sources. Probably no for fonts.
> 4) About files that work under different formats: this is hard. I
By seperating out files into different /<package>/ directories, we give
folks the opportunity to specify in what order to look. I think that as
long as the primary package comes first, it'll probably be all right.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 11:44:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 94 11:40:08 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405191040.AA19022@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
Karl> However, since the latex folk in their infinite wisdom are using
the same names for incompatible files, that's going to have to change;
simplest way is to have the default path be different for a latex2e
binary than a latex209 binary,
But having a new article.sty with the same name as the old one is no
different from any other software that gets updated. Presumably this
wouldn't be a problem on the CD which should surely just have a `latex'
hierarchy. Individual sites often run old versions of software in
parallel, but that doesnt mean the archives, or new distributions have
to.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 11:44:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 1994 12:44:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405191644.AA15583@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
Berry names, the <source>/ isnt needed either, since Berry promises
unique names (though i bet all the MF fonts are not done yet)
Hey, it's not *my* place to change the names of all the Metafont fonts
in the world. As a practical matter, it's certainly impossible to change
the names of the cm*, eu*, etc. fonts. I did actually make names in my
scheme for them (e.g., cm.txt), but I never expected them to get used.
Needing the <source>/<typeface> has nothing to do with unique names, as
I said in my last message. The actual filenames have to be unique in the
end, regardless of how many directories they are buried in.
lets just consider that a moment. how does the user of web2c TeX
specify that fonts/foo/ptm/tfm is needed, but not fonts/tfm. does
Why would you want to specify that? Heck, if all the TFM's are in a flat
directory (fonts/tfm/*.tfm), you might as well search that directory and
forget the subdirectory searching, even if your implementation provides it.
TEXFONTS=fonts//tfm *avoid* the fonts/tfm directory? I am not sure.
In versions of kpathsea up to 1.something (8?), there was a bug such
that the directory fonts/tfm would not get searched given a path of
fonts//tfm. This is fixed in the current distribution.
We are getting away from the focus on TDS.
There is definitely a tension between the practicalities of the ORA CD
(or anyone else's CD, for that matter), and the theory of the TDS.
In theory, I sense a consensus that the stuff should be organized in one
hierarchical way or another, without flat directories.
In practice, I don't think ORA wants to cut a CD that many existing TeX
implementations can't use. Hence flat directories will exist.
The product of this TWG is a proposal for a directory structure, with
hints for implementors and CD-cutters, right? I think we've reached some
kind of agreement on the fonts and macros. Norm, want to start us off
with something for the rest of the TeX files?
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 12:26:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 1994 12:26:28 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097EA9A.C1ECE4E0.127@SHSU.edu>
Subject: Re: Welcome to TWG-TDS
On Thu, 19 May 1994 06:06:27 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> I think there is only one big problem here: cmr10.300pk vs.
> dpi300/cmr10.pk. Yes, ISO restrict us to the latter. That means that
> kpathsea programs (which is to say, web2c) won't work without changing one
> definition (in kpathsea/tex-glyphs.c). The true dvips/xdvi would also
> require changes (in the default definition of their %-style paths). I'm
> not sure what other Unix (and maybe VMS? And any other long-name operating
> system)-world drivers are in common use, but I bet they too would need
> changes to the sources that come off the net. I predict that will be an
> endless source of trouble.
>
> Getting back to the Theoretically Correct Thing To Do, I am not at all
> prepared to admit that dpi300/cmr10.pk is theoretically better than
> cmr10.300pk. (In fact, I think it's worse.) Thus, I do not want to change
> the Unix defaults just because of DOS (or TDS) limitations, though I am
> ready to be swayed by a persuasive argument ... The default in mf.web is
> cmr10.300pk, another factor to take into consideration.
I completely respect Karl's sentiments on this, but please let me offer a
few irreverent comments here. One of the problems we have on VMS is that
we can run programs using the fonts with the "original" lump-in-all-in-one-
place-then-use-a-longer-extension-to-differentiate approach, or we can wait
until someone makes a decent VMS port using the equivalent of the
dpi300/cmr10.pk approach (actually, every VMS port I've seen drops the
"dpi" part altogether). Why, you might ask, would a site wait for a port
using the non-standard approach -- which is what most VMS sites do, to the
best of my knowledge? With VMS, it's because of the size limits associated
with the RMS-indexed directory files. Putting everything together in one
directory with dpi in the extension, you can easily get directory files in
excess of 128 blocks. With more powerful VMS machines, the reading problem
is less apparent, but being able to use disk caching is a real benefit.
For our use, it's not the DOS limitations for file names which gets in the
way (although it appears VMS uses DOS-like file names); instead, it's a
very real performance issue. DOS has to do it that way, VMS tends to
prefer to do it that way.
The fact that this TWG has been established does not mean that the
standards *have* to be changed from what they are now. Instead, it means
that a chance exists to review how things are done and make recommendations
based on those insights. My guess is that these recommendations can and
will have a long-term impact on future developments in a number of venues.
To say "that's the way it was originally conceived" and leave it at that is
not how I view this, if it can be demonstrated that, for a greater good,
changes in a few things might be the most fortuitous long-run solution. If
a set of recommendations can be propagated, my guess is that with a little
work by the developers of different utilities, programs, and interfaces
(including Karl!), the recommendations can be met. As it is right now, as
far as getting the latest greatest TeX-related programs, they have become
pretty Unix-specific until a common port to another hierarchy is developed
somewhere by someone else.
> 2) I invented ``texmf'' (to pick up on Erik's question) because it was the
> installation directory in /usr/local/lib. I didn't want to use ``tex''
> because (1) most Unix sites were already using /usr/local/lib/tex (that was
> a path in the previous defaults), and (2) it includes not just TeX-proper
> stuff.
Also, merely in terms of maintenance, having all TeX stuff lumped together
is pretty nice.
> I think the name of the root of the tree is not something that should be
> standardized.
I quite agree here -- each OS should exploit whatever it can insofar as the
root location. What I would hope we could get, though, is some
consistency once we're past the root level -- establish a common mounting
point, I guess.
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 12:36:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 May 94 15:25:28 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405191525.AA13130@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405171928.PAA25048@ruby.ora.com> <199405181954.PAA12550@ruby.ora.com> <9405181446.AA21660@ftp.tex.ac.uk>
>
> The point of /source/ is to easily distinguish one vendor from another.
> I guess we don't need it, but I think many users will be much more
> comfortable with an /adobe/ directory and /public/ directory and
> a /bitstream/ directory, etc.
>
> Is there a good argument against it?
only if we get anywhere near the limit of 8 descents. ok, i agree with
you. leave it.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 May 1994 17:46:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 19 May 1994 18:44:29 -0400
Message-ID: <199405192244.SAA13036@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: ISO9660 compliant files
Reply-To: TWG-TDS@SHSU.edu
Quick check:
Over all of CTAN, there are 20920 filenames (discounting directory
names) that are compliant and 10080 filenames which are not.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 May 1994 07:44:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 May 1994 08:45:05 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405201245.IAA14274@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Proposal 0.3
Reply-To: TWG-TDS@SHSU.edu
Here's another draft of my proposal. It integrates the discussion we've
had about macro and font directories and includes my first pass at the
rest of the directories. Note: I've given the rest much less thought so
it may not be as clean. ;-)
A PROPOSED TEX DIRECTORY STRUCTURE
Norman Walsh Version 0.3
O'Reilly and Associates 20 May 94
90 Sherman Street
Cambridge, MA 02140
norm@ora.com
(617) 354-5800
------------------------------------------------------------------------------
This is the abbreviated proposal. I removed a lot of explanatory text and
all references to CD-ROMs. I think that was distracting. Let's keep it in
mind but concentrate on the TDS.
------------------------------------------------------------------------------
MACROS
>>> Proposal: Macro files should be stored in a directory structure with
the following form:
/<root>/tex/<format>/<package>/<files>
The suggested value for <root> is "texmf". For example, C:\TEXMF on
PC systems and /usr/local/lib/texmf on Unix systems.
format is "plain", "latex", "latex2e", etc. This makes it easy to
limit subdirectory searching to only those input files that might be
used by the format in question.
package is the name of the package, or primary style file. For example,
"verbatim" or "changebar".
------------------------------------------------------------------------------
FONTS
>>> Proposal: Fonts should be stored in a directory structure like the
following:
For MF fonts:
/<root>/fonts/<source>/<typeface>/src
/<root>/fonts/<source>/<typeface>/tfm
/<root>/fonts/<source>/<typeface>/vf
/<root>/fonts/<source>/<typeface>/vpl
/<root>/fonts/<source>/<typeface>/pk/<mode>/<dpi>/<files>
For PS fonts:
/<root>/fonts/<source>/<typeface>/afm
/<root>/fonts/<source>/<typeface>/tfm
/<root>/fonts/<source>/<typeface>/vf
/<root>/fonts/<source>/<typeface>/vpl
/<root>/fonts/<source>/<typeface>/type1/<files>
/<root>/fonts/<source>/<typeface>/pk/<dpi>/<files>
Using /type1/ will help reduce the confusion about the differences
between PFA and PFB files.
This does not perfectly reflect the common situation on most systems
that have long filenames. On those systems, .../pk/<mode>/file.<dpi>pk
is more common.
Nevertheless, I think that the TDS should depreciate the use of long
filenames. Some tools will have to be adapted for this scheme, but
no amount of adaptation will ever make the long name scheme work on
file systems that don't support it. In addition, George has argued
that VMS users might prefer this scheme (even though long filenames
are possible).
------------------------------------------------------------------------------
BIBLIOGRAPHY SUPPORT
/<root>/bibtex/bib/<database>
/<root>/bibtex/bst/<package>/<files>
Where <package> is a real package (like economic or abstyles) or
"contrib" or "standard".
/<root>/tib/... I'm not sure what's appropriate here...
------------------------------------------------------------------------------
GRAPHICS
System-independent packages belong under the macros tree
(e.g. /<root>/tex/latex/mfpic)
------------------------------------------------------------------------------
INFO
This is the documentation tree. Contains "help" and "info" from CTAN,
for example.
------------------------------------------------------------------------------
INDEXING
/<root>/tex/indexing/<package>
Basically the indexing stuff from CTAN.
------------------------------------------------------------------------------
LANGUAGE
/<root>/tex/language/<package>
Basically the language stuff from CTAN.
------------------------------------------------------------------------------
SUPPORT
/<root>/support/<package>
Basically the language stuff from CTAN (for both TeX and MF?).
------------------------------------------------------------------------------
USERGRPS
/<root>/usergrps/<group>
------------------------------------------------------------------------------
EOF
================================================================================
From owner-twg-tds@shsu.edu Sat, 21 May 1994 23:56:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 21 May 94 15:19:32 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405211519.AA26391@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: ISO9660 compliant files
References: <199405192244.SAA13036@jasper.ora.com>
Norman Walsh writes:
>
> Over all of CTAN, there are 20920 filenames (discounting directory
> names) that are compliant and 10080 filenames which are not.
>
hey, cheer us up why dont you :-}
can you rerun the check just on fonts and macros? we dont care about
systems, tools or support for this purpose, and information files
could/should be renamed anyway
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 21 May 1994 23:59:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 21 May 94 15:46:57 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405211546.AA26506@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <0097EA9A.C1ECE4E0.127@SHSU.edu>
i think that George's argument *is* important, about limits on the
number of files in a directory. its a powerful reason for
subdirectories of fonts. the price of conformance is pretty small, for
the Unix person, if Karl would be willing to change web2c/kpathsea a
little in its next version.
apropos of which, I was vaguely hoping that if we come up with a nice
proposal from this group that Karl might consider `validating' it with
a new web2c release in the summer, since many people regard that as
canonical. so far the changes are trivial
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 21 May 1994 23:59:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 21 May 94 15:41:49 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405211541.AA26483@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405191006.AA12415@terminus.cs.umb.edu> <9405191040.AA19022@r8d.cs.man.ac.uk>
>
> But having a new article.sty with the same name as the old one is no
> different from any other software that gets updated. Presumably this
> wouldn't be a problem on the CD which should surely just have a `latex'
> hierarchy. Individual sites often run old versions of software in
> parallel, but that doesnt mean the archives, or new distributions have
> to.
its taking quite a big step to say that a 1994 CD will *only* have
LaTeX2e on as `the latex'. anyway, it doesnt matter having the old one
as latex209, since we need different trees for different formats
anyway.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 00:14:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 21 May 1994 10:57:22 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405211457.AA16222@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
The suggested value for <root> is "texmf". For example, C:\TEXMF on
PC systems and /usr/local/lib/texmf on Unix systems.
I agree with `texmf' if the installation is like the default web2c:
/usr/local/bin, /usr/local/man, /usr/local/lib/texmf.
But I would recommend `lib' in the other common installation case, where
TeX is its own tree, like X: /usr/tex/bin, /usr/tex/man, /usr/tex/lib.
format is "plain", "latex", "latex2e", etc. This makes it easy to
limit subdirectory searching to only those input files that might be
used by the format in question.
`latex209' instead of `latex', just so all the latex versions are
treated equally? Also, there is no mention of what to do with the basic
files for that <format>. I suggest they go in a subdirectory `base',
which is what we decided for CTAN long ago (has that changed?).
package is the name of the package, or primary style file. For example,
"verbatim" or "changebar".
Didn't bring this up before, but what about singular-file distributions?
I don't think there are very many such, but they shouldn't all get put
in their own directories. I'm thinking of texinfo.tex, guessing that
gkpmac.tex, picmac.tex, mftmac.tex, testfont.tex, etc., will go into
plain/base.
/<root>/fonts/<source>/<typeface>/pk/<mode>/<dpi>/<files>
1) Doesn't <dpi> have to be `dpi<dpi>', e.g., dpi300, for the sake of
systems that don't allow numeric directory names? Or are there none such?
2) Sigh. I hate to introduce another directory level, especially since
in practice the vast majority of fonts actually used in practice are
magstep0, and hence most files under cx will be in dpi300, most files
under ljfour will be in dpi600, etc.
We could drop the pk, and bring the modes up to being siblings
with type1/ and tfm/ and the rest, since gf's aren't used in
practice. That would lead to paths like
.../texmf/fonts/public/cm/cx/dpi300/cmr10.pk
Nah, never mind, that doesn't look so great.
Nevertheless, I think that the TDS should depreciate the use of long
filenames. Some tools will have to be adapted for this scheme, but
My question about this is, what should Metafont do? It seems totally
unintuitive to me for mf (under Unix) to create a subdirectory `dpi300'
in the cwd for its output instead of creating cmr10.300pk. What do DOS
mf's do?
I think the TDS should not deprecate (or depreciate :-) long filenames
for use on a particular systems, just for supposed-to-be portable
distributions. We should recommend implementations find both
dpi300/cmr10.pk and cmr10.300pk, not just one or the other.
see, owing to the 8.3 problem, why it would be needed. I think we (Karl,
could conform to it. It requires a little more attention to how
where MakeTeXPK puts things, but since the dpi number is generated repel-
for use in MakeTeXPK that is doable. Extremely tiresome, but doable. lent
I find the potential proliferation of fonts with identical names do you
( 300/cmr10.pk beside 600/cmr10pk beside 1270/cmr10.pk ) find
truly unnerving. They had better all be made up with this ??)
Gee, Pierre, I've never seen a marginal note in email before! I'm
impressed. Anyway, I don't mind making kpathsea accept either form, if I
can just figure out a decent way to do it.
I don't think MakeTeXPK is a problem (I must be missing something :-).
It just creates dpiNNN in the tmp dir (or the real dir) if it doesn't
exist.
/<root>/bibtex/bst/<package>/<files>
Where <package> is a real package (like economic or abstyles) or
We're gonna do subdirectory searching on the bst files, huh? Sure, I
guess. I didn't know there *were* packages of bst files.
"contrib" or "standard".
Let's use `base', not `standard'. It's shorter, and `standard' means a
lot of different (yet standard :-) things.
INFO
This is the documentation tree. Contains "help" and "info" from CTAN,
for example.
Why not keep the help/ vs. info/ distinction? I think it is a useful one.
INDEXING
/<root>/tex/indexing/<package>
Basically the indexing stuff from CTAN.
Isn't this sources? You must mean the additional style files. I would
just stick these in tex/latex/makeindex or whatever they work with; why
have a separate indexing/ tree to look in?
LANGUAGE
/<root>/tex/language/<package>
Doesn't this introduce another whole place to search, and to potentially
have to specify in the paths? Can the stuff be put under latex/ or
plain/ or whatever?
SUPPORT
/<root>/support/<package>
Basically the language stuff from CTAN (for both TeX and MF?).
You mean `support', not `language' :-)
Anyway, this all looks like sources to me. I don't think that should go
in texmf/ aka lib/. Isn't it cleaner to keep the stuff which is searched
for at runtime separate from all the sources? That's the assumption I've
been working on. Keeping these separate is a common need. (Sources are
in one partition, installed files in another.)
Pierre> I suppose that mf could be in /<root>/support/mf
but it isn't really a package.
I guess I'm arguing against support/ entirely. I entirely agree with <root>/mf.
(Gee, what a surprise :-)
USERGRPS
/<root>/usergrps/<group>
What is this for? I'm missing it.
No matter what it is, though :-), I think I'm gonna argue that it should go
in a sibling to texmf/, not under it, as above.
Pierre> ( The need, in 1994, for such hacks increases my conviction
that Intel architecture and the software built on it is
one of the great technological disasters of this century.
A marketing triumph, but a technological disaster.)
Off the subject here, but I have two responses: 1) I think it's even
more amazing that Apple and Microsoft have yet to design a true
multi-processing, multi-user operating system, 15-20 years after Unix
and VMS (not to mention all their predecessors). (NT doesn't allow for
multiple users (in other words, I can't telnet/rlogin into an NT
machine), I'm given to understand, though I may be wrong.)
2) A friend was at a conference with Bill Gates once, and Gates said
something along the lines of ``I'm not interested in designing a good
operating system, I'm interested in making money ... I let everyone else
do all the research, then come along, build a cheap imitation, and
market the hell of it''.
Talk about summing up everything wrong with the way computers &
programming are going ...
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 11:47:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 22 May 94 16:41:40 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405221641.AA12481@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405211457.AA16222@terminus.cs.umb.edu>
"K. Berry" writes:
> The suggested value for <root> is "texmf". For example, C:\TEXMF on
> PC systems and /usr/local/lib/texmf on Unix systems.
>
> I agree with `texmf' if the installation is like the default web2c:
> /usr/local/bin, /usr/local/man, /usr/local/lib/texmf.
>
> But I would recommend `lib' in the other common installation case, where
> TeX is its own tree, like X: /usr/tex/bin, /usr/tex/man, /usr/tex/lib.
lets be positive here. lets *recommend* /usr/local/lib/texmf
explicitly, and simply point out that /usr/tex is another viable
alternative, but deprecated.
> `latex209' instead of `latex', just so all the latex versions are
> treated equally? Also, there is no mention of what to do with the basic
> files for that <format>. I suggest they go in a subdirectory `base',
> which is what we decided for CTAN long ago (has that changed?).
no, it hasnt. latex2e is that way, and i think its a good convention.
> package is the name of the package, or primary style file. For example,
> "verbatim" or "changebar".
>
> Didn't bring this up before, but what about singular-file distributions?
> I don't think there are very many such, but they shouldn't all get put
> in their own directories. I'm thinking of texinfo.tex, guessing that
> gkpmac.tex, picmac.tex, mftmac.tex, testfont.tex, etc., will go into
> plain/base.
unless anyone has a reason against it, i'd again follow ctan with
`misc' - its ugly and silly but we use it. or 'etc'....
> /<root>/fonts/<source>/<typeface>/pk/<mode>/<dpi>/<files>
>
> 1) Doesn't <dpi> have to be `dpi<dpi>', e.g., dpi300, for the sake of
> systems that don't allow numeric directory names? Or are there none such?
i cant think of one. i'd say keep <dpi>, its less confusing (who knows
or cares what `dpi' means?')
> My question about this is, what should Metafont do? It seems totally
> unintuitive to me for mf (under Unix) to create a subdirectory `dpi300'
> in the cwd for its output instead of creating cmr10.300pk. What do DOS
> mf's do?
make a mess..... try to write cmr10.1270pk and end up with cmr10.127,
as i recall. maybe they are better now.
you have a point, though.
> distributions. We should recommend implementations find both
> dpi300/cmr10.pk and cmr10.300pk, not just one or the other.
i cant see any argument against that.
> LANGUAGE
>
> /<root>/tex/language/<package>
>
> Doesn't this introduce another whole place to search, and to potentially
> have to specify in the paths? Can the stuff be put under latex/ or
> plain/ or whatever?
yes, but which? where do the hyphenation patterns go?
> Pierre> ( The need, in 1994, for such hacks increases my conviction
> that Intel architecture and the software built on it is
> one of the great technological disasters of this century.
> A marketing triumph, but a technological disaster.)
sounds like you are talking about the motor car to me
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 11:58:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 22 May 94 16:53:11 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405221653.AA12528@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Proposal 0.3
References: <199405201245.IAA14274@ruby.ora.com>
>
> Nevertheless, I think that the TDS should depreciate the use of long
> filenames. Some tools will have to be adapted for this scheme, but
lets be quite clear that its not just long names that are the problem,
but the number of files per directory. thats why I dont use
<name>.<dpi>pk, because it creates the umanageable monolithic messes,
which cause positive problems for VMS
apart from the little messes like info, help, support etc (which I
dont think the TDS per se should mention), it seems to me that the
real issue is how to handle the language stuff. where do things like Pierre's
Yet Another Greek Font go? they probably have font files, hyphenation
patterns, plain TeX macros, and LaTeX packages. bleeagh. having them
in their own tree does make for nasty long paths if you use eg French,
German and Greek often (which someone like, say, Pierre, preparing
critical texts might do every day). a *production* system ought to
have YAGF as:
<root>/texmf/fonts/yagf/tfm etc
<root>/texmf/tex/latex/yagf/yagf.sty
<root>/texmf/tex/plain/yagf/yagf.tex
(unless its supported by Babel) while it is correct on CTAN to bundle
it under language/yagf. how about hyphenation? should we have:
<root>/texmf/tex/hyphen/yagf.hyp
since only one TeX (initex) will ever have this directory on its path?
I think the final TDS document should make it clear that we actively
propose the use of scripts/batch files with environment variables set
differently, so that initex and latex see different paths
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 14:12:50 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 22 May 1994 12:13:19 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405221913.MAA27116@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Proposal 0.3
Before we get too much further, I need to be reminded what
the less obvious limitations in file systems are, notably
the number of levels of directory that are possible
in the systems we are looking at. Unix is almost dangerously
free about that, though I have run into limitations in tar.
But does DOS have a limit in the number of levels it can search?
I was under the impression that the commonest CD-ROM file
system has a very severe limit on the depth to which
directories can be named.
Even though it may be blessed by tradition, /usr/local/ may not be
the best way to look at the future organization of Unix systems.
There is not too much that impresses me yet about Solaris-2.3 after
my recent experience, but I am somewhat impressed by the value of
a truly read-only /usr. Solaris seems to get very close to that
or maybe it even achieves it.
I just had the experience of actually making use of a shadow
root partition on a secondary disk, and it would have been even
simpler if I could have mounted /usr from a CD-ROM. But the CD-ROM
is very unlikely to include a mount point for /usr/local, and I
don't even know whether it is possible to mount a disk partition
on a mount point defined on a CD-ROM. The opportunities to try
this sort of thing out are limited.
I don't want to suggest changing the /usr/local/* practice now,
only to suggest that we may be forced to reconsider /usr/local
in the future
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 14:29:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 22 May 94 19:23:27 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405221923.AA13148@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Proposal 0.3
References: <199405221913.MAA27116@june.cs.washington.edu> <9405221653.AA12528@ftp.tex.ac.uk>
> But does DOS have a limit in the number of levels it can search?
i havent met one
> I was under the impression that the commonest CD-ROM file
> system has a very severe limit on the depth to which
> directories can be named.
yes, 8 levels
> simpler if I could have mounted /usr from a CD-ROM. But the CD-ROM
> is very unlikely to include a mount point for /usr/local, and I
> don't even know whether it is possible to mount a disk partition
> on a mount point defined on a CD-ROM. The opportunities to try
> this sort of thing out are limited.
>
> I don't want to suggest changing the /usr/local/* practice now,
> only to suggest that we may be forced to reconsider /usr/local
> in the future
i had assumed that the CD would start at /texmf, as opposed to the TDS
report which would recommend /usr/local/lib/texmf or whatever. but
in practice one would mount the CD as /texmf wherever you wanted. to
the DOS user it would like like eg E:\TEXMF.
unless i mistake your point?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 May 1994 16:58:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 22 May 1994 17:59:09 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405222159.RAA12084@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
References: <199405211457.AA16222@terminus.cs.umb.edu> <9405221641.AA12481@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 May 1994 at 16:41:40, Sebastian Rahtz wrote:
> lets be positive here. lets *recommend* /usr/local/lib/texmf
> explicitly, and simply point out that /usr/tex is another viable
> alternative, but deprecated.
Sounds reasonable.
>
> > `latex209' instead of `latex', just so all the latex versions are
> > treated equally? Also, there is no mention of what to do with the basic
> > files for that <format>. I suggest they go in a subdirectory `base',
> > which is what we decided for CTAN long ago (has that changed?).
> no, it hasnt. latex2e is that way, and i think its a good convention.
Sounds good.
> unless anyone has a reason against it, i'd again follow ctan with
> `misc' - its ugly and silly but we use it. or 'etc'....
Yeah, misc, I think. /etc/ has a lot of wrong connotations ;-)
> > /<root>/fonts/<source>/<typeface>/pk/<mode>/<dpi>/<files>
> >
> > 1) Doesn't <dpi> have to be `dpi<dpi>', e.g., dpi300, for the sake of
> > systems that don't allow numeric directory names? Or are there none such?
> i cant think of one. i'd say keep <dpi>, its less confusing (who knows
> or cares what `dpi' means?')
Hmm. I have to admit that I had in mind /300dpi/ myself, but I'm willing
to drop 'dpi' if that seems best...
> > My question about this is, what should Metafont do? It seems totally
> > unintuitive to me for mf (under Unix) to create a subdirectory `dpi300'
> > in the cwd for its output instead of creating cmr10.300pk. What do DOS
> > mf's do?
> make a mess..... try to write cmr10.1270pk and end up with cmr10.127,
> as i recall. maybe they are better now.
It's still that bad, as far as I know. We'll probably never get them
all to do it right. The trend seems to be away from MF anyway. As long
as "MakeTeXPK" (or whatever it's called) puts it in the right place.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 06:56:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 07:56:28 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405231156.HAA27922@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Slightly better news ;-)
Reply-To: TWG-TDS@SHSU.edu
In the macros and fonts directory trees, there are 10161 ISO-9660 compliant
and 4194 non-compliant files.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 07:39:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 08:39:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231239.AA04437@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: agreements and disagreements
Here are the things we seem to agree on:
1) `base' and `misc' a la ctan.
2) <dpi> (e.g., `300') under .../fonts/pk. (ISO-9660 allows purely
numeric directory names, huh?)
3) recommending implementors support `300/cmr10.pk';
also that they support subdirectory searching to at least ?? levels.
4) The TDS doesn't need to mention info/help/support/non-library files.
And here's what I'm still having problems with:
1)
lets be positive here. lets *recommend* /usr/local/lib/texmf
explicitly, and simply point out that /usr/tex is another viable
alternative, but deprecated.
I don't think it's right to deprecate /usr/tex. There are valid reasons
why sites may want to do that.
I accept the argument that even in a /usr/tex tree the library files
should be kept in directory named `texmf' instead of `lib', for the sake
of consistency; I just don't think that consistency is worth the
unnaturalness of using `texmf' (so the macros are in
/usr/tex/texmf/tex/...) instead of `lib'.
I think the TDS should mention and allow both alternatives, not
deprecate one at the expense of the other.
Pierre's point about /usr/local maybe not existing is a good one, but
the *idea* of /usr/local is independent of /usr/local itself. If you
know what I mean. If /usr/local is impossible, I would still have
/u/local or /home/local or *something*.
2)
I think the final TDS document should make it clear that we actively
propose the use of scripts/batch files with environment variables set
differently, so that initex and latex see different paths
I'm not sure I want to propose such a thing. I'd like to think that
`tex' can still be TeX, not some script that has to set a million
envvars. Anyway, users should be able to set envvars themselves, not
have some script usurp them.
Regardless, I think the TDS should say what The Right Structure is, and
not necessarily suggest how to achieve that. I think config files are a
better approach than scripts. (Of course I have to implement them first :-)
3)
lets be quite clear that its not just long names that are the problem,
but the number of files per directory. thats why I dont use
<name>.<dpi>pk, because it creates the umanageable monolithic messes,
If you separate fonts by mode (which you have to do), I don't think the
extra <dpi> subdirectory buys you much, unless you use lots of
magnifications (does anyone, any more?).
Anyway, the only reasonable thing to do for Unix is to accept both
cmr10.300pk and 300/cmr10.pk. I always intended to do this for the next
release.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 07:39:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 08:39:45 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231239.AA04449@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: language support
critical texts might do every day). a *production* system ought to
have YAGF as:
<root>/texmf/fonts/yagf/tfm etc
fonts/public/yagf/tfm, please :-)
<root>/texmf/tex/latex/yagf/yagf.sty
<root>/texmf/tex/plain/yagf/yagf.tex
(unless its supported by Babel) while it is correct on CTAN to bundle
it under language/yagf. how about hyphenation? should we have:
<root>/texmf/tex/hyphen/yagf.hyp
since only one TeX (initex) will ever have this directory on its path?
I don't think it's much of a win to separate ini/vir paths. There are so
few files that are only used by ini that it won't hurt much to just put
them in with the TeX inputs.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 07:40:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 08:40:53 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231240.AA04459@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: duplicate msgs
Sigh. Accidentally sent a draft of one of my messages, as well
as the real thing. (The one that's Re: Welcome to ...) Sorry about that.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 07:41:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 08:39:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231239.AA04443@terminus.cs.umb.edu>
To: spqr@ftp.tex.ac.uk
CC: TWG-TDS@SHSU.edu
Subject: Re: Welcome to TWG-TDS
i think that George's argument *is* important, about limits on the
number of files in a directory. its a powerful reason for
subdirectories of fonts.
The current kpathsea defaults, with their zillions of subdirectories,
also limit the number of files in a directory. At least, compared to
having *all* the PK files in one single directory ... George, what do
VMS'ers do now?
Once you split things up according to mode, I don't think the dpiNNN
buys you much, as I said in my last msg.
apropos of which, I was vaguely hoping that if we come up with a nice
proposal from this group that Karl might consider `validating' it with
a new web2c release in the summer, since many people regard that as
canonical. so far the changes are trivial
I don't want to change things so that cmr10.300pk is no longer
recognized. I don't mind changing things so that both forms are
recognized. I always intended to do this for the next release. I don't
know when it'll be ready.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 07:59:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 09:00:24 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405231300.JAA01633@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405231239.AA04437@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 23 May 1994 at 08:39:43, K. Berry wrote:
> Here are the things we seem to agree on:
>
> 1) `base' and `misc' a la ctan.
>
> 2) <dpi> (e.g., `300') under .../fonts/pk. (ISO-9660 allows purely
> numeric directory names, huh?)
Sh*t. No. Names must begin with a letter. Damn. I guess we might as
well go with 'dpi300'.
> 3) recommending implementors support `300/cmr10.pk';
> also that they support subdirectory searching to at least ?? levels.
Why suggest a limit? I *hate* arbitrary limitations. If people don't
want subdir searching to take a long time, keep the tree shallow!
> 4) The TDS doesn't need to mention info/help/support/non-library files.
Doesn't _need_ to, but should it?
> And here's what I'm still having problems with:
>
> 1)
> lets be positive here. lets *recommend* /usr/local/lib/texmf
> explicitly, and simply point out that /usr/tex is another viable
> alternative, but deprecated.
>
> I don't think it's right to deprecate /usr/tex. There are valid reasons
> why sites may want to do that.
I'm inclined to word the recommendation something like this (does this help?):
TWG-TDS recommends that implementation-independent TeX files be rooted in
a subtree that begins with "texmf/". On most non-Unix systems, we expect
this tree to begin at the root directory (although that is by no means
necessary). On Unix systems, it has become conventional to place TeX
files under /usr/local/lib or /usr/tex/lib. We recommend that new
installations begin using the "texmf/" tree mounted in a convenient place
(/usr/texmf or /usr/local/texmf, for example), but recognize that many sites
will wish to continue using a different root.
> Regardless, I think the TDS should say what The Right Structure is, and
> not necessarily suggest how to achieve that. I think config files are a
> better approach than scripts. (Of course I have to implement them first :-)
I agree. We *can't* write scripts for everyone (or even most people) so
I don't think we should try. Nothing will piss people off more than a bunch
of "broken" scripts.
> Anyway, the only reasonable thing to do for Unix is to accept both
> cmr10.300pk and 300/cmr10.pk. I always intended to do this for the next
> release.
I like /300/ better, but we can't do that under ISO 9660 (here I go, dragging
the CD back into the mix :-(. Is /dpi300/ or /pk300/ or something, acceptable
to everyone?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 10:11:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 23 May 1994 11:11:21 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
To: TWG-TDS@SHSU.edu
Message-ID: <769705881.691264.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
karl says, following up on everyone else:
3) recommending implementors support `300/cmr10.pk';
...
If you separate fonts by mode (which you have to do), I don't think the
extra <dpi> subdirectory buys you much, unless you use lots of
magnifications (does anyone, any more?).
we do still use magnifications if the font isn't one that has
been generated in outline form. and then we *must* identify
the magnification. what then is proposed for, say, cmr10.329pk
or .360pk? (that's how we name the pk files we have on e-math,
which i notice are at shsu only in .zip form, so it's not obvious
that the extended names are lurking there in the area
.../fonts/ams/amsfonts/pk-files )
i am confused ...
-- bb
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 10:15:34 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q5bFq-00004SC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 23 May 94 15:45 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
> TWG-TDS recommends that implementation-independent TeX files be rooted in
> a subtree that begins with "texmf/".
If we're going to suggest a root name, why not just `tex'? A lot more
people know what TeX is than know what MF is, so using texmf is just
asking for confusion. And there's a lot of /local/tex's or
/usr/local/tex's or whatever out there...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 10:18:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 11:18:46 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405231518.LAA10518@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405231239.AA04437@terminus.cs.umb.edu> <769705881.691264.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 23 May 1994 at 11:11:21, bbeeton wrote:
> karl says, following up on everyone else:
>
> 3) recommending implementors support `300/cmr10.pk';
>
> ...
>
> If you separate fonts by mode (which you have to do), I don't think the
> extra <dpi> subdirectory buys you much, unless you use lots of
> magnifications (does anyone, any more?).
>
> we do still use magnifications if the font isn't one that has
> been generated in outline form. and then we *must* identify
> the magnification. what then is proposed for, say, cmr10.329pk
> or .360pk? (that's how we name the pk files we have on e-math,
> which i notice are at shsu only in .zip form, so it's not obvious
> that the extended names are lurking there in the area
> .../fonts/ams/amsfonts/pk-files )
The problem is that a name like "cmr10.329pk" is not valid under a system
running MS-DOS (and perhaps a few other OSes). Since we want the TDS to
apply across as many architectures as possible, I'm suggesting that we
use
/texmf/fonts/public/cm/pk/<mode>/dpi329/cmr10.pk
"dpi329/cmr10.pk" (or 329dpi) is what most MS-DOS drivers expect now anyway.
The name of the directory has to begin with a letter under ISO 9660 for
CD-ROMs, so we better start out with that.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 11:52:18 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q5dAE-00004SC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 23 May 94 17:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
> extra <dpi> subdirectory buys you much, unless you use lots of
> magnifications (does anyone, any more?).
Have a look in the .fd files which come with LaTeX, and you'll see
magnified fonts galore! So anyone = anyone who uses LaTeX.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 13:20:06 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405231808.AA29242@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 23 May 94 14:07:32 -0400
From: bob@microprograms.com
Re: path names.
In addition to the DOS restriction of 8.3 file names, it has a very
restricted environment space and an even more restricted path space.
While all the implementors could (?) overnight (ha!) rewrite their
versions to build support for long paths into TeX and the drivers, it
will be a long time before everyone who has a DOS version will upgrade,
although they will try to use the CD-ROM. Lesson: we must keep path
names reasonably short for DOS users, especially if they will be using
the path statement. I have had to use "attach" to solve the path
limitation with all the projects I keep on one machine. Otherwise I
would have to run a batch file every time I wanted to switch projects.
To answer Pierre's question (22 May)
I do not think there is a limit to the number of levels of directory
possible under DOS in a program that does the searching. Each directory
is just a special file. There may be a practical limit in terms of time and memory.
CD-ROMs, even the newer triple speed ones, are notoriously slow. On the
current Micrografx Designer CD-ROM, if I want something near the end, I
can get a cup of coffee (nuked, of course) while I'm waiting. Group 1,
on the other hand, did something intelligent (but I don't know what) so
you can get the zip+4 for any address in the US in just a couple of seconds.
Re: font names and directories.
Norm say "...most MS-DOS drivers expect now anyway." ArborText, for
both their Unix and DOS products, put the pk files under the base
resolution and mode (e.g. canon300 for write-black at 300 dpi) The
various magnifications were under that (e.g., dpi300, dpi 329, etc). We
have maintained the same organization since taking over the DOS
products. As a result, I have a second family (which I called wb1270)
which contains dpi1270, dpi1391, etc. for our second, high-resolution
printer. Does Norm mean in this case all 14 (2 printers times 7
magsteps) magsteps be at the same level? And, yes, we get calls from
customers for the various magsteps. Not everyone wants to switch to the
outline fonts.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 13:22:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 23 May 1994 11:23:07 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231823.LAA18678@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
dpi300 is better. pk is a parent of the range of dpi directories.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 13:31:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 23 May 1994 11:31:31 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231831.LAA19824@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Just to support barbara's observation, here is a directory list made
up entirely as a result of running MakeTeXPK on a: a woven WEB file,
b: three or four texinfo files, c: a couple of LaTeX doc files
No personal preferences are represented in this list, only the
demands of the above mentioned documentation packages.
Bodoni Lives!
2 ./ 9 cmmi6.600pk 15 cmsy10.657pk
1 ../ 10 cmmi7.600pk 17 cmsy10.720pk
21 cmb10.1037pk 12 cmmi8.600pk 21 cmsy10.864pk
12 cmb10.657pk 13 cmmi9.600pk 9 cmsy6.600pk
12 cmbx10.600pk 11 cmr10.600pk 10 cmsy7.600pk
13 cmbx10.657pk 12 cmr10.657pk 12 cmsy8.600pk
15 cmbx10.720pk 14 cmr10.720pk 30 cmti10.1037pk
18 cmbx10.864pk 17 cmr10.864pk 14 cmti10.600pk
27 cmbx12.1037pk 13 cmr12.600pk 16 cmti10.657pk
14 cmbx12.600pk 19 cmr17.600pk 19 cmti12.600pk
16 cmbx12.657pk 6 cmr5.600pk 21 cmti12.720pk
18 cmbx12.720pk 7 cmr6.600pk 12 cmti8.600pk
22 cmbx12.864pk 8 cmr7.600pk 14 cmti9.600pk
9 cmbx8.600pk 9 cmr8.600pk 17 cmtt10.1037pk
10 cmbx9.600pk 10 cmr9.600pk 9 cmtt10.600pk
14 cmbxsl10.600pk 14 cmsl10.600pk 10 cmtt10.657pk
11 cmcsc10.540pk 14 cmsl10.657pk 11 cmtt10.720pk
12 cmcsc10.600pk 21 cmsl10.864pk 13 cmtt10.864pk
13 cmcsc10.657pk 17 cmsl12.657pk 11 cmtt12.600pk
14 cmex10.600pk 19 cmsl12.720pk 12 cmtt12.657pk
15 cmmi10.600pk 12 cmsl9.600pk 14 cmtt12.720pk
16 cmmi10.657pk 11 cmss10.657pk 16 cmtt12.864pk
18 cmmi12.600pk 9 cmss9.600pk 7 cmtt8.600pk
21 cmmi12.720pk 14 cmsy10.600pk 8 cmtt9.600pk
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 13:37:19 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 23 May 1994 11:37:47 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231837.LAA20537@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
texmf/ represents something quite different from tex/
It has certainly not been the habit in the past to
put things like METAFONT source in a tex/ directory.
Incidentally, I would not like to make use of the
etc/ directory name in the texmf tree. etc/ has
acquired a very specific flavor over the years,
and even though its more general use is, in a way,
sanctioned by GNU practice, I think it is best left
out of the texmf tree.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 14:34:16 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 23 May 1994 12:34:39 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405231934.MAA29198@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Here is a cautionary note
texmf/fonts/public/cm/pk/ljfour/dpi657/cmr10.{657}pk
already descends through 7 directory names.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 16:18:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 16:18:42 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097EDDF.DCDEFC00.305@SHSU.edu>
Subject: Re: Welcome to TWG-TDS
> i think that George's argument *is* important, about limits on the
> number of files in a directory. its a powerful reason for
> subdirectories of fonts.
>
> The current kpathsea defaults, with their zillions of subdirectories, also
> limit the number of files in a directory. At least, compared to having
> *all* the PK files in one single directory ... George, what do VMS'ers do
> now?
What we do here (and I doubt we are unique) is to have the 300 dpi fonts
(which we use in most applications) rooted somewhere:
SYS1:[TEX.TEX_FONTS.FONTS]
in this directory, we have all the .TFM files and directories for all of
the "magstep" variations (I honestly don't know the technical term for
this) of fonts and all .VF files in a parallel structure, so that
crm10.300pk is in SYS1:[TEX.TEX_FONTS.FONTS.300]CMR10.PK. In our case, the
magnifications are:
100.DIR;1 1075.DIR;1 121.DIR;1 1290.DIR;1
145.DIR;1 1548.DIR;1 174.DIR;1 180.DIR;1
208.DIR;1 210.DIR;1 225.DIR;1 240.DIR;1
250.DIR;1 263.DIR;1 270.DIR;1 274.DIR;1
300.DIR;1 329.DIR;1 360.DIR;1 432.DIR;1
518.DIR;1 537.DIR;1 597.DIR;1 622.DIR;1
645.DIR;1 717.DIR;1 746.DIR;1 774.DIR;1
896.DIR;1 (in VMStalk, the .DIR extension goes away in the
directory spec; 100.DIR is SYS1:[TEX.TEX_FONTS.FONTS.100])
The directories are essentially parallel to one another beyond this point
with *.PK in them. The .VF files reside in SYS1:[TEX.TEX_FONTS.VF] and
the MetaFont sources reside in SYS1:[TEX.TEX_FONTS.MF].
Out of local convention, we have all of the prebuilt 600 dpi files in a
parallel structure rooted at SYS1:[TEX.TEX_FONTS.LFONTS] ("laser fonts", I
guess) which is essentially the same structure. The .TFM files are all in
the top-level SYS1:[TEX.TEX_FONTS] directory so that they can be referred
to works in the same manner, regardless; we control what is used by the
print device with a local logical for TEX_RES -- if TEX_RES translates to
600, use [...LFONTS...]; else use [...FONTS...]).
Or did I answer your question??
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 16:27:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 16:27:22 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097EDE1.12B84600.120@SHSU.edu>
Subject: Re: agreements and disagreements
> > also that they support subdirectory searching to at least ?? levels.
>
> Why suggest a limit? I *hate* arbitrary limitations. If people don't want
> subdir searching to take a long time, keep the tree shallow!
Ummmm, VMS has a limit of 8-deep directories in a purely technical sense.
Doesn't mean we can't get around it (defining rooted, terminal, concealed
logicals -- kinda easy once you see it), but 8 deep is a technical limit if
we really get serious about it.
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 17:02:37 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 23 May 1994 15:02:41 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405232202.PAA17923@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
So now we have not one but two places where the 8 level limit
is in effect: ISO-9660 and VMS. The limit may be arbitrary
and it is, to say the least, an annoying irrelevance for
Unix systems, but it is there, and has to be recognize
if we want a generally useful file arrangement.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 May 1994 17:56:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 May 1994 17:56:00 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097EDED.749A2440.46@SHSU.edu>
Subject: Re: agreements and disagreements
On Mon, 23 May 94 14:07:32 -0400, Bob Harris <bob@microprograms.com>
posted:
> In addition to the DOS restriction of 8.3 file names, it has a very
> restricted environment space and an even more restricted path space. While
> all the implementors could (?) overnight (ha!) rewrite their versions to
> build support for long paths into TeX and the drivers, it will be a long
> time before everyone who has a DOS version will upgrade, although they will
> try to use the CD-ROM. Lesson: we must keep path names reasonably short
> for DOS users, especially if they will be using the path statement. I have
> had to use "attach" to solve the path limitation with all the projects I
> keep on one machine. Otherwise I would have to run a batch file every time
> I wanted to switch projects.
This is precisely why the TDS discussion is *Soooooooooo* important. I
think we all see that some level of real-world standardization or
portabilization, if you will, is now upon us given this media to work with.
Previously, while TeX was portable, the probability that a DOS user would
see a Unix, Mac, or VMS file in the context of a Unix, Mac, or VMS file was
slim whereas today, that probability is upon us and relatively high.
Theoretically possible since TeX is platform independent and portable, but
operationally impractical as Unix, Mac, or VMS files on any non-similar
system was asking for problems. Today, to gain economies of scale is
distribution and to reduce replication in production as well as structure,
DOS'sers seeing operational files as would Unixites while running a Mac
under VMS is exactly what we are outlining.
The lesson here is on two levels -- first level, short-term, I agree with
Bob: we have to recognize that many systems are not current
state-of-the-art and accept that users of the CD may not be running the
latest versions of the software. Second level, long-term, much more
important: how well the TDS is set up for true platform-independent
application and future extensibility along that goal may be one of the
central deciding factors in getting those upgrades, keeping people using
TeX, and getting people into using TeX (IMO, it is *THE* factor upon which
most TeX issues will be focused). The trade-off is to adequately satisfy
level one, but recognize that level two is what we are really dealing with
-- the long-term health of TeX.
--George
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 08:56:36 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405241347.AA27229@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
CC: bob@microprograms.com
Subject: Re: agreements and disagreements
Date: Tue, 24 May 94 09:45:15 -0400
From: bob@microprograms.com
Pierre observes:
texmf/fonts/public/cm/pk/ljfour/dpi657/cmr10.{657}pk
already descends through 7 directory names.
Hmmm. Do we really need the /pk level? Wouldn't
texmf/fonts/public/cm/ljfour/dpi657/cmr10.{657}pk
suffice? Also, is /public something UNIX users use and want? Since there is no
distinction between public and private in the MS-DOS world, that level
has no meaning.
Going back a way in this thread, Norm (I think) proposed putting the
tfm files under <source>/<typeface>. Don't most TeX implementations
expect the tfm files to be grouped together and not necessarily with
the fonts? The three versions I have loaded separate the tfms from the
rest. I know Abode puts the fonts (pfb) in the first subdirectory
(typically psfonts) and puts the afm and pfm files in subdirectories
(psfonts\afm and psfonts\pfm).
It is taking me a while to catch up with the rest of you.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 15:41:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 May 94 20:35:54 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405242035.AA05323@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405231239.AA04437@terminus.cs.umb.edu>
> I think the final TDS document should make it clear that we actively
> propose the use of scripts/batch files with environment variables set
> differently, so that initex and latex see different paths
>
> I'm not sure I want to propose such a thing. I'd like to think that
> `tex' can still be TeX, not some script that has to set a million
> envvars. Anyway, users should be able to set envvars themselves, not
> have some script usurp them.
its not easy to see how one supports latex2e vs latex209 without
scripts or variables, until you (for Unix) have config files. but yes,
i withdraw the suggestion it be formally stated
> If you separate fonts by mode (which you have to do), I don't think the
> extra <dpi> subdirectory buys you much, unless you use lots of
> magnifications (does anyone, any more?).
it depends on the fonts, doesn't it. assuming one uses Metafont fonts
(which i try not to :-}), one may not have any choice, unless one does a
Sauter for all font families, which is no fun
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 15:45:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 May 94 20:39:34 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405242039.AA05344@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405231300.JAA01633@ruby.ora.com> <m0q5bFq-00004SC@csrj.crn.cogs.susx.ac.uk>
Alan Jeffrey writes:
> > a subtree that begins with "texmf/".
>
> If we're going to suggest a root name, why not just `tex'? A lot more
> people know what TeX is than know what MF is, so using texmf is just
> asking for confusion. And there's a lot of /local/tex's or
> /usr/local/tex's or whatever out there...
no, no, please, lets make a clean start! one of the principles of this
discusison was to follow Berry/Mackay where possible, and texmf is
firmly embedded now.
sebasytian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 15:50:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 May 94 20:43:58 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405242043.AA05374@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <9405231808.AA29242@uu3.psi.com>
> although they will try to use the CD-ROM. Lesson: we must keep path
> names reasonably short for DOS users, especially if they will be using
> the path statement. I have had to use "attach" to solve the path
is
c:\texmf\fonts\public\cm\pk\canoncx\dpi300\foo.pk
a long name? I guess it is. but its within the 8 limit at least. I
would go back and remove the `public' level to help DOS out, since i
still think the arguments for it are weak.
> Norm say "...most MS-DOS drivers expect now anyway." ArborText, for
> both their Unix and DOS products, put the pk files under the base
> resolution and mode (e.g. canon300 for write-black at 300 dpi) The
> various magnifications were under that (e.g., dpi300, dpi 329, etc). We
> have maintained the same organization since taking over the DOS
sounds like we are proposing something you can live with quite easily
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 15:59:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 May 94 20:53:36 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405242053.AA05419@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405231934.MAA29198@june.cs.washington.edu> <9405241347.AA27229@uu3.psi.com>
> Hmmm. Do we really need the /pk level? Wouldn't
>
> texmf/fonts/public/cm/ljfour/dpi657/cmr10.{657}pk
>
> suffice? Also, is /public something UNIX users use and want? Since
> there is no distinction between public and private in the MS-DOS
> world, that level has no meaning.
i'd rather keep pk and drop public. we *do* need pk, so that searching
can look for
fonts//pk//
(in Karl's notation), whereas fonts// would look in the tfm directory
for pk files, which is inefficient
> Going back a way in this thread, Norm (I think) proposed putting the
> tfm files under <source>/<typeface>. Don't most TeX implementations
> expect the tfm files to be grouped together and not necessarily with
i think this is one of the major culture changes this TDS will ask
people to make, following the increasing use of the practice in
web2c-based systems
>
> It is taking me a while to catch up with the rest of you.
but its very important you agree with everything before we go on! you
are carrying the banner of many other vendors
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 17:41:24 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 24 May 1994 15:41:52 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405242241.PAA08275@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Karl and I rather like public/, but I suppose we would rather let it
go than be dragged over hot coals. It is not quite true to say that
in the MS-DOS world public/ is not a real distinction.
If you acquire a font from one of the major foundries, the license
maintains that the font is not sold but only licensed. I think
it is probably true that the release of Utopia for public use
is rather different from DEK's release of concrete.
The public fonts are mostly in the public domain, some of them are
GNU licensed, and some licensed in ways that closely resemble GNU,
but they are definitely made available in a very different spirit
from the proprietary fonts. Some designs (pandora) are copyright,
and since they are expressed in source code, the copyright may actually
have some meaning.
Dropping public/ will very much widen the fonts/directory, but I suppose
not enough to cause genuine trouble. I know that one of Karl's
chief objections is that (for example) concrete is a face design, and
not on the same level of generality as monotype or adobe.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 May 1994 17:54:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 May 94 22:48:12 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405242248.AA06050@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405242241.PAA08275@june.cs.washington.edu> <9405242053.AA05419@ftp.tex.ac.uk>
> If you acquire a font from one of the major foundries, the license
> maintains that the font is not sold but only licensed. I think
> it is probably true that the release of Utopia for public use
> is rather different from DEK's release of concrete.
this is true, but I still dont see why it affects where I put stuff.
My PC has two directories called `VB' and `EMTEX', which have a very
different status, but it would never occur to me to classify them as
`GATES-FUND' and `PUBLIC'. I just know what they are, and copy one for
other people but not the other
> Dropping public/ will very much widen the fonts/directory, but I suppose
> not enough to cause genuine trouble. I know that one of Karl's
Karl might like to comment on efficiency here? but in any case we'll
always search public, adobe and monotype, wont we? so do we save time?
> chief objections is that (for example) concrete is a face design, and
> not on the same level of generality as monotype or adobe.
I wasn't supposing we would have
fonts/concrete
fonts/adobe
but
fonts/concrete
fonts/ptm
fonts/put
fonts/bch
in an ideal world. OK, i can see you all blanching already at the
thought of those 250 directories each with 12 files in, but its
logical. I'd say start from that assumption, and work back? ie one
might put all the Lucida Bright fonts in one directory, like cm,
despite theoretically being several families.
we have to bear in mind the fact that the TDS is describing an
imaginary installation, where the user doesnt probably have 250 font
families installed, so the overhead isnt so bad. the CD is a special
case, if you mount that and search it, god help you. it'll work though,
albeit slowly. so lets not be too distracted by numbers
just to throw a spanner in (well, Bob already waved it), your average
DOS user of commercial fonts probably wants them available for ATM as
well as TeX, so will be tempted to throw them all in \PSFONTS. A pox
on them, I say. Keep the metrics rational, and just add \PSFONTS to a
search path for Type1 fonts for the driver.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 08:03:18 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 25 May 1994 06:03:39 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405251303.GAA01893@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Don't drop public/
It doesn't win you anything.
texmf/fonts/adobe/utopia/pk/ricoh/dpi329/putr.{329}pk
(a write-white previewer font produced via METAFONT and ps2mf)
has exactly the same seven levels of directory as
texmf/fonts/public/cm/pk/ricoh/dpi329/cmr10.{329}pk
(which is actually a bit shorter.)
No one is going to suggest the dropping of adobe/ and
there is a genuine difference between
texmf/fonts/adobe/utopia/pk/ricoh/dpi329/putr.{329}pk
and
texmf/fonts/adobe/utopia/pk/sunview/dpi131/putr.{131}pk
both of which are needed in my environment.
There is probably a very wide range of preview bitmaps needed in the
PC and even the Mac world. There may be several screen preview
drivers out there that use Adobe Font Manager, or some similar
True-Type display font manager but the last thing the TWG-TDS wants to
do is force TeX users to buy additional proprietary packages before
they can make use of free and public domain programs.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 11:26:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 25 May 94 15:52:52 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405251552.AA24190@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <199405251303.GAA01893@june.cs.washington.edu> <9405242248.AA06050@ftp.tex.ac.uk>
> texmf/fonts/adobe/utopia/pk/ricoh/dpi329/putr.{329}pk
...
> No one is going to suggest the dropping of adobe/ and
> there is a genuine difference between
>
oh, but i was! who cares about adobe being the vendor of the font. its
a font, its utopia. it there are two utopias, have two names
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 11:40:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 25 May 1994 12:40:31 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
To: TWG-TDS@SHSU.edu
Message-ID: <769884031.228314.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
sebastian:
> texmf/fonts/adobe/utopia/pk/ricoh/dpi329/putr.{329}pk
...
> No one is going to suggest the dropping of adobe/ and
> there is a genuine difference between
>
oh, but i was! who cares about adobe being the vendor of the font. its
a font, its utopia. it there are two utopias, have two names
we are using concurrently no fewer than three times fonts (aps,
adobe and monotype -- maybe more; i have come to hate times so
much that i avoid looking into this morass as much as possible).
sadly, it *is* necessary to use different names to keep track
of the .tfm files, not just different directories, so sebastian's
point is based on solid ground.
(however, i'm not taking a position on whether /public or /adobe
is useful or desirable in the path structure.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 12:05:20 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 25 May 1994 10:05:49 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405251705.KAA23228@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: a pox on them
A pox is a bit extreme, perhaps, but sebastian makes the
important point that it is one thing to accommodate special
usages in a basically rational scheme, and quite another
to capitulate to irrationality. As he says, keep the
metrics rational.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 12:45:21 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 25 May 1994 10:45:47 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405251745.KAA28517@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
Yes, I discovered that just after I sent mine. I guess what
concerns me there is that Karl's "put" though it works as
a necessary way of getting around DOS limitations (yet again)
is comprenensible to the machine, rather than the human.
I use mtlrl out of necessity when I want to set a drop
initial, but were you able to recognize it right off as
monotype CastellarMT?
We have to keep the paths and filenames within limitations
that are unavoidable, but within those limitations I think it
is important to convey as much relevant information as possible
without forcing unnecessary riffling through a reverse index
to fontname-1.6
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 12:49:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 25 May 94 17:12:37 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405251712.AA24957@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <769884031.228314.BNB@MATH.AMS.ORG> <9405251552.AA24190@ftp.tex.ac.uk>
> we are using concurrently no fewer than three times fonts (aps,
> adobe and monotype -- maybe more; i have come to hate times so
> much that i avoid looking into this morass as much as possible).
> sadly, it *is* necessary to use different names to keep track
> of the .tfm files, not just different directories, so sebastian's
this is what Karl has expended so much effort on, coming up with
unique names for fonts. why dont we use them? ok, karl's scheme will
fail one day, but i think its holding up quite well
s
================================================================================
From owner-twg-tds@shsu.edu Wed, 25 May 1994 13:16:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 25 May 94 17:52:27 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405251752.AA25411@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <199405251745.KAA28517@june.cs.washington.edu> <9405251552.AA24190@ftp.tex.ac.uk>
> is comprenensible to the machine, rather than the human.
> I use mtlrl out of necessity when I want to set a drop
> initial, but were you able to recognize it right off as
> monotype CastellarMT?
...
> is important to convey as much relevant information as possible
> without forcing unnecessary riffling through a reverse index
> to fontname-1.6
well, we more or less have to use the Berry names for the actual tfm
files, i assume. so I was going to use the same system for the
directory names - if they are going to have to look up the name of the
bold italic version of the font anyway, why make they go through two
hoops? since you are going to have to compress Monotype Castellar to 8
letters anyway....
civilised people (not that Pierre is not civilised!) will use LaTeX
packages with nice names to cover up all this garbage anyway. people
who need to use raw tfm names are in trouble already, IMHO
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 07:24:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405261221.AA22295@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
Date: Thu, 26 May 94 08:19:42 -0400
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
Is Sebastian displaying a prejudice against plain TeX? (civilized
people ... will use LaTeX packages...) Just a few years ago (I forget
which), the procedings editor for the TUG conference received more
submissions in plain TeX than in LaTeX. I doubt the situtation has changed.
I am still trying to catch up with all that transpired before I joined
the conference. Do I infer correctly that the tfm file(s) would be in a
subdirectory under the typeface? Perhaps it is the prejudice of
familiarity, but I would prefer the more commonly used arrangement of
the tfms being in a main directory, with subdirectories by vendor,
typeface, or whatever we decide on. I guess I better get a copy of
Karl's scheme of naming fonts.
On 24 May, Sebastian stated I was carrying the banner of many other
vendors. Have the rest of the vendors declined to participate? I would
have hoped Berthold would contribute since he has the most experience
of the vendors with TeX in the Microsoft Windows environment.
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 07:59:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 26 May 1994 08:59:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405261259.AA12173@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
> Dropping public/ will very much widen the fonts/directory, but I suppose
> not enough to cause genuine trouble. I know that one of Karl's
Karl might like to comment on efficiency here? but in any case we'll
always search public, adobe and monotype, wont we? so do we save time?
Directory levels are essentially free in kpathsea (aren't they in emtex,
too?). From the standpoint of machine efficiency, it makes no
substantial difference whether the path is public/cm/tfm or just
cm/tfm. Given ls-R, access time to any file is flat, regardless of where
it is in the tree (just like a hash table :-). Even without ls-R, the
only overhead for extra directories are the longer pathnames (big deal)
and the half-dozen or so extra stat calls (likewise).
files, i assume. so I was going to use the same system for the
directory names -
Just because we can't make all the names infinitely long is no reason to
avoid it in all cases, unless there is a technical problem. I do not yet
understand the basic objection to having adobe/times instead of
`ptm'. As I understand it, there are enough directory levels. So if we
can help users (and site installers/maintainers) by defining a tree that
has human-readable names, why not do it?
if they are going to have to look up the name of the
bold italic version of the font anyway, why make they go through two
People are not incapable of pattern recognition. Users do realize (after
a bit) that *bi means bold italic, *b means bold, etc., since it's the
same for all fonts But it's impossible to guess (or remember) all the
typeface abbreviations.
hoops? since you are going to have to compress Monotype Castellar to 8
letters anyway....
monotype/castellr (say) is a lot more understandable than mtl.
civilised people (not that Pierre is not civilised!) will use LaTeX
packages with nice names to cover up all this garbage anyway. people
who need to use raw tfm names are in trouble already, IMHO
I disagree with you here, Sebastian. I don't see anything wrong with
people using file names. Sure, some people might like to specify fonts
in the way latex likes. Others might not.
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 07:59:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 26 May 1994 08:59:52 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405261259.AA12179@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: help/info
Aside from the never-ending font discussion, Norm also asked a while
back about help/ and info/, and should the TDS mention them.
I don't have a problem with recommending distributors follow the CTAN
directory structure for the non-library files. I'm not sure anything
more needs to be said than that.
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 12:46:45 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405261736.AA10436@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Date: Thu, 26 May 94 13:31:37 -0400
From: bob@microprograms.com
To help me get a better idea of what (I think) we are talking about, I
prepared a simple diagram of the directory structure we are
considering. I concentrated mainly on the /font portion, but included
the rest as stubs. It can be expanded as we progress. (It is quite
lengthy as it is).
I did not use Karl's naming scheme since I do have a copy yet. It might
resolve some of the questions that arise in my mind.
Let's first consider the case of TeX. In my Adobe example I have listed
all the fonts in the Minion set. I have retained the Abode names for
the base names and changed the extension as appropriate. I did a
complete set (including screen and canon sets) to better see what a
full set would look like. Unless someone was generating pk files for
use with a LaserJet printer, the canon set in reality would not exist
for this family.
The first question is how would the users specify Minion-Regular in his document?
\font\myfont=abode\minion\morg at xx pt
or the current practice:
\font\myfont=morg at xxpt
If the later, unless Karl's naming scheme fixes it, TeX will have an
inefficient look-up to perform to get to the correct tfm file (TeX only
cares about tfm files, unless using something like David Fuch's version
with a built-in quick previewer).
Screen previewers and printer drivers need both .tfm and .pk (for
bit-mapped mf fonts) files. Even here, some consideration needs to be
given to efficiency of searching.
BTW, DEC in Ultrix, puts the Abode metrics in
/lib/font/metrics
and uses the full font name, e.g.
newcenturyschlbk_bolditalic.afm
------------------------------------ cut here ---------------------------------
texmf
|-fonts
| |-abode
| | |-minion
| | | |-pfb
| | | | |-morg.pfb
| | | | |-mob.pfb
| | | | |-moi.pfb
| | | | |-mobi.pfb
| | | | |-mobl.pfb
| | | | |-modsi.pfb
| | | | |-mods.pfb
| | | | |-moor.pfb
| | | | |-mosbi.pfb
| | | | |-mosb.pfb
| | | | |-mosdi.pfb
| | | | |-mossb.pfb
| | | | |-moswi.pfb
| | | | |-mjbi.pfb
| | | | |-mjbl.pfb
| | | | |-mjdsi.pfb
| | | | |-mji.pfb
| | | | |-mjrg.pfb
| | | | |-mjsbi.pfb
| | | | |-mjsb.pfb
| | | |-pk
| | | | |-screen
| | | | | |-dpi118
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi129
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi142
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi170
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi204
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi245
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi294
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | |-canon
| | | | | |-dpi300
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi329
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi360
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi432
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi518
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi622
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | | | |-dpi746
| | | | | | |-morg.pk
| | | | | | |-mob.pk
| | | | | | |-moi.pk
| | | | | | |-mobi.pk
| | | | | | |-mobl.pk
| | | | | | |-modsi.pk
| | | | | | |-mods.pk
| | | | | | |-moor.pk
| | | | | | |-mosbi.pk
| | | | | | |-mosb.pk
| | | | | | |-mosdi.pk
| | | | | | |-mossb.pk
| | | | | | |-moswi.pk
| | | | | | |-mjbi.pk
| | | | | | |-mjbl.pk
| | | | | | |-mjdsi.pk
| | | | | | |-mji.pk
| | | | | | |-mjrg.pk
| | | | | | |-mjsbi.pk
| | | | | | |-mjsb.pk
| | | |-tfm
| | | | |-morg.tfm
| | | | |-mob.tfm
| | | | |-moi.tfm
| | | | |-mobi.tfm
| | | | |-mobl.tfm
| | | | |-modsi.tfm
| | | | |-mods.tfm
| | | | |-moor.tfm
| | | | |-mosbi.tfm
| | | | |-mosb.tfm
| | | | |-mosdi.tfm
| | | | |-mossb.tfm
| | | | |-moswi.tfm
| | | | |-mjbi.tfm
| | | | |-mjbl.tfm
| | | | |-mjdsi.tfm
| | | | |-mji.tfm
| | | | |-mjrg.tfm
| | | | |-mjsbi.tfm
| | | | |-mjsb.tfm
| | |-TimesRoman
| | | |-pfb
| | | | |-*.pfb
| | | |-pk
| | | | |-screen
| | | | | |-dpi118
| | | | | | |-*.pk
| | | | | |-dpi*
| | | | |-canon
| | | | | |-dpi*
| | | |-tfm
| | | | |-*.tfm
| |-<what name?>
| | |-cm (Computer Modern)
| | | |-pk
| | | | |-screen
| | | | | |-dpi*
| | | | |-canon
| | | | | |-dpi*
| | | |-tfm
| | | | |-*.tfm
|-tex
| |-language
| | |-<whatever>
| |-indexing
| | |-<whatever>
|-bibtex
| |-bst
| | |-<whatever>
|-support
| |-<whatever>
|-usergrps
|-<group>
|-<whatever>
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 13:59:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 26 May 94 16:14:11 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405261614.AA16509@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <9405251752.AA25411@ftp.tex.ac.uk> <9405261221.AA22295@uu3.psi.com>
bob@microprograms.com writes:
> Is Sebastian displaying a prejudice against plain TeX? (civilized
> people ... will use LaTeX packages...) Just a few years ago (I forget
> which), the procedings editor for the TUG conference received more
> submissions in plain TeX than in LaTeX. I doubt the situtation has changed.
you must be joking! a rough look at 1994 has 22 LaTeX, 9 plain. and
last year LaTeX was higher i think. but this is religion....
> the conference. Do I infer correctly that the tfm file(s) would be in a
> subdirectory under the typeface? Perhaps it is the prejudice of
thats what is planned so far
> familiarity, but I would prefer the more commonly used arrangement of
> the tfms being in a main directory, with subdirectories by vendor,
> typeface, or whatever we decide on. I guess I better get a copy of
its much easier to *remove* a family if all its files are in the same
directory tree.
> On 24 May, Sebastian stated I was carrying the banner of many other
> vendors. Have the rest of the vendors declined to participate? I would
> have hoped Berthold would contribute since he has the most experience
> of the vendors with TeX in the Microsoft Windows environment.
i think the feeling when this group was suggested that it should be
small, and so not everyone would be asked to join. you were obviously
to be there, since you were working on the CD, so berthold would not
be needed. but maybe he should be brought in soon; but he'd have to
*promise* not to start any discussion about virtual fonts!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 May 1994 18:13:58 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q6ocT-0006RwC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 27 May 94 00:13 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
>full set would look like. Unless someone was generating pk files for
>use with a LaserJet printer, the canon set in reality would not exist
>for this family.
Or if they preview using xdvi!
>or the current practice:
> \font\myfont=morg at xxpt
This latter version is what exists (in a disguised version) in the
standard LaTeX fd files. The fd files have to be portable between
systems, so until there's agreement amongst TeX implementors on
specifying multi-part font names, the `morg at Xpt' version will be
what the fd files on CTAN support.
Oh yes, and thinking of fd files, where are these going to live? With
the LaTeX inputs (they're read by LaTeX) or with the fonts?
Since the files aren't very big (typically two files of ~1K per font
family) we could have both... an fd subdirectory of inputs/latex and
an fd subdirectory of each font family.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 09:54:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 94 14:05:47 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405271405.AA05811@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <9405242248.AA06050@ftp.tex.ac.uk> <9405261736.AA10436@uu3.psi.com>
> The first question is how would the users specify Minion-Regular in his document?
> \font\myfont=abode\minion\morg at xx pt
> or the current practice:
> \font\myfont=morg at xxpt
> If the later, unless Karl's naming scheme fixes it, TeX will have an
> inefficient look-up to perform to get to the correct tfm file (TeX only
> cares about tfm files, unless using something like David Fuch's version
I dont understand this. there is only one morg.tfm, where is the
ambiguity? the driver has to *look* for it, of course
> BTW, DEC in Ultrix, puts the Abode metrics in
> /lib/font/metrics
> and uses the full font name, e.g.
> newcenturyschlbk_bolditalic.afm
they have the luxury of Unix...
your tree is basically as i imagine it. the <?> branch above cm is
`public' in Karl/Pierre-speak. Or `knuth' perhaps more accurately
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 09:54:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 94 14:08:03 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405271408.AA05838@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <9405261736.AA10436@uu3.psi.com> <m0q6ocT-0006RwC@rsuna.crn.cogs.susx.ac.uk>
>
> Oh yes, and thinking of fd files, where are these going to live? With
> the LaTeX inputs (they're read by LaTeX) or with the fonts?
>
> Since the files aren't very big (typically two files of ~1K per font
> family) we could have both... an fd subdirectory of inputs/latex and
> an fd subdirectory of each font family.
>
since the tfms can be read by any font, and .fd files (currently)
only by LaTeX, the .fds really have to be in
texmf/tex/latex/minion/*.fd
to be logical. or
texmf/tex/latex/fd
if you prefer (I dont)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 10:14:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q73WZ-000073C@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 27 May 94 16:08 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
>since the tfms can be read by any font, and .fd files (currently)
>only by LaTeX, the .fds really have to be in
> texmf/tex/latex/minion/*.fd
>to be logical. or
> texmf/tex/latex/fd
>if you prefer (I dont)
Hmm... I can see the former producing a *lot* of directories at the
latex/ level. There's also the problem that if Jane or Joe Doe wants
to copy Adobe Minion off a CD-ROM, they have to copy the contents of
fonts/adobe/minion *and* latex/minion.
How about latex/fd/<file>.fd for LaTeX to find the fd files easily,
and fonts/<foundry>/<family>/fd/<file>.fd to keep all the files
related to one font family together.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 10:17:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 94 16:17:26 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405271517.AA00165@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
> since the tfms can be read by any font, and .fd files (currently)
> only by LaTeX, the .fds really have to be in
> texmf/tex/latex/minion/*.fd
> to be logical. or
> texmf/tex/latex/fd
> if you prefer (I dont)
>
> sebastian
This seems odd to me. There seem to be two opposing forces:
1) For retrieving and deleting individual font families, the most
convenient structure is
<some-path-to-specify-font-family>/
with individual directories/files for the tfm/pfa/mf/fd
whatever... below this.
This puts all files related to one font family in one place.
2) For using fonts in a simplistic way, a more natural scheme is the
current `norm' which is to have top level tfm, mf ... whatever
directories, with possibly a directory structure below that
corresponding to source/vendor etc.
This puts all the files of one type in one branch of the tree, but
separates the files related to a particular font-family.
The discussion so far has strongly indicated (1) as being preferred.
(which is OK by me, as I use Karl's web2c system) but does require
TeX (and all other associated programs) to have a smart searching
scheme.
Now you have distinguished fd files, it would seem a bit odd to put
them somewhere else, away from all the other files related to a given
font. Plain TeX can not read them directly, but it can not read pk
files either, so I dont see why this is relevant.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 10:31:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 11:32:06 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405271532.LAA16047@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Proposal 0.3
References: <9405221653.AA12528@ftp.tex.ac.uk> <199405221913.MAA27116@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
> I don't want to suggest changing the /usr/local/* practice now,
> only to suggest that we may be forced to reconsider /usr/local
> in the future
>From the point of view of the TDS, /usr/local/* is immaterial. What's
important is .../texmf/*. "..." can be anywhere that's convenient.
On non-Unix systems ('cept for wierdos like me ;-), it's very unlikely
to be /usr/local.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 10:39:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 11:39:38 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405271539.LAA17184@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <0097EDED.749A2440.46@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 23 May 1994 at 17:56:00, George D. Greenwade wrote:
> The lesson here is on two levels -- first level, short-term, I agree with
> Bob: we have to recognize that many systems are not current
> state-of-the-art and accept that users of the CD may not be running the
> latest versions of the software. Second level, long-term, much more
> important: how well the TDS is set up for true platform-independent
> application and future extensibility along that goal may be one of the
> central deciding factors in getting those upgrades, keeping people using
> TeX, and getting people into using TeX (IMO, it is *THE* factor upon which
> most TeX issues will be focused). The trade-off is to adequately satisfy
> level one, but recognize that level two is what we are really dealing with
> -- the long-term health of TeX.
The thing to keep in mind is that the TDS doesn't (necessarily) need
all of the compromises that a commercially viable CD for 1994 does.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:01:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 12:01:34 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405271601.MAA19698@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <199405251745.KAA28517@june.cs.washington.edu> <9405251552.AA24190@ftp.tex.ac.uk> <9405251752.AA25411@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 25 May 1994 at 17:52:27, Sebastian Rahtz wrote:
> > is comprenensible to the machine, rather than the human.
> > I use mtlrl out of necessity when I want to set a drop
> > initial, but were you able to recognize it right off as
> > monotype CastellarMT?
> ...
> > is important to convey as much relevant information as possible
> > without forcing unnecessary riffling through a reverse index
> > to fontname-1.6
> well, we more or less have to use the Berry names for the actual tfm
> files, i assume. so I was going to use the same system for the
> directory names - if they are going to have to look up the name of the
> bold italic version of the font anyway, why make they go through two
> hoops? since you are going to have to compress Monotype Castellar to 8
> letters anyway....
>
> civilised people (not that Pierre is not civilised!) will use LaTeX
> packages with nice names to cover up all this garbage anyway. people
> who need to use raw tfm names are in trouble already, IMHO
I still argue in favor of the directory level (I know I'm still reading
old mail (you wouldn't believe the week I had), someone pointed out that
it isn't really much of an advantage to remove it anyway from an efficiency
standpoint, but I'll argue that point when I reach it ;-).
Ok, so the user doesn't need to know the name of the TFM to use it, that's not
unlikely, but I still think the _directory structure_ should be
understandable. If I want to know which variants of Adobe Courier that I've
got around, I'd much rather look for
.../adobe/courier/tfm/pcr*.tfm
than
.../pcr/tfm/pcr*
Especially if this isn't my system and I'm wondering generally what's
available. An ls -R that shows "adobe/courier", "bitstream/charter", etc.
is going to be easier to interpret than the Berry names.
Additionally, as much as I favor and use the Berry names myself, our TDS
doesn't need to mandate them if we leave <supplier>/<typeface> in place.
I can use ../adobe/courier/adobe-courier-bold.tfm if I really want.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:30:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 08:41:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405271241.AA04559@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: font directory schemes
Let me try to summarize the two proposed font directory schemes (seeing
Bob's tree made me realize this might help us decide what to do):
1) the Berry/MacKay scheme, now the kpathsea default:
texmf/fonts/adobe/times/tfm/ptmr.tfm
texmf/fonts/public/cm/pk/cx/dpi300/cmr10.pk
(as well as, on non-DOSish systems
texmf/fonts/public/cm/pk/cx/cmr10.300pk
)
2) the Rahtz scheme:
texmf/fonts/ptm/tfm/ptmr.tfm
texmf/fonts/cm/pk/cx/dpi300/cmr10.pk
I already laid out my thoughts on the two yesterday ...
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:30:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 08:41:36 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405271241.AA04571@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: latex .fd files
Oh yes, and thinking of fd files, where are these going to live? With
the LaTeX inputs (they're read by LaTeX) or with the fonts?
They're read by latex, hence I think they should go in a latex
directory. What's the advantage to having them in the font tree?
Since the files aren't very big (typically two files of ~1K per font
family) we could have both... an fd subdirectory of inputs/latex and
an fd subdirectory of each font family.
It's always better not to duplicate files if it can be avoided.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:31:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 1994 08:41:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405271241.AA04565@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
The first question is how would the users specify Minion-Regular in his document?
\font\myfont=abode\minion\morg at xx pt
or the current practice:
\font\myfont=morg at xxpt
It has to be the latter. The former is portable neither technically
(different systems use different directory separators) nor among sites
(different installations use different directories, and always will, no
matter how much this ``standard'' gets promulgated).
Therefore, it has to be up to the implementation to turn `morg' (pmnr,
in my names) into a filename.
If the later, unless Karl's naming scheme fixes it, TeX will have an
inefficient look-up to perform to get to the correct tfm file (TeX only
How does the inefficiency follow? I don't understand.
How the files are looked up is a quality-of-implementation issue. There
are many, many ways to do it. (I've implemented half a dozen file
searching methods myself.)
| |-abode
I don't know what Abode is. Is that the name of your product?
(Or is a typo for Adobe?)
In any case, since you say these are the Adobe files, I think the
<source> name at this level should be `adobe'.
| | | | |-screen
Is `screen' a mode? I think this should somehow reflect what created
those files -- `ps2pk' or `gsftopk' or whatever program you use.
| | |-TimesRoman
Names like TimesRoman won't do, as I'm sure you know. Has to be
monocase, <= 8 letters. I.e., `times'.
| |-<what name?>
`public'.
|-tex
| |-language
| | |-<whatever>
| |-indexing
| | |-<whatever>
It's not clear to me that either language/ or indexing/ should be
subdirectories of tex/. We were talking about having directories named
plain/, latex/, amstex/, etc. Then there would be latex/misc/makeidx.sty
or whatever.
|-support
| |-<whatever>
|-usergrps
|-<group>
|-<whatever>
IMO, these should be siblings of texmf, not descendants.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:35:28 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q74o3-000073C@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 27 May 94 17:30 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
>They're read by latex, hence I think they should go in a latex
>directory. What's the advantage to having them in the font tree?
I buy the Lucida fonts, I mount my CD-ROM to grab the Lucida-in-TeX
stuff off the CD. What do I need? The contents of
fonts/bandh/lucida/*, and some miscellaneous stuff in the LaTeX and
plain TeX heirachy that I have to root around for.
It's another of those times when the heirachy you want for running TeX
is very different from the heirachy you want for distributing it.
Sigh...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 11:44:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 May 94 17:44:40 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405271644.AA00271@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
> It's always better not to duplicate files if it can be avoided.
sounds good.
> They're read by latex, hence I think they should go in a latex
> directory. What's the advantage to having them in the font tree?
I'll turn this round
texmf/fonts/adobe/times/tfm/ptmr.tfm
texmf/fonts/adobe/times/fd/ptmr.fd
texmf/fonts/adobe/times/afm/ptmr.afm
...
Has the advantage of keeping all the files for adobe times in one
place, which is helpful for human maintainers, but it means that all
applications searching for one particular type of file have to search
the whole tree (in theory implementation issues might mean this isnt
as bad as it sounds)
texmf/fonts/tfm/adobe/times/ptmr.tfm
texmf/fonts/fd/adobe/times/ptmr.fd (or texmf/latex/fd/...)
texmf/fonts/afm/adobe/times/ptmr.afm
...
means that any application searching for tfm files only need search a
branch of the tree containing tfm's, but means that installing a new
font family involves inserting files at various leaves of the tree.
Both schemes have advantages and disadvantages, but I think that fd
files are no different from other files in this respect.
David
By the way adobe/times looks a nicer directory name than ptm
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 14:58:55 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q77yM-00007GC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 27 May 94 20:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
>Both schemes have advantages and disadvantages, but I think that fd
>files are no different from other files in this respect.
Well, they're a bit worse than some, since they straddle the divide
between fonts/ and latex/.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 May 1994 19:01:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 27 May 1994 14:44:44 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405272144.OAA00637@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
Karl says
it's alwas better not to duplicate files . . .
Emphatic agreement. You inevitably get dialects developing on
the two different branches of the tree. Most often the dialects
are trivial in their difference, but they can somtimes cause
real trouble.
Elizabeth and I have a slight problem in this regard. We want
to put the files for (e.g.) arabtex where they belong in the
texmf/ tree, but we also want to give people access to the
other material in the package that does not really belong
in the texmf/ tree. We have decided to keep the package
together in a directory entirely outside texmf/ but that does
mean having copies kicking around. Maybe fd needs to be treated this
way, but it doesn't sound to me as if the need has been very
clearly proven.
One last thing, which is really outside the texmf/ question, but
germane to the TDS. After getting some plaintive calls for help
from people with memory-starved postscript printers and no previous
experience of dvips, etc., we propose for a few things like
the texi files for dvips and kpathsea to run
dvips -S 4 -i -N on them, which reduces the sections to files
of about 60kb or less, and provide them in a directory whose
name I have forgotten (Elizabeth knows). What we are wondering
is whether we can use the -Z bitmap compression flag, or whether
this risks messing up some of the less competently written
PostScript interpreters. -N is necessary because there is a lot
of bad handling of structure comments still floating around.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 May 1994 10:25:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 28 May 1994 11:25:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405281525.AA18914@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: fd files
(I thought I'd try sending separate mail on separate subjects to see if
that cleared things up in my mind any; I kinda doubt it, but ... :-)
About fd files: I really don't see that it's worth putting latex (or
plain) input files in the font tree. We certainly don't want tex to have
to search for texmf/fonts//fd, so they're just there for the benefit of
installers.
But it seems to me someone installing latex should know enough to
install the things under latex/. Or the script they are using should
know enough. And presumably all the fd files will be installed in a
chunk (because they're small), so it's not a human will have to pick and
choose from among hundreds of things to do.
And then we don't have to duplicate the files.
It just seems strange to me to put files in a place where they will
never be used.
As for the arrangement under latex, one option is to do
<source>/<typeface> stuff under latex/fd, as in latex/fd/adobe/times.
Now you have distinguished fd files, it would seem a bit odd to put
them somewhere else, away from all the other files related to a given
font. Plain TeX can not read them directly, but it can not read pk
files either, so I dont see why this is relevant.
The point is that latex won't search for them in the font tree.
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 May 1994 10:25:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 28 May 1994 11:25:42 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405281525.AA18926@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: distribution vs. installation
Elizabeth and I have a slight problem in this regard. We want
to put the files for (e.g.) arabtex where they belong in the
texmf/ tree, but we also want to give people access to the
other material in the package that does not really belong
in the texmf/ tree. We have decided to keep the package
together in a directory entirely outside texmf/ but that does
mean having copies kicking around. Maybe fd needs to be treated this
way, but it doesn't sound to me as if the need has been very
clearly proven.
Now this is the biggest remaining problem that we need to address, imo,
which Alan and others have mentioned before.
There is a big clash between the best way to distribute a package
(arabtex-1.0/{tfm,latex,...}) and the best way for it to be seen by the
programs (texmf/fonts/public/arabtex/tfm/...).
Perhaps the only viable approach is to punt, and have two copies of the
files, i.e., there's a `make install' in the arabtex-1.0/ source
directory that puts everything in the ``right'' place. But the right
place is not the same place everywhere.
Is there any plausible alternative, so that somehow tex can be convinced
into finding arabtex-1.0/tfm?
The same applies for things like dvips and dvilj -- there are all
those font files in those distributions. A number of sites use the
automounter to keep different versions separate -- there is
/tools/dvips-5.55a and /tools/dvips-5.528b, for example. /tools/dvips
is a symlink to whichever is the stable, tested version.
Unfortunately, TeX cannot look for the fonts under /tools/dvips, unless
I go through and individually symlink everything in
.../texmf/fonts/adobe/*/tfm, which has its own problems (when the set of
fonts in the distribution changes, a new symlink needs to be made). Yuck.
Am I making any sense? Is there any good way to deal with this?
In short, how to deal with fonts and other library files that are part
of other distributions, when it's not optimal to copy them into texmf...
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 May 1994 10:25:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 28 May 1994 11:25:41 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405281525.AA18920@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: font hierarchies
David suggests:
2) For using fonts in a simplistic way, a more natural scheme is the
current `norm' which is to have top level tfm, mf ... whatever
directories, with possibly a directory structure below that
corresponding to source/vendor etc.
For small installations, I wouldn't argue with flat directories: all the
tfm's in texmf/fonts/tfm, all the pk's in texmf/fonts/pk/<mode>, etc.
Then path searching is no more than what every program does, because
subdirectory searching is unnecessary.
But I don't think the TDS should recommend it, because it leads to truly
large directories. I have nothing installed but the usual free fonts and
the TFM's for the builtin PostScript and LJ4, and that is 772 TFM files
(56 typefaces, 255 directories). I wouldn't want to have a directory
with 772 files. That's the whole reason I invented subdirectory
searching for TeX in the first place.
I don't see the point to replicating the source/typeface stuff below
top-level tfm/pk/vf/etc. directories, because then you just have to do
subdirectory searching again. I doubt there is enough of an efficiency
gain to searching texmf/fonts/tfm// to make it worthwhile to separate
the files for a given typeface. I suspect you'd still have to resort to
ls-R.
I could certainly be wrong, though. Do you have your fonts set up as
fonts/tfm/<source>/<typeface>? If so, can you tell me how long file
searching takes without ls-R?
The discussion so far has strongly indicated (1) as being preferred.
(which is OK by me, as I use Karl's web2c system) but does require
TeX (and all other associated programs) to have a smart searching
scheme.
If you're not going to have single huge directories, you have to have
subdirectories, right? They can either be searched automatically or by adding
lots of things to the paths, but they'll have to be searched somehow...
As a practical matter, I hear emtex has subdirectory searching now,
which ought to let a significant fraction of non-web2c TeX users use
something like what we have now.
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 May 1994 10:59:42 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q7Qiw-000076C@csrj.crn.cogs.susx.ac.uk>
Date: Sat, 28 May 94 16:54 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: fd files
>It just seems strange to me to put files in a place where they will
>never be used.
Nevery be used, yes. But it's the way they're distributed. OK, an
example. The stmaryrd package consists of some mf files, some tfm
files, some pk files, an fd file, a sty file and some documentation.
Just about the only restriction we made on distribution was that all
these files had to be distributed together as one unit. This is
precisely to avoid the case where A.N.Sysadmin copies stmary.sty into
the inputs directory, and doesn't copy the tfms (or the pks or the mfs
or the fds or whatever). So CTAN has (or at least should have :-) two
copies of the stmary directory, one under fonts and one under latex.
These can just be symbolic links, so all is fine and well. But ISO
9660 doesn't support symlinks, so we have a problem there.
Previously it's been OK to have two completely different heirachies:
one for distribution (eg on CTAN) and one for running TeX (eg
/usr/local/tex). But CD-ROMs rather scupper this neat division,
because they're doing both jobs.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 May 1994 23:48:56 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 28 May 1994 21:49:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405290449.VAA07813@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
CC: mackay@cs.washington.edu, unixtex@u.washington.edu
Karl reinforces our feeling that the only thing
to do is to "punt, and have two copies of the files"
My sense is that as long as we are constrained by
the historical limitations of a catastrophically badly
designed file system (DOS 8.3) and several other nearly
as bad compromises, there is no better way. Symbolic
links are wonderful. I can't imagine how I would live
without them in 1994, but they are so specific to
BSD-flavored Unix, that even the Posix standard makes
them impossible.
"Of course, the fact that no POSIX-conforming application
will ever create a symbolic link does not help much."
Donald Lewine, {\it Posix Programmer's Guide}. p 83
So symbolic links are a cure for those of us who have
them, but not for the rest of the world.
(As we face wretched botches like this, it is worth remembering
that Tops-20 offered sensible filename lengths and half
a dozen other sensible features well before Unix became
a household name. It isn't as if the creators of brain-dead
operating systems had no models of what was needed.)
I guess the only problem is to decide which packages are
so esoteric that we dump them on the user with the cold comfort
that "if you want to do X you are on your own." and which we try to
provide for at the primary level. I have an obvious prejudice.
I would like to make at least a couple of the more significant
natural language packages in TeX available at the basic level of
installation. TeX is at least as important for what it offers to
readers of GGreek and Arabic
as for what it offers to mathematicians, and the readers of Greek
and Arabic so often need an even easier path to familiarization
with the system than mathematicians do. I don't know quite how we choose.
Should Greek and Arabic take preference over Czech and Vietnamese?
I have no obvious answer. We obviously can't accommodate everyone.
On the positive side, the broad outlines of a working compromise
are clearly discernable. It seems to me we are very close
to something that will work across the spectrum of DOS VMS ISO-9660
and Unix. I think we should lean towards paths that incidentally
convey the largest amount of information to both users and
installers, and it appears that there is some support for that
view. There is not too much more needed except a broad agreement
on the content of the basic distribution.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Sun, 29 May 1994 10:15:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 29 May 1994 11:15:38 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405291515.AA26735@terminus.cs.umb.edu>
To: mackay@cs.washington.edu
CC: TWG-TDS@SHSU.edu, mackay@cs.washington.edu, unixtex@u.washington.edu
Subject: Re: distribution vs. installation
Karl reinforces our feeling that the only thing
to do is to "punt, and have two copies of the files"
Bummer! I was hoping you'd have a better solution, i.e., a way to search
the distribution directories.
"Of course, the fact that no POSIX-conforming application
will ever create a symbolic link does not help much."
Donald Lewine, {\it Posix Programmer's Guide}. p 83
That just means there will be fewer and fewer POSIX-conforming
applications as time goes by. Standards that don't reflect reality
quickly become obsolete.
view. There is not too much more needed except a broad agreement
on the content of the basic distribution.
But we're supposed to be defining the directory structure, not a common
TeX distribution (if there can be any such thing) ... not that the
latter is not a worthwhile goal, but it's a separate issue.
example. The stmaryrd package consists of some mf files, some tfm
files, some pk files, an fd file, a sty file and some documentation.
Just about the only restriction we made on distribution was that all
these files had to be distributed together as one unit. This is
Distributed together, yes. But installed together? Urk ...
Previously it's been OK to have two completely different heirachies:
one for distribution (eg on CTAN) and one for running TeX (eg
/usr/local/tex). But CD-ROMs rather scupper this neat division,
because they're doing both jobs.
Yes. Clearly, the maker of each CD-ROM (or any other distribution) has
to decide what to put in it. As Pierre says, which distributions get put
into the texmf/ tree by the distributors, and which get left up to the
installers to do is open to debate. Each distributor has to make their
own decision in this matter, it seems to me.
What people producing source hierarchies like stmaryrd or dvips or
arabtex can do is provide an install script/target that copies the stuff
from the source directory (stmaryrd-1.0/tfm) to the installed location
(texmf/fonts/public/stmaryd/tfm).
The thing I don't yet see is the purpose of enshrining, in the
Ideal-yet-Practical, Officially Recommended TeX Directory Structure,
is directories that are never used. Like fd in the fonts tree.
Maybe it'll be there on the O'Reilly CD, maybe not. But I don't see the
point in *recommending* it be there, i.e., saying a directory tree is
``not strictly conforming'' if it is not there.
What a mess.
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 May 1994 05:54:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 30 May 94 11:54:47 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405301054.AA02939@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: fd files
On fd files,
I take Karl's points about path searching, my concern about fd files
was really along the lines of his other post.
> There is a big clash between the best way to distribute a package
> (arabtex-1.0/{tfm,latex,...}) and the best way for it to be seen by the
> programs (texmf/fonts/public/arabtex/tfm/...).
That is, (hopefully:-) new distributions of individual font families
will distribute fd files along with all the other assorted files
required to describe a font, so from that `view' fd files appear the
same as other files. Since we are going to have to live with this
problem anyway for all kinds of files that need to be unpacked from
their distributed form into the `proper' place, I'll give up on
suggesting TDS should put fd files under fonts.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 May 1994 13:26:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 30 May 1994 13:26:40 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097F347.FD451660.2813@SHSU.edu>
Subject: RE: distribution vs. installation
On Sat, 28 May 1994 11:25:42 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> Perhaps the only viable approach is to punt, and have two copies of the
> files, i.e., there's a `make install' in the arabtex-1.0/ source directory
> that puts everything in the ``right'' place. But the right place is not
> the same place everywhere.
Personal religion time. IMO, the `right' place should be the same relative
location in the hierarchy for packages which are putatively TeX-related.
It may be that the variously-mountable texmf/ (i.e., on Unix, it could be
/usr/local/texmf/... while on VMS it might be SYS1:[LOCAL.texmf] while on
DOS it might be c:\somewhar\texmf\ etc., .etc., ad nauseum) needs to
reconsider a misc/ or somesuch to provide hooks for extensibility -- not
that they will necessarily ever be on any CD, but the TDS should have that
type of hook in it.
> The same applies for things like dvips and dvilj -- there are all those
> font files in those distributions.
Again, this may be (hell, it IS) a short-term truth; an implicit goal I
hope everyone is keeping an eye on is that if some well-specified
guidelines are provided, maybe future versions of these (and other)
applications will migrate to the TDS. Historically, meaning pre-CTAN, I
can see very valid reasons for each package essentially being a
stand-alone; with the CTAN and a well-specified structure, I can see where
some of the `already included in the package' items might be viewed as the
superfluous material it should be.
> A number of sites use the automounter to keep different versions separate
> -- there is /tools/dvips-5.55a and /tools/dvips-5.528b, for example.
> /tools/dvips is a symlink to whichever is the stable, tested version.
>
> Unfortunately, TeX cannot look for the fonts under /tools/dvips, unless I
> go through and individually symlink everything in
> .../texmf/fonts/adobe/*/tfm, which has its own problems (when the set of
> fonts in the distribution changes, a new symlink needs to be made). Yuck.
But this is essentially what every other operating system is doing right
now; for Unix, there is a semi-elegant way to handle migration between
versions. Maintaining a migration movement on just about any other
operating system is not quite so nice. Where a TDS would come in nice (and
assuming my view of the future for related packages above become reality
come true) is in minimizing the pain, whether it is a symlink, change in
environment variable, path, logical, what-have-you. Not that I want to
move to the lowest common denominator for everything, but I also wish to
offer a slightly different view here -- quite a bit of this discussion is
focused toward what I would term professional installers (system
administrators, etc.) while the bottom line is that logical support for Joe
User on a stand-alone system is what will make or break someone dealing
with this on their own. I would expect to have to deal with the stable
version here as the primary topic for concern.
On a side comment (showing my ignorance) -- regarding the .fd files:
Isn't this just about always going to be read in the texinputs (or
whatever) path for every application? As far as LaTeX is concerned, this
is to be in the inputs path (or so it appears), but it points to something
in the fonts path. It seems simple enough to me to include them simply in
the inputs path (as now provided) recognizing that they represent the link
to the fonts path. Just as some things in FSF packages get placed in an
exepath and others to a manpath, why can't this also be the case here?
That way, no retrofitting of anything. Possibly having a texmf/inputs/fd
or something if you really want to segregate them out, but leave them in
the inputs path and omit them from the fonts path.
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 May 1994 15:02:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 30 May 94 19:56:47 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405301956.AA28425@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: RE: distribution vs. installation
References: <0097F347.FD451660.2813@SHSU.edu>
i think we are sliding a bit from TDS itself; our guidelines really
cannot *recommend* that things appear twice.
working down from ideals, we all agree (I assume) that the correct
behaviour for package `foo' is to have:
fonts/foo/...
and
tex/latex/foo
relecting the set of metrics/sources/bitmaps, and the LaTeX inputs
(or plain, or misc). so i don't see whats wrong with:
fonts/utopia/.../*.{tfm,vf,pfb}
tex/latex/utopia/OT1put.fd
in *theory*. similarly,
fonts/arabtex/.../*.{pk,tfm}
tex/latex/arabtex/arab.sty
seems fine. the fact that arabtex comes in one package for
distribution is besides the point - it can have an install script.
the argument that OT1put.fd should go under `fonts' falls over in the
light of the fundamental decision that `macros' and `fonts' live
separately (not, if you think about it, entirely necessary).
one *could* argue that a tex/latex/fd directory would a good
compromise, since typically an fd file refers to many .tfm files, so
we don't have many fd files.
so I think that the TDS recommendation should be that for a mixed
macro/font package, it should be installed in two directories of its
own, one under fonts, the other under {plain,latex,misc} as
appropriate. BUT that some installations may prefer to lodge solitary
.fd files in their own directory for tidiness.
i wonder abouit having a *parallel* directory to tex/latex, tex/plain
etc, called tex/languages? since almost all language stuff is format
independent? i don't know.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 May 1994 16:14:37 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405302108.AA24553@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Date: Mon, 30 May 94 17:07:19 -0400
From: bob@microprograms.com
Karl comments on my tree:
> |-tex
> | |-language
> | | |-<whatever>
> | |-indexing
> | | |-<whatever>
>
>It's not clear to me that either language/ or indexing/ should be
>subdirectories of tex/. We were talking about having directories named
>plain/, latex/, amstex/, etc. Then there would be latex/misc/makeidx.sty
>or whatever.
>
> |-support
> | |-<whatever>
> |-usergrps
> |-<group>
> |-<whatever>
>
>IMO, these should be siblings of texmf, not descendants.
I found two messages in this thread: one proposed support and usergrps
as descendants of root, which was defined as "texmf"; the other as
siblings. With our preoccupation with fonts I think we missed resolving this one.
Bob
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 May 1994 16:15:02 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9405302108.AA24547@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
Date: Mon, 30 May 94 16:59:45 -0400
From: bob@microprograms.com
Oops! Sorry about the typos. I hope they did not cause anyone undue
pain and confusion. Thank you, Karl, for the copy of your "Filenames for TeX Fonts".
My "screen" refered to fonts for screen previewers and paralleled the
"canon" and "ljfour" examples. The name is probably incorrect.
If one were to adopt Karl's naming scheme, finding the tfm files would
be relatively efficient:
my source directory "adobe" becomes "p"
my typeface directory "minion" becomes "mn"
etc.
The program would parse the name.
If a directory off of fonts named "p" does not exist, fail and return
"font not found" else continue.
If a directory off of "p" named "mn" does not exist, fail and
return "font not found" else continue.
etc.
Not bad---as long as the site rigorously follows Karl's scheme.
But, what if a site did not want to follow Karl's scheme, but retain
"adobe," "minion," "times," etc.? Then the program would have to desend
all the subdirectories under fonts until it found the correct tfm file
or exhausted the the possibilities.
The programmer would have to provide for both alternatives since I do
not believe it is reasonable to force a site to use a particular naming
scheme, however well contructed it is. For the programmer, it is a
one-time investment in time to write, test and debug.
Now, when the system administrator installs a typeface, he puts
everything together as we have discussed using either Karl's names or
the one adopted by his site. Since all the files for a given typeface
are together in one place, his job of maintenance is simplified. The
organization we have proposed should be readily accepted by the system
administrators.
Finally, the user comes along to (La)TeX his document. All of the work
that has gone before is transparent to him. He only sees how fast his
computer processes the input. If the site has adopted Karl's scheme
rigorously, it should not matter because the directory search will be
fast. However, if the site has used a different scheme, it could take
some time for the computer (especially a moderate speed one like my
486DX2-66) to search all the directories to find the correct tfm file.
Someone refered to the UNIX ls -R. I tried the DOS equivalent (dir /s)
to find a random file on a 320 MB drive. It took a noticeable length of time.
That is the inefficiency to which I refered.
I was discussing some of our thoughts with a heavy TeX user who lives
near me (name omitted to protect the innocent) and his immediate and
strong reaction was "leave the tfm files in their own directory like
they are now". When I countered with the argument of system
maintenance, he rejoined that the tfm files are small enough that if a
few orphans were left around it would not bother him as much as the
lost of speed when processing a document.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 03:58:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q8PZn-000076C@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 31 May 94 09:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: RE: distribution vs. installation
>Isn't this just about always going to be read in the texinputs (or
>whatever) path for every application? As far as LaTeX is concerned, this
Yes, the fd files should be in the LaTeX inputs path. inputs/latex/fd
is the obvious place to put them, although this directory may end up
quite large (two files per font family). It might be possible to
split the fd directory by foundry, but that would break the pattern
for the rest of the inputs directory.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 07:29:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 08:29:50 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405311229.AA19519@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
My "screen" refered to fonts for screen previewers and paralleled the
"canon" and "ljfour" examples. The name is probably incorrect.
`screen' is a generic category. `canon' and `ljfour' are specific modes.
Hence the TDS should have something like `ega' or `sun' or `ps2pk' or
`ghostscript' or ..., not `screen'.
The program would parse the name.
If a directory off of fonts named "p" does not exist, fail and return
"font not found" else continue.
If a directory off of "p" named "mn" does not exist, fail and
return "font not found" else continue.
Oh my. As you suggest, we cannot force sites to be so rigorous about
their font names. Anyway, names like `cmr' wouldn't work.
it could take
some time for the computer (especially a moderate speed one like my
486DX2-66) to search all the directories to find the correct tfm file.
A 66MHz 486 is faster than the machines I regularly use.
It's disk speed that matters for this, anyway, not CPU speed.
I've found that searching 100-200 directories on fairly slow hardware is
acceptable. Anything over that isn't.
Someone refered to the UNIX ls -R. I tried the DOS equivalent (dir /s)
to find a random file on a 320 MB drive. It took a noticeable length of time.
No, you misunderstood (understandably enough :-). I was talking about
ls-R *the file* that my path searching code can use; see the kpathsea
documentation in any of the xdvik/dvipsk/dviljk distributions. It just
lists all the available files; thus, a program can read this file
instead of searching the actual disk. This makes access time effectively
independent of how many files or directories there are.
For the purposes of defining a directory structure, my kpathsea code is
a ``proof of concept''. It *is* possible to arrange things in
subdirectories and still have fast searches. Really. Hundreds of sites
(judging from the bug reports :-) are doing it.
I do not know of any technical reasons why DOS or VMS or any other
system could not adopt the same approach (though doubtless there are
better ways to accomplish the same result of fast searching). In fact,
web2c and my path searching code have been successfully compiled and run
on DOS, OS/2, and VMS (at least), as well as Unix.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 07:29:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 08:29:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405311229.AA19525@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RE: distribution vs. installation
reconsider a misc/ or somesuch to provide hooks for extensibility -- not
that they will necessarily ever be on any CD, but the TDS should have that
type of hook in it.
Maybe. The problem with ``hooks for extensibility'' is that oftentimes
they become a dumping ground for everything under the sun, instead of
the original problem being addressed. I would prefer that the TDS be
revised as necessary as problems come up, instead of freezing it forever.
guidelines are provided, maybe future versions of these (and other)
applications will migrate to the TDS. Historically, meaning pre-CTAN, I
George, I can see I didn't make myself clear. Sorry.
1) dvipsk and dviljk do *right now* install their fonts in the Web2c default
directory hierarchy. So they have already ``migrated''.
2) But I was hoping somehow that we could avoid the need to have the
source directory over *here* (/sources/dvipsk-NNN/fonts/...), and the
library files over *there* (/usr/local/lib/texmf/fonts/), and thus to
have to have an install script copy or link or whatever between the
two. Instead somehow for the path searching to find the fonts in the
source directory.
But as I write it like this, it seems clear it is an impossibility.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 08:57:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 09:58:17 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311358.JAA12784@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Don't drop public/
References: <9405251752.AA25411@ftp.tex.ac.uk> <9405261221.AA22295@uu3.psi.com> <9405261614.AA16509@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 26 May 1994 at 16:14:11, Sebastian Rahtz wrote:
> bob@microprograms.com writes:
> > On 24 May, Sebastian stated I was carrying the banner of many other
> > vendors. Have the rest of the vendors declined to participate? I would
> > have hoped Berthold would contribute since he has the most experience
> > of the vendors with TeX in the Microsoft Windows environment.
> i think the feeling when this group was suggested that it should be
> small, and so not everyone would be asked to join. you were obviously
> to be there, since you were working on the CD, so berthold would not
> be needed.
I appologize for having been out of touch for more than a week. Sebastian
is correct, I tried very hard to keep this group initially small. When
I feel that we basically agree (and I hope to feel that way soon--after I've
read the thirty or so messages I have pending), I'll consider adding more
commercial vendors.
I want to say again, I have no desire to keep any particular *individuals*
out of the discussion, I have only been trying to keep the *number* of
individuals managable.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 09:02:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 10:02:54 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311402.KAA12967@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
References: <199405271241.AA04571@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 27 May 1994 at 08:41:36, K. Berry wrote:
> Oh yes, and thinking of fd files, where are these going to live? With
> the LaTeX inputs (they're read by LaTeX) or with the fonts?
>
> They're read by latex, hence I think they should go in a latex
> directory. What's the advantage to having them in the font tree?
>
> Since the files aren't very big (typically two files of ~1K per font
> family) we could have both... an fd subdirectory of inputs/latex and
> an fd subdirectory of each font family.
>
> It's always better not to duplicate files if it can be avoided.
I'm still reading, so I haven't formed an educated opinion yet, but I
have to agree with Karl, duplication is *bad*. (I have this feeling that
a nice compromise could be reached with symbolic links, but that's not
practical in general...sigh....if I could add *one* feature to all file
systems...)
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 09:35:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 10:35:50 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311435.KAA14517@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405271241.AA04565@terminus.cs.umb.edu> <9405302108.AA24553@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 30 May 1994 at 17:07:19, bob@microprograms.com wrote:
> Karl comments on my tree:
> > |-tex
> > | |-language
> > | | |-<whatever>
> > | |-indexing
> > | | |-<whatever>
> >
> >It's not clear to me that either language/ or indexing/ should be
> >subdirectories of tex/. We were talking about having directories named
> >plain/, latex/, amstex/, etc. Then there would be latex/misc/makeidx.sty
> >or whatever.
This issue is still fermenting, as far as I know. I don't have enough
experience with foreign languages to offer much input myself. But I think
Karl's right about indexing, it belongs under the package...
> >
> > |-support
> > | |-<whatever>
> > |-usergrps
> > |-<group>
> > |-<whatever>
> >
> >IMO, these should be siblings of texmf, not descendants.
>
> I found two messages in this thread: one proposed support and usergrps
> as descendants of root, which was defined as "texmf"; the other as
> siblings. With our preoccupation with fonts I think we missed resolving
> this one.
I think Karl's right on this one too, at least about support. We can't really
suggest that all the applications in /support belong to TeX. Many of them
will get scattered to the four winds anyway in a non-unix installation (under
unix, they probably only get scattered to one or two winds ;-).
Usergrps is basically TeX related, so I don't see why it shouldn't be under
/texmf.
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 09:50:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 10:51:07 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311451.KAA15043@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405271241.AA04565@terminus.cs.umb.edu> <9405302108.AA24547@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 30 May 1994 at 16:59:45, bob@microprograms.com wrote:
> Not bad---as long as the site rigorously follows Karl's scheme.
> But, what if a site did not want to follow Karl's scheme, but retain
> "adobe," "minion," "times," etc.? Then the program would have to desend
> all the subdirectories under fonts until it found the correct tfm file
> or exhausted the the possibilities.
I think this is a matter of efficiency. In principle, there's nothing wrong
with searching all those directories. If it's too slow in practice, the
application should be improved (building an index seems like one (easy) way to
make it as fast as a flat structure).
As Bob suggests, you can't expect any site to follow the conventions of the
TDS religiously. I'll bet dollars to donuts that most sites will have one
exception. And one exception is too many for a "parsing" solution to
filenames---you just gotta look for the files on the path (with subdirectory
searching). If we declare that a single exception voids the whole scheme, no
one'll ever use our scheme.
> Finally, the user comes along to (La)TeX his document. All of the work
> that has gone before is transparent to him. He only sees how fast his
> computer processes the input. If the site has adopted Karl's scheme
> rigorously, it should not matter because the directory search will be
> fast. However, if the site has used a different scheme, it could take
> some time for the computer (especially a moderate speed one like my
> 486DX2-66) to search all the directories to find the correct tfm file.
> Someone refered to the UNIX ls -R. I tried the DOS equivalent (dir /s)
> to find a random file on a 320 MB drive. It took a noticeable length of time.
>
> That is the inefficiency to which I refered.
Well, I don't want to sound unreasonable, but it seems to me that the answer
is to build a better index. I'm sure that I can design and implement a fast
search algorithm for as many as 10000 files w/o more than a hundred lines of
code. The fact that "dir /s" isn't fast enough hardly surprises me. I'm more
surprised that ls-R works, actually.
I've done a lot of DOS programming, and I'm very familiar with the limitations
of the platform, but I think it was agreed early on that subdirectory
searching was a necessity in the 90's. I'm sorry that it's going to be harder
on some platforms than others (since it'll slow down acceptance of the TDS),
but I don't think we can do anything about it.
> I was discussing some of our thoughts with a heavy TeX user who lives
> near me (name omitted to protect the innocent) and his immediate and
> strong reaction was "leave the tfm files in their own directory like
> they are now". When I countered with the argument of system
> maintenance, he rejoined that the tfm files are small enough that if a
> few orphans were left around it would not bother him as much as the
> lost of speed when processing a document.
Subdirectory searching does not have to slow the system down. At most,
subdirectory searching should require only T+delta time, where T is the
amount of time required in a flat structure and delta is the amount of
time required to use an index plus the ammortized time it takes to build
the index.
Naturally, the index only needs to be constructed when new fonts are
added, so it doesn't really contribute to the time required to use the
system.
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:18:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:26:14 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311426.AA16133@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
References: <199405271241.AA04571@terminus.cs.umb.edu> <m0q74o3-000073C@csrj.crn.cogs.susx.ac.uk>
> I buy the Lucida fonts, I mount my CD-ROM to grab the Lucida-in-TeX
> stuff off the CD. What do I need? The contents of
> fonts/bandh/lucida/*, and some miscellaneous stuff in the LaTeX and
> plain TeX heirachy that I have to root around for.
>
> It's another of those times when the heirachy you want for running TeX
> is very different from the heirachy you want for distributing it.
>
this is an implementation issue for the CD (ie do we provide install
scripts). it isnt really relevant for the TDS - we need to decide
where things should live in production, not how to get them there
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:18:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:31:56 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311431.AA16195@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
References: <199405281525.AA18926@terminus.cs.umb.edu>
>
> Am I making any sense? Is there any good way to deal with this?
> In short, how to deal with fonts and other library files that are part
> of other distributions, when it's not optimal to copy them into texmf...
why cant you link
arabtex/tfm --> texmf/fonts/public/arabtex/tfm
arabtex/latex --> texmf/tex/latex/aarabtex
?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:18:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:36:09 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311436.AA16223@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: font hierarchies
References: <199405281525.AA18920@terminus.cs.umb.edu>
"K. Berry" writes:
> For small installations, I wouldn't argue with flat directories: all the
> tfm's in texmf/fonts/tfm, all the pk's in texmf/fonts/pk/<mode>, etc.
> Then path searching is no more than what every program does, because
> subdirectory searching is unnecessary.
>
> But I don't think the TDS should recommend it, because it leads to truly
> large directories. I have nothing installed but the usual free fonts and
> the TFM's for the builtin PostScript and LJ4, and that is 772 TFM files
> (56 typefaces, 255 directories). I wouldn't want to have a directory
> with 772 files. That's the whole reason I invented subdirectory
> searching for TeX in the first place.
we *have* assumed meaningful subdirectories, havent we? i think the
only dissenter is Bob, who will have to do some coding, but unless we
abandon the whole idea and say `texinputs' and `texfonts' like the old
days, the only question is whether to go fonts/tfm/times or
fonts/times/tfm (more or less). Karl assures us (as the most
experienced subdir searching code writer) that the latter is perfectly
OK for efficiency, and its easiest for maintainers, so why not stick
with it?
> As a practical matter, I hear emtex has subdirectory searching now,
> which ought to let a significant fraction of non-web2c TeX users use
> something like what we have now.
so do the web2c ports for DOS and Mac, I assume?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:19:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:42:34 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311442.AA16262@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: fd files
References: <199405281525.AA18914@terminus.cs.umb.edu> <m0q7Qiw-000076C@csrj.crn.cogs.susx.ac.uk>
> example. The stmaryrd package consists of some mf files, some tfm
> files, some pk files, an fd file, a sty file and some documentation.
> Just about the only restriction we made on distribution was that all
> these files had to be distributed together as one unit. This is
*distributed*, yes, but not *installed* as one unit, surely?
>
> Previously it's been OK to have two completely different heirachies:
> one for distribution (eg on CTAN) and one for running TeX (eg
> /usr/local/tex). But CD-ROMs rather scupper this neat division,
> because they're doing both jobs.
>
lets forget about the ORA CD for the mo. sort out the TDS, and then
tackle how to deliver on the CD
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:22:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:44:48 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311444.AA16269@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
References: <199405291515.AA26735@terminus.cs.umb.edu>
>
> view. There is not too much more needed except a broad agreement
> on the content of the basic distribution.
>
> But we're supposed to be defining the directory structure, not a common
> TeX distribution (if there can be any such thing) ... not that the
> latter is not a worthwhile goal, but it's a separate issue.
its a goal of the NTS project, now delegated to Rainer Schoepf to
action, so maybe Pierre should be putting some pressure there.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:22:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:53:40 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311453.AA16370@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405271241.AA04565@terminus.cs.umb.edu> <9405302108.AA24553@uu3.psi.com>
> > |-support
> > | |-<whatever>
> > |-usergrps
> > |-<group>
> > |-<whatever>
> >
> >IMO, these should be siblings of texmf, not descendants.
>
> I found two messages in this thread: one proposed support and
> usergrps as descendants of root, which was defined as "texmf"; the
> other as siblings. With our preoccupation with fonts I think we
> missed resolving this one.
>
`support' on CTAN is a ragbag. its stuff which TeX users might like. i
dont think we should say where such stuff goes.
usergrps should (IMHO) go in a texmf/doc tree
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 10:22:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 14:58:13 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311458.AA16407@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: agreements and disagreements
References: <199405271241.AA04565@terminus.cs.umb.edu> <9405302108.AA24547@uu3.psi.com>
> The program would parse the name.
> If a directory off of fonts named "p" does not exist, fail and return
> "font not found" else continue.
> If a directory off of "p" named "mn" does not exist, fail and
> return "font not found" else continue.
> etc.
i agree with the opinion that this is not on. either have generalized
subdir searching or none.
> fast. However, if the site has used a different scheme, it could take
> some time for the computer (especially a moderate speed one like my
> 486DX2-66) to search all the directories to find the correct tfm file.
> Someone refered to the UNIX ls -R. I tried the DOS equivalent (dir /s)
i use Karls's stuff every day on a 486/33 (under Linux) and search
time is hidden in the noise. its possible that the same code under DOS
would be slower ( i havent tried web2cpc or emtex subdir searching),
but i dont think its important.
> I was discussing some of our thoughts with a heavy TeX user who lives
> near me (name omitted to protect the innocent) and his immediate and
> strong reaction was "leave the tfm files in their own directory like
> they are now". When I countered with the argument of system
> maintenance, he rejoined that the tfm files are small enough that if a
> few orphans were left around it would not bother him as much as the
> lost of speed when processing a document.
i think one has to reassure such people that the loss of speed, if
any, just isnt noticeable in practice. anyone whos a speed freak can
preload the tfms in teh format anyway
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 11:01:24 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0q8WAx-000075C@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 31 May 94 16:56 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: latex .fd files
>this is an implementation issue for the CD (ie do we provide install
>scripts). it isnt really relevant for the TDS - we need to decide
>where things should live in production, not how to get them there
OK, as long as the TDS documentation makes it clear that it's a
directory structure for use not for distribution, fine.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 11:08:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 12:09:17 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311609.MAA19627@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
References: <199405281525.AA18926@terminus.cs.umb.edu> <9405311431.AA16195@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 31 May 1994 at 14:31:56, Sebastian Rahtz wrote:
> >
> > Am I making any sense? Is there any good way to deal with this?
> > In short, how to deal with fonts and other library files that are part
> > of other distributions, when it's not optimal to copy them into texmf...
>
> why cant you link
> arabtex/tfm --> texmf/fonts/public/arabtex/tfm
> arabtex/latex --> texmf/tex/latex/aarabtex
> ?
'Cause DOS doesn't have links... ;-(
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 11:13:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 1994 12:14:16 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199405311614.MAA19944@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Catch-up comments...
Reply-To: TWG-TDS@SHSU.edu
I think we're getting close to a final proposal---there are still some issues,
but none that seem unresolvable. Here are the major issues that have been
discussed in the last week or so, as I see them. Please let me know if I've
missed any.
On the topic of distribution vs. installation:
- The purpose of the TDS is for use, not distribution, although I don't
think these are mutuallly exclusive. We should keep distribution in mind
and try to make it easy, but there will always be packages out there that
are harder to install than they are to use. We want to make things as
easy to *use* as possible; I think this will make them as easy to install
*as possible* too.
- Assuming the TDS is widely accepted, I would recommend that authors
distribute things in a format that could be quickly installed.
Why not have a ArabTeX or StMary fonts distribution organized so that
if you are in the 'texmf' directory when you run unzip, you get the
complete installation:
$ cd /somewhere/texmf
$ unzip arabtex
Inflating doc/arabtex/arabtex.tex
Inflating fonts/public/arabtex/tfm/xxx.tfm
Inflating fonts/public/arabtex/src/xxx.mf
Inflating tex/latex/arabtex/arab.sty
Inflating tex/plain/arabtex/arab.tex
Cautious sysadmins might not choose to perform the installation this
way, without any testing, but at least it would be fairly obvious where
things belonged.
On the topic of fd files:
- The TDS cannot recommend duplication. If we were only concerned about
Unix, I would recommend /texmf/fonts/adobe/minion/fd/*.fd with symbolic
links from /texmf/tex/fd without hesitation. But alas, that's not an
option.
- I don't think they belong under /fonts. We've already argued that,
for efficiency, TeX implementors can use an index to find TFM files,
thus making a complete search of the /fonts tree unnecessary. It makes
no sense to turn around and say they've got to search it for FD files.
And I'm not going to start advocating an index for other input files
(even if some implementors provide such a thing).
- Where to put them? It seems like there are a few possibilities:
1) /texmf/tex/latex/fd/*.fd
2) /texmf/tex/latex/fd/adobe/*.fd
3) /texmf/tex/latex/fd/adobe/minion/*.fd
4) /texmf/tex/fd/*.fd
5) /texmf/tex/fd/adobe/*.fd
6) /texmf/tex/fd/adobe/minion/*.fd
The decision to go with 1-3 or 4-6 seems to rely on how likely we feel
it is that any format other than LaTeX reads the FD files. Since NFSS
(in one withdrawn ;-( configuration, at least) used to support plain,
it seems reasonable to assume it'll be used by other formats someday.
So, of the choices 1-3, I'm torn. Any suggestions?
(I don't like /texmf/tex/latex/adobe/<minion/>*.fd, but we can consider
it, I guess.)
On the topic of directory structures for fonts, we seem to be in agreement
with two exceptions:
- Bob is worried about efficiency of subdirectory searching in PC
implementations (so am I, really), but since emTeX does it painlessly (at
least I've never noticed it on my 386SX/16---but I never looked for it,
either) and no one has suggested an alternative to subdirectories that
doesn't result in hundreds, perhaps thousands, of files in each directory, I
don't think there's much we can do except suggest that implementors
use indexes.
- Two schemes have been suggested for naming within the /fonts tree
(scheme A):
/texmf/fonts/ptm/tfm/ptm*.tfm
/texmf/fonts/ptm/pk/canoncx/dpi300/ptm*.pk
and (scheme B):
/texmf/fonts/adobe/times/tfm/ptm*.tfm
/texmf/fonts/adobe/times/pk/canoncx/dpi300/ptm*.pk
I argue that the latter is easier to understand and Karl has said it's
no less efficient (a claim that seems obvious to me).
I don't want to drag this out very long, since I don't think there's
a strong technical argument in favor of either scheme, so does anyone
want to make final arguments before I don my committee chair hat and
try to force a decision ;-)
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 11:29:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 May 94 17:29:45 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9405311629.AA04961@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
I'd vote for scheme B
/texmf/fonts/adobe/times/tfm/ptm*.tfm
on fd files, I suppose the cleanest thing is to mirror the fonts tree
so that would give your choice (2 or 6) I think
/texmf/tex/latex/fd/adobe/times/*fd
or /texmf/tex/fd/adobe/times/*fd
but I'd have no objection to saving a directory layer and having
/texmf/tex/latex/fd/adobe/times/*fd
or /texmf/tex/fd/adobe/*fd
Depends how many adobe *fd files Alan and Sebastian are going to
produce, I suppose.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 16:16:55 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 31 May 1994 14:17:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405312117.OAA10264@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
It is going to be difficult to get suppliers of packages
to supply scripts for the installation from package
to texmf tree, but it will certainly be less difficult
if we have a really consistent model of the texmf tree
to suggest
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 May 1994 17:46:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 31 May 1994 15:47:03 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199405312247.PAA24647@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: distribution vs. installation
why cant you link
arabtex/tfm --> texmf/fonts/public/arabtex/tfm
arabtex/latex --> texmf/tex/latex/aarabtex
?
Because not everybody can link, alas.
I am all for Unix Cultural Imperialism, but I have to recognize
that unfortunate fact.
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 04:45:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Jun 1994 05:46:31 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406010946.AA29979@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: usergrps
Correct me if I'm wrong, but usergrps is for stuff like
meeting minutes, periodicals, I don't know what all.
But not TeX/MF input files. Hence, I don't think it
belongs in texmf, if no program is going to look for stuff in that tree.
I don't think it would be a bad idea for the tds to specifya location,
(/usr/local/doc/texmf/usergrps vs. /opt/texmf/usergrps or something?)
but it seems a separate issue from handling the real input files.
Ditto for the help and info files.
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 06:14:38 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9406011113.AA19092@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
Date: Tue, 31 May 94 16:01:15 -0400
From: bob@microprograms.com
I don't really mind subdirectories. It is just the heirachy. A further
concern (as a programmer) is that a commercial version should support
both the conventional layout (the tfms grouped together, possibily in
subdirectories) and our proposed TDS (tfms under the typeface). Users
upgrading may or may not want to spend a lot of time and effort moving
stuff around. Unless one has a neat third party utility, moving files
under MS-DOS is a real pain.
It has been my experience that a user of commercial packages want "plug
and play" installations while the same person using public domain
software is more willing to put time into configuring and maintaining the software.
Does emTeX support searching both types of directory structures?
Bob
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 06:56:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Jun 1994 07:57:23 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406011157.HAA03781@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
References: <9405311629.AA04961@r8d.cs.man.ac.uk> <9406011113.AA19092@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 31 May 1994 at 16:01:15, bob@microprograms.com wrote:
>
> Does emTeX support searching both types of directory structures?
>
Actually, if you have subdirectory searching, you automatically get support
for both approaches. If all the TFM files are in the first subdirectory
probed, then they are always found in that directory (in a time that is
identical to the more historical flat approach---modulo a few compare
instructions and branches). Furthermore, if the directory (c:/tex/fonts/tfm,
or what-have-you) contains no subdirectories, you never experience any
overhead even when the TFM files are *not* found.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 08:25:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Jun 94 12:51:54 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406011251.AA04750@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: usergrps
References: <199406010946.AA29979@terminus.cs.umb.edu>
"K. Berry" writes:
> Correct me if I'm wrong, but usergrps is for stuff like
> meeting minutes, periodicals, I don't know what all.
> But not TeX/MF input files. Hence, I don't think it
> belongs in texmf, if no program is going to look for stuff in that tree.
i guess that is a fair criterion
sebasyian
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 08:30:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 01 Jun 1994 09:30:12 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: usergrps
To: TWG-TDS@SHSU.edu
Message-ID: <770477412.357060.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
karl:
Correct me if I'm wrong, but usergrps is for stuff like
meeting minutes, periodicals, I don't know what all.
But not TeX/MF input files. ...
indeed, usergrps is for information on user groups, application
forms, notices of meetings, etc., etc. some of these may be in
the form of files to be texed. on ctan, this legitimately goes
into the tex-archive tree as at least some of the ctan sites are
also host to other, unrelated archives.
i am concluding that the tds organization will likely be *very*
different from that of the tex-archive. will someone please
correct me if i'm wrong?
the ams offerings -- ams-tex, ams-latex, fonts, ... -- have been
grouped on the ams archive node, e-math.ams.org, and on diskettes
that we offer for users who don't have network access, in such a
way that we can write a single, comprehensive set of installation
instructions for each "product" + target operating system. i know
that this causes grief for the ctan folks, and we will be discussing
possible modifications as soon as all the principal local players
are in the office. to try to support multiple configurations would
stretch our capabilities beyond their limits. (yesterday, a couple
of us tech support types spent more than two hours altogether on the
phone before discovering that one part of our installation setup
simply doesn't work under ms windows, but not because the instructions
were faulty -- a script provided for pc installation was the problem.
we don't look forward to setups that will require even more phone
support.) if anyone has suggestions on how we can "blend in" with
both the tds and ctan setups without major additional effort, we'd
love to hear them.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 09:54:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Jun 94 13:56:40 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406011356.AA05367@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
References: <199405311614.MAA19944@ruby.ora.com>
>
> 1) /texmf/tex/latex/fd/*.fd
> 2) /texmf/tex/latex/fd/adobe/*.fd
> 3) /texmf/tex/latex/fd/adobe/minion/*.fd
> 4) /texmf/tex/fd/*.fd
> 5) /texmf/tex/fd/adobe/*.fd
> 6) /texmf/tex/fd/adobe/minion/*.fd
>
> The decision to go with 1-3 or 4-6 seems to rely on how likely we feel
> it is that any format other than LaTeX reads the FD files. Since NFSS
> (in one withdrawn ;-( configuration, at least) used to support plain,
> it seems reasonable to assume it'll be used by other formats someday.
>
> So, of the choices 1-3, I'm torn. Any suggestions?
i assume we value clarity and orthogonality above all else, if in
doubt. which means 3) or 6). no sense in half measures.
6) is curiously attractive, but it means two roots on the search path
for every latex. if we have `misc' already, better misc/fd? or
misc/adobe? how about changing `misc' to `all' by the way.
> /texmf/fonts/ptm/tfm/ptm*.tfm
> /texmf/fonts/ptm/pk/canoncx/dpi300/ptm*.pk
>
> and (scheme B):
>
> /texmf/fonts/adobe/times/tfm/ptm*.tfm
> /texmf/fonts/adobe/times/pk/canoncx/dpi300/ptm*.pk
>
> I argue that the latter is easier to understand and Karl has said it's
> no less efficient (a claim that seems obvious to me).
i argued for A) on grounds of rationality. but i accept B) happliy
enough
ssebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Jun 1994 09:54:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Jun 94 14:01:35 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406011401.AA05395@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
References: <199405311614.MAA19944@ruby.ora.com> <9405311629.AA04961@r8d.cs.man.ac.uk>
> but I'd have no objection to saving a directory layer and having
> /texmf/tex/latex/fd/adobe/times/*fd
> or /texmf/tex/fd/adobe/*fd
no intrinsic virtue in saving a directory level, unless we hit the 8
on a CD
> Depends how many adobe *fd files Alan and Sebastian are going to
> produce, I suppose.
>
all of them, some day. i shall do all of the monotype tonight :-}
by the way, if we takes fonts/metrics on CTAN, we see unequivocal
Berry names, viz fonts/metrics/mnt for Monotype Times. to make life
easier, i could change this to fonts/metrics/monotype/newtimes, but
what is the algorithm for the >=8-letter names `newtimes' or `castllr'
or whatever? seems to me the names will be unpredictable, and
therefore it wont be as easy to spot duplicates. and its a pain for me
to work them all out, unless i just take the first 8 letters.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Jun 1994 11:21:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Jun 94 13:37:26 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406021337.AA24575@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: usergrps
References: <199406010946.AA29979@terminus.cs.umb.edu> <770477412.357060.BNB@MATH.AMS.ORG>
>
> i am concluding that the tds organization will likely be *very*
> different from that of the tex-archive. will someone please
> correct me if i'm wrong?
well, its still open, i guess. CTAN is happy to change its structure
to accomodate TDS if its possible. they'll probably be different, but
not from principle
> support.) if anyone has suggestions on how we can "blend in" with
> both the tds and ctan setups without major additional effort, we'd
> love to hear them.
eergh. the AMS stuff is so complicated it needs a whole new TWG
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Jun 1994 11:44:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Jun 1994 12:45:06 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406021645.MAA13868@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: usergrps
References: <199406010946.AA29979@terminus.cs.umb.edu> <770477412.357060.BNB@MATH.AMS.ORG> <9406021337.AA24575@ftp.tex.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 June 1994 at 13:37:26, Sebastian Rahtz wrote:
> >
> > i am concluding that the tds organization will likely be *very*
> > different from that of the tex-archive. will someone please
> > correct me if i'm wrong?
> well, its still open, i guess. CTAN is happy to change its structure
> to accomodate TDS if its possible. they'll probably be different, but
> not from principle
I thought that the AMS package would be a good concrete example, so I'm
in the process of organizing it into the TDS scheme. I'll post the
results when I'm done (won't be today because I'm home fighting off
a cold---see what reading The Stand has gotten me? ;-)
I have added a new directory, though, to the scheme. Comments welcome:
/texmf/doc/<package>
so that I can move AMS docs into /texmf/doc/ams.
> > support.) if anyone has suggestions on how we can "blend in" with
> > both the tds and ctan setups without major additional effort, we'd
> > love to hear them.
> eergh. the AMS stuff is so complicated it needs a whole new TWG
I'm not convinced. I've got it about 1/3 to 1/2 done and I've only found
a few things troubling (multiple files called READ.ME in different directories
that I want to move to the /doc/ directory and the distinction between files
needed by initex (modified lplain.tex, for example) and those by tex proper).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Jun 1994 12:15:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 02 Jun 1994 12:15:29 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097F599.8B3DE5C0.2927@SHSU.edu>
Subject: Re: usergrps
On Thu, 2 Jun 94 13:37:26 GMT, spqr@ftp.tex.ac.uk (Sebastian Rahtz) posted:
> > i am concluding that the tds organization will likely be *very*
> > different from that of the tex-archive. will someone please
> > correct me if i'm wrong?
> well, its still open, i guess. CTAN is happy to change its structure to
> accomodate TDS if its possible. they'll probably be different, but not
> from principle
>
> > support.) if anyone has suggestions on how we can "blend in" with
> > both the tds and ctan setups without major additional effort, we'd
> > love to hear them.
> eergh. the AMS stuff is so complicated it needs a whole new TWG
One idea I've had brewing for some time now for complex sets such as the
AMS files or those sets which include inputs as well as fonts, etc., as
recently discussed here can probably be achieved with a well-specified TDS.
Since it seems that the package is a "whole thing" (which we currently get
kinda in the right places via links), why not have the CTAN structure as
is, but add a texmf/ directory where these files are already where they
ought to be.
Conceptually, there could be a:
texmf/ams/whatever-the-AMS-wants
texmf/musictex/musictex-tree-starting-from-texmf/
etc.
This way, the files will be already located where they should be, relative
to texmf/ -- may be a few essentially null directories as musictex, for
example, would branch out to at least two levels, but everything would be
there, pre-made, pre-located.
In all (and this is an uninformed guess), I doubt that there are many
"packages" in the context of multiple branches presently, so the migration
to texmf/ should be minimal. The important thing is that the hierarchy
where the files are placed be consistent with a portable context, using a
mount point for the texmf/ tree.
Just an idea.
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Sat, 04 Jun 1994 19:31:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 04 Jun 1994 17:33:04 -0700 (PDT)
From: ELISABET@U.WASHINGTON.EDU
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
To: twg-tds@shsu.edu, unixtex@U.WASHINGTON.EDU
Message-ID: <01HD5I139S1UBESI8A@MAX.U.WASHINGTON.EDU.L>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Just one small comment re
texmf/doc/<package>
arabtex/arabdoc.tex, etc.
ams/amsguide.tex, etc.
Do we want to have another search path for texinputs?
Until now, all texinput files were searched in directories ramifying
from texmf/tex.
Additional side comment: I like the idea of having a texmf/doc directory,
but think it might be useful as a place for ready-to-print-or-view
.ps and .dvi files that authors of packages sometimes provide. For example,
Prof. Lagally provides arabdo
c.ps (the ArabTeX manual) with his distribution,
along with demo files guha.ps and omar.ps, as well as introductory text files
arabtex.faq and arabtex.doc. None of them are input files for (la)tex;
a library directory of their own seems justifiable.
TeX administrators might also favor such a directory intended as a
repository for .dvi or .ps copies of manuals/guides for installed
texmf programs and environments. May save users a bit of time and
user disk space if a <pkgdoc>.dvi were already in the t
exmf library
ready to be looked up. Users would, of course, have to be informed
of the path.
The only objection I can think of is that the texmf tree was intended
as a tree for programs to search, rather than users; in which case,
such a directory outside the texmf tree might still be useful.
The distinction between programs and users is not at all a strict one,
of course; it's just that I'm wondering aloud whether or not the sources
for, say, amsguide.dvi should be moved from texmf/tex/ams/amst
ex/doc or
texmf/tex/amstex/doc, to be placed instead in texmf/doc/ams. It used
to be the case that the input files currently in AMS's amstex/doc and
in ArabTeX's arabtex/report remained in the src tree and never entered
the installation tree; but since the original function of the Berry/MacKay
texmf installation tree has been changing, and we are trying to find a
place for source files for program manuals to roost in the texmf tree,
I thought it might be worth asking whether we wanted another inputs
search path.
Apart from that, I do favor a place in the TDS system for ready-to-use
documentary files -- such as amsguide.dvi or amsguide.ps --
for programs and program environments that are installed in the texmf tree.
That's all,
--Elizabeth
================================================================================
From owner-twg-tds@shsu.edu Sat, 04 Jun 1994 20:10:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 04 Jun 1994 21:10:54 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
To: TWG-TDS@SHSU.edu
Message-ID: <770778654.818998.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i like elizabeth's idea to have a separate documentation area with
ready-to-print .ps files, but i have a couple of problems. i hope
someone can solve them.
consider the documentation for the amsfonts package. it's called
userdoc.* which makes no sense out of the context of an /ams/amsfonts
area. okay, the name can be changed to, say, amsftdoc.*, which is
cryptic, but decipherable. but i've got a bigger problem. this
documentation uses nearly all of the distinct fonts in the amsfonts
package (in 10pt only), and can't be printed without them. to render
the .ps file printable without installing the fonts, i believe that
the fonts have to be packaged in the .ps file. at what resolution?
300dpi is probably the most common, but i sure wouldn't want to put
money on it.
perhaps we should separate the installation instructions from the
user manual (they're now an appendix, which most dvi translators
would permit to be selected by page span; this doesn't ask for any
of the amsfonts, just good old cm*). that avoids having to include
the additional fonts, but it still doesn't solve the resolution
problem.
suggestions, please ...
-- bb
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 01:55:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Jun 94 21:52:37 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406052152.AA19926@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
References: <01HD5I139S1UBESI8A@MAX.U.WASHINGTON.EDU.L> <770778654.818998.BNB@MATH.AMS.ORG>
i think the resoution problem is an illusion. put in 300 dpi pk
bitmaps, and 600 or 400 dpi printers will still work, even if not
looking optimum.
i'd assumed per package subdirectories under doc/? so the meaningless
(as it were) names dont matter.
and i don't think we should get *too* hung up on the texmf root being
searched by programs only. i dont see any harm in texmf/doc at all, it
seems a rational place to put the stuff being discussed
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 02:01:03 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 5 Jun 1994 21:22:23 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406060422.VAA02953@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Catch-up comments...
CC: mackay@cs.washington.edu
So long as we are talking about PostScript documentation, we can
use 300dpi. There are virtually no hardcopy devices with postscript
interpreters which use a smaller resolution, and 300dpi will print
on 400dpi 600dpi and 1000dpi to my certain knowledge. It doesn't
look as good as the native resolution but it works. This adaptability
is one of the real strengths of PostScript, and Rokicki's PostScript
includes all the required parameters for the interpreter to get it right.
Does anyone have experience to contradict this view?
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 07:30:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Jun 1994 06:30:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406051030.AA19302@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: texmf: for programs or humans?
I have added a new directory, though, to the scheme. Comments welcome:
/texmf/doc/<package>
There is a generic question: is the stuff under texmf/ supposed to be
for programs to look at, or for humans? I have referred to this several
times as the former, but I'm not sure everyone agrees.
If it's for programs, doc/ should not be there.
I prefer to think of it for programs, as the ``library files''. Not as
a distribution tree. Thus, the
documentation/help/info/usrgrps/support/whatever directories as siblings.
If texmf is /usr/local/lib/texmf, then I would have /usr/local/bin/texmf
(or just /usr/local/bin/{tex,mf,bibtex,...}, /usr/local/src/texmf,
/usr/local/doc/texmf, etc.
If texmf is /opt/texmf/lib, then I would have /opt/texmf/bin,
/opt/texmf/doc, /opt/texmf/src, etc.
I see c:\texmf as the moral equivalent of /opt/texmf, thus would have
c:\texmf\lib\fonts\..., c:\texmf\doc, etc.
So. What do you all think?
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 07:30:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Jun 1994 12:00:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406051600.AA20376@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: packages and their docs
texmf/doc/<package>
arabtex/arabdoc.tex, etc.
ams/amsguide.tex, etc.
Do we want to have another search path for texinputs?
The doc sources don't have to be in the TeX search path, imho.
Until now, all texinput files were searched in directories ramifying
from texmf/tex.
Yes, that's the question. It is a big change, no doubt about it. But it
might be worth it. I think it's technically feasible, though I can't say
I've actually tried it. I can't see why it would be much worse to search
texmf//tex than texmf/tex//.
Then the doc files would wind up in places like
texmf/arabtex/doc/...
(still not in TEXINPUTS).
user disk space if a <pkgdoc>.dvi were already in the texmf library
ready to be looked up. Users would, of course, have to be informed
Do path searching for DVI files?
Gosh. I guess we could, but nothing except Nelson's drivers do now.
The only objection I can think of is that the texmf tree was intended
as a tree for programs to search, rather than users; in which case,
such a directory outside the texmf tree might still be useful.
Yes, I agree. This was my argument earlier this morning for doc/ and the
like being siblings of the texmf/ cum. lib/ directory, not under it.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 07:30:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Jun 1994 06:30:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406051030.AA19308@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: texmf/ams and other packages
George has an interesting idea (though I don't follow everything he says):
Conceptually, there could be a:
texmf/ams/whatever-the-AMS-wants
texmf/musictex/musictex-tree-starting-from-texmf/
etc.
This way, the files will be already located where they should be, relative
to texmf/ -- may be a few essentially null directories as musictex, for
This is interesting because texmf/ams could be a symlink to (say)
/packages/amstex-2.8, and you could have multiple versions of amstex
active easily. This is exactly what I was trying to do before.
Let's see where this leads.
If we have texmf/ams/fonts/pk/cx/cmr10.300pk, texmf/ams/tex/amstex.tex,
etc., then we have to specify a PKFONTS (say) of texmf//fonts//pk//, a
TEXINPUTS of texmf//tex, etc. Basically, we'll wind up searching all the
children of texmf for input files.
Basically, this inverts the tree. Instead of
<root>/<file-format>/<package>, it's <root>/<package>/<filefmt>.
This might be good.
One niggle is that not all the fonts (or TeX input files, or MF input
files) are in one easily-found (by humans) place. Thus, it is harder to
know what you've got. But this is probably acceptable.
If we're going to cast some things into this mold, what would happen if
we try to do everything like this? For example, if instead of having
texmf/tex/plain/plain.tex, we have texmf/knuth/tex/plain.tex,
texmf/knuth/fonts/cm, etc. You could consider *everything* as coming
from some package or another. dvips would be
texmf/dvips/fonts/tfm/ptmr.tfm, texmf/dvips/latex/epsf.sty, etc. (I
guess binary executables have to be treated specially somehow.)
Another thought along these lines: someone suggested that the AMS (and
similar folks) distribute their stuff as
texmf/fonts/ams/...
texmf/tex/ams/...
i.e., in the positions we're constructing for them in the TDS.
I disagree with this *vehemently*. I strongly believe the only
reasonable way to do distributions is to have them unpack into a
*single* directory <package>[-<version>], e.g., gcc-2.5.8. Some
distributions (like the current ams ones) omit the version number, which
I find annoying, but easy to work around: I just have to remember to mv
amstex to amstex-2.1 after unpacking. But if something unpacked into
many sibling directories, it would be extremely difficult and painful to
track the different versions.
What we've been doing up to now is providing installation scripts or
Makefiles or instructions to copy stuff from the distribution hierarchy
to the installation one.
But the beauty of George's idea is that wouldn't be necessary
(necessarily :-). You can just unpack your amstex.tar.gz in
/usr/local/lib/texmf. It unpacks into (say) amstex-2.1/tex/... and so
forth. Boom. You are done.
I think I might like this. I think I might like this a lot.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 07:30:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Jun 1994 12:00:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406051600.AA20370@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: ams doc distribution
consider the documentation for the amsfonts package. it's called
userdoc.* which makes no sense out of the context of an /ams/amsfonts
area. okay, the name can be changed to, say, amsftdoc.*, which is
cryptic, but decipherable. but i've got a bigger problem. this
We all want to avoid cryptic names where possible.
If we adopt George's suggestion, the package-specific documentation
could wind up texmf/amstex/doc (or whatever).
In the current scheme, you could have doc/ams/fontdoc.* or
something. There's no need for documentation files to have unique names!
(Which reminds me, I wanted to mention that `README' is far more common,
and simpler and less painful than `READ.ME'. But never mind, we can
discuss the ams distribution in a different forum :-)
the .ps file printable without installing the fonts, i believe that
the fonts have to be packaged in the .ps file. at what resolution?
300dpi is probably the most common, but i sure wouldn't want to put
money on it.
Yes, the bitmap fonts have to be in the .ps files. The most common
resolutions I know about are 300 and 600. You can't provide a PS file
that will work for every possible printer, after all (unless you use
Times-Roman, but then you screw the non-PostScript folks). It doesn't
even matter that much -- all that will happen when you use a wrong
resolution printer is the bitmap fonts will be scaled and maybe a couple
pixels off in strange spacing cases. I guess this would argue for 600,
if you're only going to do one -- 600 will scale down to 300 ``better''
than the reverse, in my experience.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 08:12:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 06 Jun 1994 09:11:59 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: texmf/ams and other packages
To: TWG-TDS@SHSU.edu
Message-ID: <770908319.897783.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
a comment on version numbers.
i don't think we'd have any problem *in principle* with marking
the ams files with the version number, as amstex-2.1, etc.
but there's a big objection *in practice*. we have constructed
the names so that everything is usable on *any* operating system
likely to be in use (thank goodness we no longer have to cope
with the sail 6+3 restriction!).
"amstex-2.1" violates the dos 8-character limit, and furthermore,
"amsppt-2.1.sty" is an impossibility in every os that i know
about except for unix. (i don't believe we should be unix-centric
any more than dos-centric, but it's a fact that dos-compatible
names will work under unix whereas the opposite is not true.)
i know -- i'd rather have longer, more scrutable names, but we
get many support calls from people using dos with no network
access. it's *very* much easier for us if we don't have to
remember different naming conventions for different installations.
the version information is right there in the headers of (almost)
every file (not binaries, of course, and not in a few files that
were generated by, e.g., bibtex, and are present to be checked
against the result of similar operations by the user). when we
get calls, we ask the user to type the file out and let us know
what the header says. doesn't make any difference what system.
we can always follow the same procedure.
by the way, i don't know how to add a header to a .ps file -- can
anybody help? or should .ps versions of the documentation *not*
carry such headers?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 09:29:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Jun 94 13:35:16 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406061335.AA02570@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
References: <199406051030.AA19302@terminus.cs.umb.edu>
> There is a generic question: is the stuff under texmf/ supposed to be
> for programs to look at, or for humans? I have referred to this several
> times as the former, but I'm not sure everyone agrees.
>
i am not sure what it really matters?
> If texmf is /usr/local/lib/texmf, then I would have /usr/local/bin/texmf
> (or just /usr/local/bin/{tex,mf,bibtex,...}, /usr/local/src/texmf,
> /usr/local/doc/texmf, etc.
>
> If texmf is /opt/texmf/lib, then I would have /opt/texmf/bin,
> /opt/texmf/doc, /opt/texmf/src, etc.
>
> I see c:\texmf as the moral equivalent of /opt/texmf, thus would have
> c:\texmf\lib\fonts\..., c:\texmf\doc, etc.
>
i favour keeping all our stuff to a single tree, except where there
are standards, of which the only relevant ones here are the `info' and
`man' directories. i hate these bits of software that force me to have
root privileges for no good reason
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 09:30:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Jun 94 13:59:30 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406061359.AA02836@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/ams and other packages
References: <199406051030.AA19308@terminus.cs.umb.edu>
er, this is getting rather radical, everything descending from
texmf/<package>. But I like it too, *if* Karl really does think that
texmf//tex is going to be efficient enough, and the emtex subdir
searching permits this
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 12:52:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 06 Jun 1994 12:52:18 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: BNB@MATH.AMS.ORG
Message-ID: <0097F8C3.599112E0.2957@SHSU.edu>
Subject: Re: texmf/ams and other packages
On 06 Jun 1994 09:11:59 -0400 (EDT), bbeeton <BNB@MATH.AMS.ORG> posted:
> by the way, i don't know how to add a header to a .ps file -- can anybody
> help? or should .ps versions of the documentation *not* carry such
> headers?
The PostScript comment character is "%", so a header of
% this is header material
% and this is more
% still more
[the PS file]
should work fine. I know Nelsons' filehdr and my tpuhdr work on this
principle and I have created, distributed, and used files using this
convention.
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Jun 1994 15:11:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Jun 1994 16:12:19 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406062012.QAA26470@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Does /texmf only contain TeX inputs?
References: <01HD5I139S1UBESI8A@MAX.U.WASHINGTON.EDU.L>
Reply-To: TWG-TDS@SHSU.edu
[ I'm replying to Elizabeth's message, but several other messages today
echoed this sentiment... ]
On 4 June 1994 at 17:33:04, ELISABET@U.WASHINGTON.EDU wrote:
> The only objection I can think of is that the texmf tree was intended
> as a tree for programs to search, rather than users; in which case,
> such a directory outside the texmf tree might still be useful.
That isn't precisely my vision of the TDS. The goal, as I understand it,
is to create an architecture/implementation independent TeX hierarchy.
As such, we aren't bound to put only input files in the hierarchy (certainly
the documentation for most packages is largely implementation independent).
When the notion of sibling directories (/texmf, /texdoc, /whatever) was
initially broached, I thought I agreed, but I've changed my mind.
I think that /texmf/tex should only be for TeX to search; similarly
/texmf/fonts should only be for MF and other font-using programs. However,
I think that "/texmf" is for both users *and* programs.
In that light, I think that putting documentation under
/texmf/doc
is perfectly reasonable. I propose that
/texmf/doc/<package>/*
be used for any package that includes enough documentation to warrant it.
I know that this spreads things around (moving different parts of a
distribution away from each other), but I don't see any better alternative.
Do you?
I've never felt that README files, user documentation, etc. belonged in
the directories that TeX was searching for input files anyway.
I know that some of you disagree, so convince me I'm wrong ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 07:48:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Jun 1994 08:48:25 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406071248.AA12656@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
I know that some of you disagree, so convince me I'm wrong ;-)
OK, I'll try :-)
There are sources, binaries, library files, and documentation files.
The TDS isn't going to say anything about where the first two go
(right?), and it *is* going to say something about library files (that's
the whole point, so implementors have a target to shoot for), and we're
debating if it's going to say something about the fourth. But it's a
different category, and I don't think we've settled on all the library
file issues yet.
I'll say it again: I don't think the TDS should specify that doc/ as a
sibling directory of fonts/, mf/, tex/, etc. That could mean either
/opt/texmf/lib/tex and /opt/texmf/doc, or it could mean
/usr/local/lib/texmf and /usr/local/doc/texmf, or it could mean the
documentation stays in the source distribution directories, or whatever.
It's useless to mandate standards for something that is legitimately
different at different sites. Man files at site A may be
/usr/local/texmf/man/man1/tex.1. Man files at site B may want to go in
/usr/local/man/man1/tex.1. Both these choices work fine. Neither is
clearly better than the other. Existing sites use both
methods. Therefore, there is no point in specifying one or the other as
preferred in a standard.
I don't think an implementation/distribution/site should be a
``non-conforming'' site simply because they don't want to put the many
megabytes of documentation into the same place as the fonts and other
files that are *required* for an operational TeX. Documentation is not
*required*. There might not be enough space in the partition for all the
documentation, just for the library files.
If we adopt the texmf/<package>/{tex,fonts,latex,...} scheme that has
been broached in the last few days, then this whole discussion is moot,
because `doc' would clearly be in the `...' (whether or not the tds
should actually specify this is a different question, and not one that
needs to be address now).
Thus, I'd like to hear more reactions to that; it's certainly a much
larger change than anything else contemplated up to now. But I think it
has a much better chance of keeping up with the world. As people
implement major packages, like arabtex or latex or amstex or whatever,
as TeXophiles we should be striving to make those significant additions
to the TeX world as easy to possible to install and maintain, not
consider them as exceptions to the rule of small, one or two file,
single-format hacks.
texmf/<package>. But I like it too, *if* Karl really does think that
texmf//tex is going to be efficient enough, and the emtex subdir
I already hypothesized on the efficiency issue. The proof will be when
someone actually tries it. I can't do that right now; I want to finish
implementing runtime config files and the rest. So I hope someone else
can experiment with it.
searching permits this
I've never used emtex, so I can't answer this. It would be a strange
implementation method if it only allowed subdir searching in certain
predefined unchangeable places, though.
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 15:39:42 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 13:40:10 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406072040.NAA12563@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: texmf: for programs or humans?
/texmf/doc/<package>
I like this. For the initial read off whatever archival medium
is used, it puts the documentation out where it can be seen. Since
it will be very much better not to complicate our present work
with questions of path searching into .//doc, accepting this
location for the directory simply bags the question of whether
texmf/* should be only for program searching. My prejudice in this
matter is based on the fact that I recently put together a package
rooted exclusively in texmf, with the hope that it would make it possible
to extract the entire package into /opt on a Solaris machine, add
/opt/texmf/bin to the path, and run. It worked.
There is a generic question: is the stuff under texmf/ supposed to be
for programs to look at, or for humans? I have referred to this several
times as the former, but I'm not sure everyone agrees.
If it's for programs, doc/ should not be there.
[ I prefer to think of it for programs, as the ``library files''. Not as
a distribution tree. Thus, the
documentation/help/info/usrgrps/support/whatever directories as siblings.
But this seems to be an argument {\em against} texmf/doc.]
If texmf is /usr/local/lib/texmf, then I would have /usr/local/bin/texmf
(or just /usr/local/bin/{tex,mf,bibtex,...}, /usr/local/src/texmf,
/usr/local/doc/texmf, etc.
??????????????
If texmf is /opt/texmf/lib, then I would have /opt/texmf/bin,
/opt/texmf/doc, /opt/texmf/src, etc.
That makes two entirely different divisions of the material, like the
wretched questions of whether it is /usr/include/X11 or /usr/X11/include
of /usr/openwin/include.
Why introduce the lib at all. I see texmf as the moral equivalent of
lib/texmf. I don't really care whether texmf is extracted into
/usr/local /usr/local/lib or /opt. Avoiding the question for now
of whether doc/ really belongs,
texmf/bin/
texmf/tex/
texmf/mf/
texmf/fonts/
texmf/doc/
texmf/*/ seems to have a lot going for it.
We want to keep to the iso-9660 limits {\em if possible} and the introduction
of a directory lib/ between texmf/ and fonts/ is going to make that all the
more difficult. There will probably be many who don't want an extra
element in the path to executables, but they can copy the contents of
texmf/bin to some other directory.
In a Solaris environment, /opt/texmf/src looks like a gread idea too.
(And I am still not sure whether I even l
I see c:\texmf as the moral equivalent of /opt/texmf, thus would have
c:\texmf\lib\fonts\..., c:\texmf\doc, etc.
????
Again, why the lib?
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 15:39:45 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 13:40:10 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406072040.NAA12563@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: texmf: for programs or humans?
/texmf/doc/<package>
I like this. For the initial read off whatever archival medium
is used, it puts the documentation out where it can be seen. Since
it will be very much better not to complicate our present work
with questions of path searching into .//doc, accepting this
location for the directory simply bags the question of whether
texmf/* should be only for program searching. My prejudice in this
matter is based on the fact that I recently put together a package
rooted exclusively in texmf, with the hope that it would make it possible
to extract the entire package into /opt on a Solaris machine, add
/opt/texmf/bin to the path, and run. It worked.
There is a generic question: is the stuff under texmf/ supposed to be
for programs to look at, or for humans? I have referred to this several
times as the former, but I'm not sure everyone agrees.
If it's for programs, doc/ should not be there.
[ I prefer to think of it for programs, as the ``library files''. Not as
a distribution tree. Thus, the
documentation/help/info/usrgrps/support/whatever directories as siblings.
But this seems to be an argument {\em against} texmf/doc.]
If texmf is /usr/local/lib/texmf, then I would have /usr/local/bin/texmf
(or just /usr/local/bin/{tex,mf,bibtex,...}, /usr/local/src/texmf,
/usr/local/doc/texmf, etc.
??????????????
If texmf is /opt/texmf/lib, then I would have /opt/texmf/bin,
/opt/texmf/doc, /opt/texmf/src, etc.
That makes two entirely different divisions of the material, like the
wretched questions of whether it is /usr/include/X11 or /usr/X11/include
of /usr/openwin/include.
Why introduce the lib at all. I see texmf as the moral equivalent of
lib/texmf. I don't really care whether texmf is extracted into
/usr/local /usr/local/lib or /opt. Avoiding the question for now
of whether doc/ really belongs,
texmf/bin/
texmf/tex/
texmf/mf/
texmf/fonts/
texmf/doc/
texmf/*/ seems to have a lot going for it.
We want to keep to the iso-9660 limits {\em if possible} and the introduction
of a directory lib/ between texmf/ and fonts/ is going to make that all the
more difficult. There will probably be many who don't want an extra
element in the path to executables, but they can copy the contents of
texmf/bin to some other directory.
In a Solaris environment, /opt/texmf/src looks like a gread idea too.
(And I am still not sure whether I even l
I see c:\texmf as the moral equivalent of /opt/texmf, thus would have
c:\texmf\lib\fonts\..., c:\texmf\doc, etc.
????
Again, why the lib?
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 15:45:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 13:45:58 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406072045.NAA13149@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
Sebastian makes a very good point about root privileges. Every
foray into root is pregnant with possible disaster, and the more
we can avoid it (e.g. texmf/bin left as is) the better.
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 15:50:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Jun 94 20:44:37 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406072044.AA02097@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
References: <199406072045.NAA13149@june.cs.washington.edu> <9406061335.AA02570@ftp.tex.ac.uk>
Pierre MacKay writes:
> Sebastian makes a very good point about root privileges. Every
> foray into root is pregnant with possible disaster, and the more
> we can avoid it (e.g. texmf/bin left as is) the better.
i have found myself on more than once occasion installing Tex as a
guest user; the real sys person is happy to establish a single root
point owned by me which will have all of TeX, but doesn want to give
random permissions all over the shop. it really is so much easie to
have a single texmf/, with its own bin and doc. someone later can move
the bin/* is they like.
i think we can get too Unix purist about this; its a TDS for everyone,
and most people wont have any religious ideas one way or the other
about what `lib' should or should not mean. i think its likelier they
will want all of TeX isolated in a single place
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 15:56:42 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 13:57:15 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406072057.NAA14501@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
You give one more good reason for texmf/doc
I wonder if it would be possible to send out a template
for contributions, so that splitting tex/ fonts/ and doc/
across a texmf/ root is made as easy as possible.
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 18:23:51 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 16:24:24 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406072324.QAA08047@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: ISO-9660 directory levels
Has it occurred to any one else, as it just has to me,
that if everything is rooted in texmf/ after installation,
there is no need for a texmf/ on a CD-ROM. That frees
up one level of directory specification. Not that we
have to go out and find something to put in that
level just because it is there, but it is nice not
to be pushing the limits quite so relentlessly.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 19:09:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Jun 1994 20:09:47 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406080009.UAA11817@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
References: <199406062012.QAA26470@ruby.ora.com> <199406072057.NAA14501@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 7 June 1994 at 13:57:15, Pierre MacKay wrote:
> I wonder if it would be possible to send out a template
> for contributions, so that splitting tex/ fonts/ and doc/
> across a texmf/ root is made as easy as possible.
Could you expand on that? I'm not sure what you mean...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 19:22:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Jun 1994 20:22:43 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406080022.UAA12557@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: ISO-9660 directory levels
References: <199406072324.QAA08047@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 7 June 1994 at 16:24:24, Pierre MacKay wrote:
> Has it occurred to any one else, as it just has to me,
> that if everything is rooted in texmf/ after installation,
> there is no need for a texmf/ on a CD-ROM. That frees
> up one level of directory specification. Not that we
> have to go out and find something to put in that
> level just because it is there, but it is nice not
> to be pushing the limits quite so relentlessly.
I thought of it (actually, I miscounted the texmf/fonts/.../pk/mode/dpi/foo.pk
levels and lay awake worrying one night ;-)
I fear that there may be things on a CD that *don't* belong in /texmf (like
the CD copyright gibberish and associated READMEs) so I'm inclined to leave
that level in unless it's torn away by force.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Jun 1994 22:39:49 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 7 Jun 1994 20:40:19 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406080340.UAA13723@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
At present the content of contributions, particularly
language-related contributions like arabtex, or my own
ibygrk, go out with a directory structure that may or
may not be reasonably similar to what we are trying to
set up.
If we can decide on what the minimum lot of branches under
texmf/ are, it should be possible to suggest through
texhax and info-tex something like the following
<package>/
/doc/<packagename>/*[tex.dvi,ps],README(s)
/src/<packagename>/*.[c,h] etc.
/tex/<packagename>/*.[tex,sty]
/fonts/ . . .
and so on.
src/ would probably be moved somewhere else entirely, but
if the template were well designed, a simple script could
spread doc/ tex/ and fonts/ across a texmf/root cleanly and
quickly.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 06:47:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 07:47:33 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406081147.AA24794@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
<package>/
I don't follow the need for this top-level <package>/ directory?
/doc/<packagename>/*[tex.dvi,ps],README(s)
/src/<packagename>/*.[c,h] etc.
/tex/<packagename>/*.[tex,sty]
/fonts/ . . .
(Or maybe it's that I don't follow the need for this subsidiary
<packagename>/ directory.)
and so on.
src/ would probably be moved somewhere else entirely, but
if the template were well designed, a simple script could
spread doc/ tex/ and fonts/ across a texmf/root cleanly and
quickly.
If we use texmf/<package>/{src,fonts,tex,doc,...}, and that is how the
distributions come (as they often do, or could), no installation script
would be needed at all, thus the (modern Unix) installer would not have
to have two copies of all the library/documentation/tex input files --
just symlink texmf/dvips to, say, /the/source/dir/dvipsk-5.67a.
We change the default paths so that they search texmf//tex// instead of
texmf/tex// (and so on), and away you go.
This will lose for an existing installation that uses the current
scheme, but doesn't use ls-R, because it will end up looking at (say)
texmf/fonts/*/* for a `tex' directory. But I think the initial pain will
be worth it in the long run, because new packages will be so much easier
to deal with. If Mattes and the other TeX distributors agree to this, so
that we all eventually converge on it, then I think it will succeed.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 06:47:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 07:47:33 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406081147.AA24787@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
(1) If texmf is /usr/local/lib/texmf, then I would have /usr/local/bin/texmf
(or just /usr/local/bin/{tex,mf,bibtex,...}, /usr/local/src/texmf,
/usr/local/doc/texmf, etc.
??????????????
(2) If texmf is /opt/texmf/lib, then I would have /opt/texmf/bin,
/opt/texmf/doc, /opt/texmf/src, etc.
That makes two entirely different divisions of the material, like the
wretched questions of whether it is /usr/include/X11 or /usr/X11/include
of /usr/openwin/include.
I don't follow what the ``this'' is.
(1) and (2) (I added the numbers for this msg) above are mutually exclusive
organizations. A site will do one or the other. I don't think the TDS
should (or can) force one, because there may be local administrative
reasons why one is preferable.
Again, why the lib?
Because you might not have enough disk space to store all the
documentation, sources, and binaries in one partition. Just the library
files. I think making it easy to separate the files that are *necessary*
to run from the files which are not is a win. (See my message yesterday
for details.)
texmf/bin/
You can't just have one bin at many sites, where multiple architectures
are supported. Something trickier has to happen. Local admins have
probably already dealt with the problem, either by using /usr/local/bin
or by using the automounter or symlinks or something. The TDS cannot
make that decision for them.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 07:38:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 08:38:26 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081238.IAA23191@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: texmf/<filetype>/<package> vs. texmf/<package>/<filetype>
Reply-To: TWG-TDS@SHSU.edu
On 7 June 1994 at 08:48:25, K. Berry wrote:
>
> texmf/<package>. But I like it too, *if* Karl really does think that
> texmf//tex is going to be efficient enough, and the emtex subdir
> searching permits this
There is a certain logic to inverting the order of <filetype> and
<package>, but I have some reservations:
- It's a radical departure from what everyone does now.
[ devils advocate: what's wrong with being radical? ]
- It scatters similar files all over the place. Fonts are now in
a whole bunch of directories.
[ da: so what? It moves *packages* back together ]
- It complicates subdirectory searching. I'm already worried that we
will have trouble convincing commercial implementors to do subdir
searching. I think we can argue that it's *necessary* so I'm willing
to put up the fight.
On the other hand, this scheme requires *a lot* more searching *or* a
more sophisticated searching algorithm.
[ da: with an ls-R file, this is a moot point, so stop worrying ]
Consider the difference between
TEXINPUTS=/texmf/tex/latex//:/texmf/tex/latex209:/texmf/tex/plain//
and
TEXINPUTS=/texmf/latex//:/texmf/latex209//:/texmf/plain//
Whereas KB can do TEXINPUTS=/texmf//tex//, that's more complex than
simple subdir searching.
- It moves the documentation and other non input files right back into
the way of the path searching algorithm.
[ da: so what? ]
- It really clutters up the top level /texmf directory with a lot of
directories.
[ da: no it doesn't, it makes the top level really clear; everything's
a package. ]
Gulp. I started this message firmly opposed and now I'm not so sure...
I'll try rearranging some of the /tex tree here and see what I get.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 07:42:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 08 Jun 1994 07:42:24 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@SHSU.edu
Message-ID: <0097FA2A.63569C60.2993@SHSU.edu>
Subject: Bob Harris may be off-line
Just for the record, some mail recently on the list to Bob Harris has
just bounced back.
--George
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 07:57:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 08:57:19 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081257.IAA23621@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: texmf/<package>/<filetype>
Reply-To: TWG-TDS@SHSU.edu
For packages, is the full tree under this scheme something like this?
texmf/<package>/fonts/<typeface>/...
texmf/<package>/tex/<format>/...
texmf/<package>/src/*
texmf/<package>/doc/*
texmf/<package>/<whatever else the author wants?>
Does this mean we'll have directories like all these?
texmf/plain/fonts/cm/src
texmf/plain/fonts/cm/pk/<mode>/<dpi>/<files>
texmf/plain/tex/plain/*
texmf/latex/fonts/cm/src
texmf/latex/fonts/cm/pk/<mode>/<dpi>/<files>
texmf/latex/tex/latex/*
{ assuming someone will/has added input files for the YH's gothic fonts }
texmf/gothic/fonts/gothic/src
texmf/gothic/fonts/gothic/pk/<mode>/<dpi>/<files>
texmf/gothic/tex/latex/gothic.sty
texmf/gothic/tex/plain/gothic.tex
And we still have a fonts tree for just fonts:
texmf/fonts/adobe/courier/afm
texmf/fonts/adobe/courier/pfa
texmf/fonts/adobe/courier/pk/ps2pk/<dpi>/<files>
Or is this now:
texmf/adobe/fonts/courier/afm
texmf/adobe/fonts/courier/pfa
texmf/adobe/fonts/courier/pk/ps2pk/<dpi>/<files>
If we use texmf/fonts/adobe (as I'm inclined to), we'll have the problem
of a package (like ljmetrics) that should be
texmf/fonts/ljmetrics/tfm ...
but might become
texmf/ljmetrics/fonts/tfm
texmf/ljmetrics/tex/latex/ljfonts.sty
texmf/ljmetrics/tex/plain/ljfonts.tex
if I add some style files. Do we want to start with texmf/ljmetrics/fonts
initially to avoid having this problem someday?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 08:40:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 09:41:07 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081341.JAA25066@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Sample texmf/<package> listing...
Reply-To: TWG-TDS@SHSU.edu
I took the /usr/local/lib/tex tree on our system and reorganized it
according to the texmf/<package> style. I may have messed a few things
up, I haven't actually tried to use it in this form yet.
Also, our fonts are in /usr/local/lib/fonts so they aren't in here yet,
but I think this'll give the flavor.
./texmf:
DraTeX
README
Xfonts
amstex
arabtex
biblio
bin
cweb
dvips
eplain
fontinst
hebrew
ini
knuth
latex
latex209
latex2html
lollipop
ls-R
mainze
man
misc
modes
musictex
nfss2
norm
psfig
pstricks
seetex
texinfo
tugboat
xet-ini
./texmf/DraTeX:
tex
./texmf/DraTeX/tex:
latex
./texmf/DraTeX/tex/latex:
AlDraTex.sty
AlProTex.sty
DraTex.sty
Examples.tex
ProTex.sty
./texmf/Xfonts:
cmbx12.120.pcf
cmbx12.173.pcf
cmbx12.207.pcf
cmmi10.100.pcf
cmmi7.100.pcf
cmr10.100.pcf
cmr10.300.pcf
cmr12.300.pcf
cmr7.100.pcf
cmsy10.100.pcf
cmsy7.100.pcf
cmti10.100.pcf
fonts.dir
./texmf/amstex:
doc
tex
./texmf/amstex/doc:
00Contents
READ.ME
amsguide.tex
amsppt.doc
amstex.bug
amstinst.tex
joyerr.tex
./texmf/amstex/tex:
amslatex
amstex
contrib
ini
./texmf/amstex/tex/amslatex:
amsppt.sty
./texmf/amstex/tex/amstex:
amsppt1.tex
amssym.tex
amstex.tex
./texmf/amstex/tex/contrib:
00Contents
amstexsiam.sty
imappt.sty
imapptdoc.tex
jfpppt.sty
lncsppt.sty
review.sty
review.tex
sample.tex
siamdoc.tex
springer
xppt
./texmf/amstex/tex/contrib/springer:
00Contents
amamult
jnsa
./texmf/amstex/tex/contrib/springer/amamult:
00Contents
amamult.cmm
amamult.dem
amamult.doc
read.me
./texmf/amstex/tex/contrib/springer/jnsa:
00Contents
jnsa.dem
jnsa.doc
jnsams.cmm
read.me
./texmf/amstex/tex/contrib/xppt:
00Contents
Makefile
README
TRAILER
pptfixes.doc
pptfixes.tex
xfixed.doc
xfixed.tex
xlatin1.doc
xlatin1.tex
xppt.doc
xppt.sty
xppt.tex
xppta.bst
xpptabc.doc
xpptb.bst
xpptc.bst
xrcs.doc
xrcs.tex
./texmf/amstex/tex/ini:
amstex.ini
./texmf/arabtex:
bin
doc
tex
./texmf/arabtex/bin:
mls2arab
./texmf/arabtex/doc:
arabdmac.tex
./texmf/arabtex/tex:
fd
latex
plain
./texmf/arabtex/tex/fd:
unash~aa.fd
./texmf/arabtex/tex/latex:
abjad.sty
aedpatch.sty
afonts.sty
alatex.sty
aligs.sty
aparse.sty
apatch.sty
arabsymb.sty
arabtex.sty
ascan.sty
asmo449.sty
atrans.sty
awrite.sty
etrans.sty
iso88596.sty
nashbf.sty
oldarabt.sty
twoblks.sty
./texmf/arabtex/tex/plain:
arabtex.tex
./texmf/biblio:
bst
./texmf/biblio/bst:
abbrv.bst
alpha.bst
plain.bst
unsrt.bst
./texmf/bin:
MakeTeXPK.pl
MakeTeXPK.save
MakeTeXTFM.pl
TeXtoXfont
afm2tfm
bibtex
bm2font
buildfonts
cmmf
dvicopy
dvips
dvips.old
dvitype
epsfig
gftodvi
gftopk
gftype
inimf
initex
initex--xet
latex
makeindex
mf
mft
mftobdf
nlatex
patgen
pktogf
pktype
pltotf
pooltype
ps2pk
tangle
tex
texit
tftopl
vftovp
virmf
virtex
virtex--xet
vptovf
weave
xdvi
xtex
./texmf/cweb:
tex
./texmf/cweb/tex:
plain
./texmf/cweb/tex/plain:
cwebmac.tex
./texmf/dvips:
DC.enc
EC.enc
ascii.enc
color.pro
config.QMS1725
config.emu
config.emu_ps
config.kiwi
config.kiwi_ps
config.laserwriter
config.moa
config.moa_ps
config.preview
config.ps
config.videodisplayi
config.videodisplayii
config.videodisplayiii
config.videodisplayiv
config.videodisplayv
config.videodisplayvi
config.videodisplayvii
config.videodisplayviii
crop.pro
doc
encodings
extex.enc
finclude.pro
funky.enc
gradient.pro
ibmoem.enc
psfonts.map
pst-coil.pro
pst-node.pro
pstricks.pro
special.pro
test
tex
tex.pro
tex.ps
texc.pro
texmext.enc
texmital.enc
texmsym.enc
texps.pro
textpath.pro
./texmf/dvips/doc:
dvips.tex
./texmf/dvips/encodings:
ASCII.enc
CMmathex.enc
CMmathit.enc
CMsymbol.enc
CMtext.enc
CMtextit.enc
CMtypewriter.enc
DC.enc
EC.enc
extex.enc
isolatin1.enc
standard.enc
symbol.enc
./texmf/dvips/test:
test.tex
./texmf/dvips/tex:
latex
plain
./texmf/dvips/tex/latex:
blackdvi.sty
colordvi.sty
epsf.sty
rotate.sty
./texmf/dvips/tex/plain:
blackdvi.tex
colordvi.tex
dvipsmac.tex
epsf.tex
rotate.tex
rotsample.tex
./texmf/eplain:
tex
./texmf/eplain/tex:
eplain
./texmf/eplain/tex/eplain:
eplain.tex
./texmf/fontinst:
examples
tex
./texmf/fontinst/examples:
fontptcm.tex
fontptmm.tex
fontstnd.tex
fonttime.tex
mathptm.sty
ptmrmhax.mtx
ptmrvhax.mtx
ptmryhax.mtx
testmath.tex
unsetalf.mtx
unsethum.mtx
zrhax.mtx
zrmhax.mtx
zrvhax.mtx
./texmf/fontinst/tex:
latex
./texmf/fontinst/tex/latex:
OML.etx
OMS.etx
OMX.etx
OT1.etx
OT1c.etx
OT1ctt.etx
OT1i.etx
OT1itt.etx
OT1o.etx
OT1tt.etx
T1.etx
T1c.etx
fontdoc.sty
fontinst.sty
kernoff.mtx
kernon.mtx
latin.mtx
mathex.mtx
mathit.mtx
mathsy.mtx
trig.sty
./texmf/hebrew:
tex
./texmf/hebrew/tex:
latex
./texmf/hebrew/tex/latex:
HUMheblet.sty
HUMhebletter.sty
HUMletter.sty
HUheblet.sty
HUhebletter.sty
heb_macros_pc.sty
hebcal.sty
hebcal_newcode.sty
hebcal_pc.sty
hebletter.sty
hebrew.sty
hebrew_newcode.sty
hebrew_pc.sty
new.hebrew.sty
rightcol.sty
./texmf/ini:
amstex.fmt
amstex.log
cmbase.base
cmbase.base.save
cmbase.log
cmbase.log.save
dxbase.base
dxbase.log
latex2e.fmt
latex2e.log
lollipop.fmt
lollipop.log
lplain.fmt
lplain.log
mf.base
mf.pool
nfss2ltx.fmt
nfss2ltx.log
nfss2ltx.tex
plain.base
plain.base.save
plain.fmt
plain.log
plain.log.save
psr_lplain.fmt
psr_lplain.log
psr_lplain.readme
tex.pool
tex.pool.save
./texmf/knuth:
mf
tex
./texmf/knuth/mf:
00Contents
00Description
3test.mf
6test.mf
cmbase.mft
expr.mf
grayf.mf
hyphen.tex
io.mf
logo.mf
logo10.mf
logo8.mf
logo9.mf
logobf10.mf
logosl10.mf
manfnt.mf
manmac.tex
mftmac.tex
null.mf
null.tex
plain.mf
plain.mft
plain.tex
rtest.mf
slant.mf
story.tex
test.mf
testfont.tex
waits.mf
webmac.tex
ztest.mf
./texmf/knuth/tex:
plain
./texmf/knuth/tex/plain:
manmac.tex
mftmac.tex
null.tex
plain.tex
story.tex
testfont.tex
ushyphen.tex
webmac.tex
./texmf/latex:
ist
tex
./texmf/latex/ist:
gglo.ist
gind.ist
./texmf/latex/tex:
fd
latex
./texmf/latex/tex/fd:
LMRhlcm.fd
LMRlbm.fd
OMLccm.fd
OMLcmm.fd
OMLhlcm.fd
OMLlbm.fd
OMLlcmm.fd
OMLmtt.fd
OMLplcm.fd
OMScmsy.fd
OMShlcm.fd
OMSlbm.fd
OMSlcmsy.fd
OMSmtt.fd
OMSplcm.fd
OMXcmex.fd
OMXhlcm.fd
OMXlbm.fd
OMXlcmex.fd
OMXmtt.fd
OMXplcm.fd
OT1ccr.fd
OT1cmdh.fd
OT1cmfib.fd
OT1cmfr.fd
OT1cmr.fd
OT1cmss.fd
OT1cmtt.fd
OT1lcmss.fd
OT1lcmtt.fd
OT1pag.fd
OT1panr.fd
OT1pbk.fd
OT1pcr.fd
OT1phv.fd
OT1pnc.fd
OT1ppl.fd
OT1pss.fd
OT1ptm.fd
OT1pzc.fd
OT2cmr.fd
OT2cmss.fd
T1ccr.fd
T1cmdh.fd
T1cmfib.fd
T1cmfr.fd
T1cmr.fd
T1cmss.fd
T1cmtt.fd
T1hlc.fd
T1hlcf.fd
T1hlcs.fd
T1hlct.fd
T1lb.fd
T1lbf.fd
T1lbs.fd
T1lbt.fd
T1pag.fd
T1pbk.fd
T1pcr.fd
T1phv.fd
T1pnc.fd
T1ppl.fd
T1ptm.fd
T1pzc.fd
Ucmr.fd
Ucmss.fd
Ucmtt.fd
Ulasy.fd
Ullasy.fd
Upsy.fd
Upzd.fd
Uyfrak.fd
Uygoth.fd
Uyinit.fd
Uyswab.fd
./texmf/latex/tex/latex:
article.cls
article.sty
avant.sty
bk10.clo
bk11.clo
bk12.clo
book.cls
book.sty
bookman.sty
doc.sty
docstrip.tex
eufrak.sty
euscript.sty
exscale.sty
flafter.sty
fleqn.clo
helvet.sty
ifthen.sty
latex209.cmp
latex209.def
latexbug.tex
latexsym.sty
leqno.clo
letter.cls
letter.sty
ltxdoc.cls
lucbrb.sty
lucbry.sty
lucid.sty
lucmath.sty
mathtime.sty
newcent.sty
newlfont.sty
oldgerm.sty
oldlfont.sty
ot1.def
ot1var.sty
oz.sty
palatino.sty
pandora.sty
pifont.sty
report.cls
report.sty
sfontdef.ltx
shortvrb.sty
size10.clo
size11.clo
size12.clo
slides.cls
slides.ltx
slides.sty
t1.def
t1enc.sty
t1ot1.sty
testpage.tex
texsys.cfg
times.sty
tracefnt.sty
varioref.sty
./texmf/latex209:
tex
./texmf/latex209/tex:
latex
./texmf/latex209/tex/latex:
art10.sty
art11.sty
art12.sty
article.sty
bezier.sty
bk10.sty
bk11.sty
bk12.sty
book.sty
fleqn.sty
ifthen.sty
leqno.sty
letter.sty
makeidx.sty
openbib.sty
proc.sty
rep10.sty
rep11.sty
rep12.sty
report.sty
showidx.sty
slides.sty
titlepag.sty
titlepage.sty
twocolum.sty
./texmf/latex2html:
tex
./texmf/latex2html/tex:
latex
./texmf/latex2html/tex/latex:
html.sty
./texmf/lollipop:
doc
tex
./texmf/lollipop/doc:
README
mandefs.tex
manual.aux
manual.bbl
manual.cix
manual.imp
manual.oix
manual.tct
manual.tex
manual.tix
manual.toc
./texmf/lollipop/tex:
lollipop
./texmf/lollipop/tex/lollipop:
address.ats
address.aux
address.brt
address.tex
appendix.tex
btxmac.tex
comm.tex
comment.tex
define.tex
document.tex
example.tex
extern.tex
float.tex
fontdefs.tex
fonts.tex
head.tex
heading.tex
list.tex
lists.tex
lollipop.tex
lolplain.tex
opt.tex
out.tex
output.tex
prelim.tex
struct.tex
tex-inde.xen
text.tex
titlepag.tex
tools.tex
trace.tex
./texmf/mainze:
tex
./texmf/mainze/tex:
latex
plain
./texmf/mainze/tex/latex:
array.sty
dcolumn.sty
delarray.sty
doc.sty
hhline.sty
longtable.sty
multicol.sty
newarray.sty
newdoc.sty
tabularx.sty
verbatim.sty
vrbinput.sty
./texmf/mainze/tex/plain:
docstrip.tex
verbatim.tex
verbtest.tex
./texmf/man:
man1
./texmf/man/man1:
afm2tfm.1
amslatex.1
amstex.1
bibtex.1
dvips.1
dvitype.1
etex.1
gftodvi.1
gftopk.1
gftype.1
initex.1
lamstex.1
latex.1
mf.1
mft.1
patgen.1
pktogf.1
pktype.1
pltotf.1
pooltype.1
slitex.1
tangle.1
tex.1
tftopl.1
vftovp.1
virtex.1
vptovf.1
weave.1
./texmf/misc:
tex
./texmf/misc/tex:
latex
plain
./texmf/misc/tex/latex:
chemtex.sty
epsfig.sty
fancyheadings.sty
footnpag.sty
index.sty
pspic.sty
./texmf/misc/tex/plain:
chemstruct.tex
empty.tex
./texmf/modes:
ORA-modes.mf
local.modes
modes-1.0.mf
./texmf/musictex:
tex
./texmf/musictex/tex:
latex
./texmf/musictex/tex/latex:
a4report.sty
bigmusic.sty
euro92.sty
euro92.tex
euromtex.tex
extras.tex
hchoral.tex
howtoget.tex
lines.tex
musicacc.tex
musicadd.tex
musicdoc.tex
musicext.tex
musicnft.tex
musicpln.tex
musicpos.tex
musicpre.tex
musicref.tex
musicsty.tex
musictex.sty
musictex.tex
musictrp.sty
musictrp.tex
musicvbm.sty
musicvbm.tex
screatim.tex
./texmf/nfss2:
build
drv
tex
./texmf/nfss2/build:
cmpreloa.xii
cmpreloa.xip
cmpreloa.xpt
dcpreloa.xii
dcpreloa.xip
dcpreloa.xpt
fdprefix.tex
fontdef.tex
main.log
nfss2ltx.tex
preload.min
preload.ori
preload.tex
./texmf/nfss2/drv:
amsfonts.drv
cmrfonts.drv
fdprefix.drv
fontdef.drv
nfbeton.drv
nfconcr.drv
nfeufrak.drv
nfeuler.drv
nfeuscr.drv
nfexscal.drv
nffntcmd.drv
nfltxsym.drv
nfoldger.drv
nfpandor.drv
nfslide2.drv
nfslides.drv
nfss1cmp.drv
nfssboot.drv
nfssfont.drv
preload.drv
psfonts.drv
./texmf/nfss2/tex:
fd
latex
./texmf/nfss2/tex/fd:
OMLccm.fd
OMLcmm.fd
OMLlcmm.fd
OMScmsy.fd
OMSlcmsy.fd
OMXcmex.fd
OMXlcmex.fd
OT1ccr.fd
OT1cmdh.fd
OT1cmfib.fd
OT1cmfr.fd
OT1cmr.fd
OT1cmss.fd
OT1cmtt.fd
OT1lccr.fd
OT1lcmss.fd
OT1lcmtt.fd
OT1panr.fd
OT1pcr.fd
OT1pss.fd
OT1ptm.fd
OT2cmr.fd
OT2cmss.fd
T1ccr.fd
T1cmdh.fd
T1cmfib.fd
T1cmfr.fd
T1cmr.fd
T1cmss.fd
T1cmtt.fd
Ucmr.fd
Ucmss.fd
Ucmtt.fd
Ueuex.fd
Ueuf.fd
Ueur.fd
Ueus.fd
Ulasy.fd
Ullasy.fd
Umsa.fd
Umsb.fd
Upsy.fd
Upzd.fd
Uyfrak.fd
Uygoth.fd
Uyinit.fd
Uyswab.fd
./texmf/nfss2/tex/latex:
concrete.sty
dclfont.sty
eufrak.sty
euler.sty
euscript.sty
exscale.sty
margid.sty
newlfont.sty
nfavant.sty
nfbeton.sty
nfbookm.sty
nfconcr.sty
nfeufrak.sty
nfeuler.sty
nfeuscr.sty
nfexscal.sty
nffntcmd.sty
nfhelve.sty
nfltxsym.sty
nfnewce.sty
nfoldger.sty
nfot1.def
nfpalat.sty
nfpandor.sty
nfpi.sty
nfslides.sty
nfslides.tex
nfssfont.tex
nft1.def
nftimes.sty
nomargid.sty
oldlfont.sty
sfontdef.tex
syntonly.sty
tracefnt.sty
./texmf/norm:
tex
./texmf/norm/tex:
latex
./texmf/norm/tex/latex:
example.sty
./texmf/psfig:
bin
doc
tex
./texmf/psfig/bin:
pscompress
./texmf/psfig/doc:
00Contents
figs
psfig-doc.tex
psfig.man
./texmf/psfig/doc/figs:
00Contents
box.ps
cm.ps
piechart.ps
pretzel.ps
rosette.ps
starlines.ps
trevor.ps
zip.ps
./texmf/psfig/tex:
latex
unsupported
./texmf/psfig/tex/latex:
psfig.sty
./texmf/psfig/tex/unsupported:
00Contents
arbortext.pro
dospecial.frag
dospecial.patch
graphpaper.ps
macdemo
psfig-li.pro
psfig-li.tex
./texmf/psfig/tex/unsupported/macdemo:
00Contents
README
cleanfig
figs
lprep68.pro
lprep68.procs
lprep70.pro
lprep70.procs
macdemo.tex
macfigs
stripfonts.awk
./texmf/psfig/tex/unsupported/macdemo/figs:
00Contents
box.ps
cm.ps
piechart.ps
pretzel.ps
rosette.ps
starlines.ps
trevor.ps
zip.ps
./texmf/psfig/tex/unsupported/macdemo/macfigs:
00Contents
bullet.fig68.Z
bullet.fig68.bb
dave.fig68.Z
dave.fig68.bb
macdraw.fig68.Z
macdraw.fig68.bb
./texmf/pstricks:
config
ps
tex
./texmf/pstricks/config:
pstricks.con
./texmf/pstricks/ps:
gradient.pro
pst-coil.pro
pst-node.pro
pstricks.pro
textpath.pro
./texmf/pstricks/tex:
latex
plain
./texmf/pstricks/tex/latex:
charpath.sty
colortab.sty
fancybox.sty
gradient.sty
multido.sty
pst-coil.sty
pst-node.sty
pst-plot.sty
pst2eps.sty
pstricks.sty
textpath.sty
./texmf/pstricks/tex/plain:
charpath.tex
colortab.tex
gradient.tex
multido.tex
pst-coil.tex
pst-node.tex
pst-plot.tex
pst2eps.tex
pstricks.tex
textpath.tex
./texmf/seetex:
fonts
tex
./texmf/seetex/fonts:
fontdesc
./texmf/seetex/tex:
latex
./texmf/seetex/tex/latex:
xtex.sty
./texmf/texinfo:
tex
./texmf/texinfo/tex:
texinfo
./texmf/texinfo/tex/texinfo:
texinfo.tex
./texmf/tugboat:
tex
./texmf/tugboat/tex:
latex
plain
./texmf/tugboat/tex/latex:
ltugboat.sty
ltugproc.sty
./texmf/tugboat/tex/plain:
tugboat.cmn
./texmf/xet-ini:
lplain.fmt
lplain.log
plain.fmt
plain.log
tex.pool
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 09:16:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 94 15:16:35 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406081416.AA14324@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
> I took the /usr/local/lib/tex tree on our system and reorganized it
> according to the texmf/<package> style.
Given a scheme as you list, I can not see how one would specify
the input paths for latex and latex209 (should you wish to keep the
latter for a while:-).
If you did not mind both directories being searched, and one being
searched twice, you could go
texmf/latex/tex//:texmf//tex// (for 2e)
texmf/latex209/tex//:texmf//tex// (for 209)
or whatever the syntax is, but to construct completely separate paths
for 209 and 2e (or any other format) you would seem to have to
explicitly mention every <package> in the TEXINPUTS, and modify
TEXINPUTS whenever you add a package.
The first solution is probably OK, I can not really comment as
I have no feeling for the implementation costs of this searching.
The second solution is not OK at all:-)
Actually given such a scheme, I would suggest that people move
latex209 out of texmf all together to a place for storing obsolete
software, together with a latex209 script (or config file) that puts
this directory back in TEXINPUTS, that avoids the problem for latex,
but in general, different packages may have clashes of filenames, and
if both are `current' then you have to manipulate TEXINPUTS somehow,
you can not just get rid of the obsolete package.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 09:55:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 08 Jun 1994 09:55:15 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097FA3C.F21BD0C0.3014@SHSU.edu>
Subject: RE: texmf/<package>/<filetype>
On Wed, 8 Jun 1994 08:57:19 -0400, norm@ora.com (Norman Walsh) posted:
> texmf/ljmetrics/fonts/tfm
> texmf/ljmetrics/tex/latex/ljfonts.sty
> texmf/ljmetrics/tex/plain/ljfonts.tex
>
> if I add some style files. Do we want to start with texmf/ljmetrics/fonts
> initially to avoid having this problem someday?
This is a stupid question, but..... Is there any way to do selective
recursive searches on other platforms by any chance? By this, I mean
selecting certain reserved names (such as any directory named "fonts") and
avoiding searching them altogether. This is already how I handle a few
logical definitions on VMS so I can keep some stuff together for
maintenance reasons and have been quite happy with it so far.
--George
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 10:01:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 11:02:01 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081502.LAA29598@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: texmf/<package>/<filetype>
References: <0097FA3C.F21BD0C0.3014@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 8 June 1994 at 09:55:15, George D. Greenwade wrote:
> This is a stupid question, but..... Is there any way to do selective
> recursive searches on other platforms by any chance? By this, I mean
> selecting certain reserved names (such as any directory named "fonts") and
> avoiding searching them altogether. This is already how I handle a few
> logical definitions on VMS so I can keep some stuff together for
> maintenance reasons and have been quite happy with it so far.
I can't imagine exactly what VMS is doing, but the short answer is "no".
Subdirectory searching (at least on Unix and PC's) is an application-specific
rather than OS specific thing and it would be up to the application designer
to provide that feature.
I gather that web2c provides an approximation of that feature by allowing you
to specify search paths like 'texmf//tex//'. But even there, I don't see how
it can avoid looking in 'texmf/fonts/*' for a directory called 'tex'.
My primary objection to the texmf/<package> organization (as appealing
as it is to keep the packages together) is that it greatly increases the
amount of searching required.
I keep soothing myself by saying that fast searches are done by table
lookup (ls-R files, for example) anyway so it doesn't really matter. In
my heart, though, I know it does. I doubt emTeX uses tables (though we might
convince EM to add it). I don't know how we'll convince commercial
developers to do the work.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 10:05:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 11:05:38 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081505.LAA29721@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406081341.JAA25066@ruby.ora.com> <9406081416.AA14324@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 8 June 1994 at 15:16:35, David Carlisle wrote:
>
> > I took the /usr/local/lib/tex tree on our system and reorganized it
> > according to the texmf/<package> style.
> Given a scheme as you list, I can not see how one would specify
> the input paths for latex and latex209 (should you wish to keep the
> latter for a while:-).
I guess I'd do something like this:
TEXINPUTS=/usr/local/texmf/latex//tex//:/usr/local/texmf/latex209//tex//:
/usr/local/texmf/plain//tex//
But for documents that also use other packages, I think it quickly
reduces to
TEXINPUTS=/usr/local/texmf//tex//
> If you did not mind both directories being searched, and one being
> searched twice, you could go
> texmf/latex/tex//:texmf//tex// (for 2e)
> texmf/latex209/tex//:texmf//tex// (for 209)
> or whatever the syntax is, but to construct completely separate paths
> for 209 and 2e (or any other format) you would seem to have to
> explicitly mention every <package> in the TEXINPUTS, and modify
> TEXINPUTS whenever you add a package.
>
> The first solution is probably OK, I can not really comment as
> I have no feeling for the implementation costs of this searching.
> The second solution is not OK at all:-)
I agree.
I'm quickly coming to the conclusion that I like
texmf/<package>/*
better, but it's impractical.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 10:42:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 08 Jun 1994 11:42:29 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
To: TWG-TDS@SHSU.edu
Message-ID: <771090149.836099.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
sorry, norm, what you have listed as ./texmf/amstex/ is all
fouled up. here's a more accurate arrangement. as far as
it goes, i think it may be possible to sell it to the
management here, but before i try to do that, i'd like to
know that it's acceptable.
./texmf:
ams
./texmf/ams:
amslatex
amstex
doc
./texmf/ams/amslatex:
contrib
ini
tex
./texmf/ams/amslatex/...:
[parallel to the corresponding .../amstex/ areas]
./texmf/ams/amstex:
contrib
ini
tex
./texmf/ams/amstex/contrib:
[lots of stuff; i'm not sure whether what you have listed
is ams-tex or ams-latex -- it does make a difference! --
but the principle is reasonable.]
./texmf/ams/amstex/ini:
amstex.ini
./texmf/ams/amstex/tex:
amsppt.sty
amsppt1.tex
amssym.tex
amstex.tex
./texmf/ams/doc:
amsfonts
amslatex
amstex
./texmf/ams/doc/amstex:
amsguide.tex
amsppt.doc
amstex.bug
amstinst.tex
joyerr.tex
[similarly for ./texmf/ams/doc/amsfonts and ./texmf/ams/doc/amslatex]
i really don't know what to do with README files. in our
distribution on e-math there are 15 of them, (at least) one
in each directory at every level, and each one is specific
to the directory in which it resides. similarly, the
00Contents file that was in .../doc is from ctan and in that
form is meaningless here; are you suggesting that a new one
should be generated for this cd?
i also didn't see any of the amsfonts material clearly
delineated, although you noted that the fonts aren't in here
yet. knowing what's in this area really is critical. i want
to know where the dummy.tem and dummy.pl files will go. (there
is no dummy.mf.) amstex and amslatex simply won't work without
the dummy font, and it is a frequent complaint that non-ams
distributors of the ams packages don't include it and they
can't use the packages without it. likewise, the macros in
cyracc.def are necessary for proper use of the wncy* fonts,
and therefore we package that file with the fonts, not with any
of the macro packages (although they can be used with either
ams-tex or ams-latex). omitting these seemingly insignificant
items, or disconnecting them from what they logically go with
makes things confusing for users and very frustrating and time
consuming for us who have to answer the complaints.
again, i appeal to you all to think of those of us for whom
support for some of these packages is part of our job
descriptions. we try to do the best job we can writing the
documentation in the first place, so that we don't have to
deal with complaints. i realize that most tex volunteers
are very responsive and responsible. but in the end, a
volunteer can just say "i need a break" and go off and ignore
problems for a while. we can't. so please give us a break
by not fragmenting what we are responsible for beyond
recognition and making it impossible for us to create a single
scrutable documentation set for each package.
before i try to change anything here, i will also have to
know quite specifically what is proposed for the amsfonts.
from the point of view of maintenance and documentation, of
course we'd prefer to have them kept as a package, but that
seems to be quite unacceptable here. i hope we can find
some mutually satisfactory arrangement that will also make
sense on ctan. it will take some time to rewrite the
documentation, and we haven't got time to do it more than
once.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Jun 1994 11:04:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 12:04:51 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406081604.MAA02601@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406081341.JAA25066@ruby.ora.com> <771090149.836099.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 8 June 1994 at 11:42:29, BNB@math.ams.org wrote:
> sorry, norm, what you have listed as ./texmf/amstex/ is all
> fouled up.
Sorry! I should have been more explicit. What I did was convert the
existing installation to the proposed texmf/<package> scheme. I should
have stated explicitly: the installation that I converted was deficient
in several places *especially* in the /amstex tree which was basically
mangled. I'm the only one who uses TeX and I did some things to make it
easy to print my book that I wouldn't ordinarily allow anyone else to
see ;-)
I've waffled a lot today, but I now have serious doubts about the
practicality of using the texmf/<package> scheme. Am I alone?
> i really don't know what to do with README files. in our
> distribution on e-math there are 15 of them, (at least) one
> in each directory at every level, and each one is specific
> to the directory in which it resides.
I'll work on converting the AMS to whatever we decide is best for the TDS
(as an example, not because I expect the AMS to start using it
(at least not tomorrow ;-))
> i also didn't see any of the amsfonts material clearly
> delineated, although you noted that the fonts aren't in here
> yet. knowing what's in this area really is critical. i want
You're right. I didn't mean to muddy the waters (as I may have done).
I appreciate your attention to detail, and I probably should have trimmed
the ams branch right out of the tree before I posted my listing. I
knew it was wrong. I had hoped that the listing would provide a feel
for the kind of layout we were proposing; I didn't expect that I had gotten
it entirely right.
> to know where the dummy.tem and dummy.pl files will go. (there
Well, in
texmf/ams/fonts/dummy/tfm/dummy.tfm
texmf/ams/fonts/dummy/pl/dummy.pl
or
texmf/fonts/ams/dummy/tfm/dummy.tfm
texmf/fonts/ams/dummy/pl/dummy.pl
I expect, depending on the scheme we choose.
> can't use the packages without it. likewise, the macros in
> cyracc.def are necessary for proper use of the wncy* fonts,
> and therefore we package that file with the fonts, not with any
> of the macro packages (although they can be used with either
> ams-tex or ams-latex). omitting these seemingly insignificant
> items, or disconnecting them from what they logically go with
> makes things confusing for users and very frustrating and time
> consuming for us who have to answer the complaints.
I think that putting TeX input files in the font tree (no matter which
scheme we select) will be a bad thing. The purpose of seperating fonts
and inputs is to cut down on the searching necessary to find an input file.
I don't know what to do about this...
> again, i appeal to you all to think of those of us for whom
> support for some of these packages is part of our job
> descriptions. we try to do the best job we can writing the
> documentation in the first place, so that we don't have to
> deal with complaints. i realize that most tex volunteers
> are very responsive and responsible. but in the end, a
> volunteer can just say "i need a break" and go off and ignore
> problems for a while. we can't. so please give us a break
> by not fragmenting what we are responsible for beyond
> recognition and making it impossible for us to create a single
> scrutable documentation set for each package.
I want to assure you that I'm keenly aware of these issues. We are trying
very hard to create a directory structure that will be *easier* to install
and maintain.
There is a down side: that structure will almost certainly be different
than the existing structures (in general, including the ams structure
in particular).
> before i try to change anything here, i will also have to
> know quite specifically what is proposed for the amsfonts.
I hope (well, had hoped anyway---things seem to have gotten muddled again)
that we'd have a concrete proposal by the end of next week. Something
that we could circulate to a wider audience for further comment.
> from the point of view of maintenance and documentation, of
> course we'd prefer to have them kept as a package, but that
> seems to be quite unacceptable here.
Our most recent discussions have, in fact, been addressing exactly this
point. If we elect to use the /texmf/<package> scheme, I think it will
be very possible to keep all of the ams stuff together under /texmf/ams.
Unfortunately, I fear that there are practical (i.e. technical) problems
with spreading fonts and input files all over.
The alternatives seem to be this: spread packages around or spread different
types of files around. Technically, it's easier to spread packages.
>From an installation, maintainance, and support perspective, it's easier
to spread different types of files around.
> i hope we can find
> some mutually satisfactory arrangement that will also make
> sense on ctan.
What we're discussing here, recall, is an arrangement on the users disk
and that's not necessarily identical to the CTAN arrangement.
Nevertheless, I also dearly hope that we can come to a mutually satisfactory
solution. For the TDS to succeed, I think we must...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 06:44:30 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9406091136.AA25452@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Bob Harris may be off-line
Date: Thu, 09 Jun 94 07:14:09 -0400
From: bob@microprograms.com
I had a system problem earlier this week. The write permission for my
/spool/mail directory got corrupted so mail bounced. Sorry for the inconvenience.
Bob
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 06:55:18 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9406091136.AA25450@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
Date: Thu, 09 Jun 94 07:10:29 -0400
From: bob@microprograms.com
Karl observes:
> You can't just have one bin at many sites, where multiple architectures
> are supported. Something trickier has to happen. Local admins have
> probably already dealt with the problem, either by using /usr/local/bin
Arbortxt, in their standard distributions, add one more level, i.e.,
/usr/local/bin/sun
/usr/local/bin/hp
/usr/local/bin/decmips
etc
Bob
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 06:55:38 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9406091136.AA25453@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/<package>/<filetype>
Date: Thu, 09 Jun 94 07:35:17 -0400
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
Norm says:
> I keep soothing myself by saying that fast searches are done by table
> lookup (ls-R files, for example) anyway so it doesn't really matter. In
> my heart, though, I know it does. I doubt emTeX uses tables (though we might
> convince EM to add it). I don't know how we'll convince commercial
> developers to do the work.
I am sharing Norm's concern about the interests I am representing on
this committee. At least in the DOS market, the return on investment in
product development is waning fast. Furthermore, we have to be carefull
not to cut off users who don't want to adopt the committee's
reccommendations. For an example, look at what the C compiler
manufacturers are going through to maintain K&R compatibility with ANSI
compliance in the same compiler!
For my specific situation, I am not sure I can convince Dave Fuchs to
put a lot of work into revising MicroTeX. He still holds the source and
copyright to the version of TeX I sell. Since I hold the source to the
previewer and dvi translators, I can modify them as required.
BTW several messages in the past week still suggest making symlinks to
solve problems. WE CAN'T DO THAT IN MS-DOS.
Bob
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 08:26:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091324.AA24433@spice.iti.informatik.th-darmstadt.de>
Subject: A place for docs is necessary
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 9 Jun 1994 15:24:51 +0100 (MESZ)
Content-Type: text
[Hi, I'm back :-)]
To me, it's very important to specify a place for documentation files
in a TDS. And it's important that they are not spread over a large
tree, but kept together. That does not imply that they must be all in
one directory, but starting from one directory (named doc/,
documents/, or documentation/ [8.3, I know], please).
The point is that one should not _only_ look at stand-alone users who
sell some TeX CD. One should also care for TeX administrators who
have to install and TeX at a site and support it for a (maybe large)
bunch of users. They probably want to tell their users, ``Look,
you'll find lot's of documentation for our locally installed [?] TeX
packages in directory foo/doc/. Often, it's DVI files, sometimes
ASCII, and sometimes sample source files.'' That's a great help, many
users are willing to inform themselves before they bother the system
administrator. We should encourage this kind of behaviour, at least I
do it here. (Really, most users _do_ have an IQ above room
temperature. :-)
As an particular example: LaTeX. I want a directory where I can put
*guide.dvi, <package>.dvi, local-guide.{tex,dvi}, sample.tex, and
similar files into and that I can advertise to my users.
Actually, I want a proposed name for this directory. This name
shall be used in the Guidelines to Write LaTeX Bundles and in the
Generic Local Guide (aka Local Guide Template).
That does not concern the issue of distribution. Most folks on this
list have heard my opinion earlier: Distribution and Using are two
different tasks and will demand different structures for an adequate
support. We should not forget that an installation is _not_ only
looked at by programs, but by human beings as well.
As an empirical point of evidence: Phone calls for our commercial TeX
products dropped by 50% after we (a) made the directory structure
clearer [almost identical to the proposed TDS, formerly we had
tex/inputs/ etc.], (b) documented that structure properly (At first
we thought users will write documents, not look at available files.
We were wrong.), and (c) supplied all documentation in printable form
as part of the distribution in a few directories. That was back in
1986, btw.
Joachim
PS: Sorry, if some of the points above have been made already. I've
still to read a backlog of > 100 mails from twg-tds and might not be
fully up-to-date concerning the presented arguments.
PPS: Also sorry for my `German English'. Usually I try to double my
sentences after I've written a text, but don't have the time now. ;-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 09:26:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 13:12:59 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091312.AA18454@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/<package>/<filetype>
References: <199406081502.LAA29598@ruby.ora.com> <9406091136.AA25453@uu3.psi.com>
> For my specific situation, I am not sure I can convince Dave Fuchs to
> put a lot of work into revising MicroTeX. He still holds the source and
> copyright to the version of TeX I sell. Since I hold the source to the
> previewer and dvi translators, I can modify them as required.
>
lets not consider that TDS is *necessarily* production. its a common
language and system to describe a TeX library. It may be that Bob has
to write a (relatively trivial) utility for MicroTeX users to take a
given subset of the library and flatten it. but it is considerably
easier for him to do so if the TDS is documented, used and
recommended.
Either David Fuchs adds subdir searching or he doesnt; if he does,
lets assume he will do it efficiently, using whatever the best method
for DOS is. We know it can be done cleanly. Given that, I am really
very reluctant to let TDS *not* assume sub directory searching, and
would rather accept that some implementations impose a filter betwen
the TDS and whats actually on disk
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:17:27 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 9 Jun 1994 09:18:00 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406091618.JAA29138@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/<package>/<filetype>
CC: mackay@cs.washington.edu
TeXcauses the smallest number of problems and delays with path-searching,
and would require fewer files in a putative flat library directory than
a display or printer program. So the division of interest in the microprograms
case is as good as it can be. The perceived delay for the display program
is probably the most exasperating effect of a slow search, you can get pretty
impatient about a printer program too, but you can also batch it off somewhere
and pretend that it is the spooler that is causing the trouble.
We (the non-DOS) contingent, do not want to seem unkind, and we do
recognize that things like symlinks (or for that matter links of any kind)
may be unknown to DOS, but we have to hope and assume that DOS will ultimately
go the way of CP/M (which may well have been better designed for its time),
and plan as best we can for the operating system of the next five years.
One of the chief indictments against DOS is the unnecessary way it incorporated
Intel hardware peculiarities into what ought to have been logical structures.
I agree absolutely that the TDS must not be crippled by the defects of
DOS. 8+3 filenames handicap us seriously, but they do not maim. A distorted
file tree maims us.
Incidentally, in a previous message, Norm is concerned with the possibility
that TeX may have to look at texmf/fonts/. . . even if only to reject
all the paths there. That is---and I may simply be repeating his observations---
an excellent reason for the basic branches
texmf/tex
texmf/fonts
texmf/. . .
All I have to do to keep from an unnecessary search of texmf/fonts
is set TEXINPUTS to look at $TEXMFROOT/tex//
and texmf/fonts/ . . . will be left out of the search.
I hope I am not teaching granny to suck eggs, but it seemed to me that
this point got lost a couple of days ago.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:43:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 14:58:10 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091458.AA19790@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
References: <199406071248.AA12656@terminus.cs.umb.edu>
>
> I don't think an implementation/distribution/site should be a
> ``non-conforming'' site simply because they don't want to put the many
> megabytes of documentation into the same place as the fonts and other
> files that are *required* for an operational TeX. Documentation is not
> *required*. There might not be enough space in the partition for all the
> documentation, just for the library files.
i don't agree with Karl, I am afraid. If space is at a premium, omit
the docs (it still conforms with an empty branch). if the partitioning
system is mucking you up, mobe them elsewehere, but leave the branch
and add a link or a textual pointer.
i really think people will be very grateful for a standard place to
put .dvi and .ps files (leave info mand man pages out of it) for TeX,
all in one nice manageable tree. even if its empty, or has a readme,
at least they know where to start
> has a much better chance of keeping up with the world. As people
> implement major packages, like arabtex or latex or amstex or whatever,
> as TeXophiles we should be striving to make those significant additions
> to the TeX world as easy to possible to install and maintain, not
> consider them as exceptions to the rule of small, one or two file,
> single-format hacks.
i really want to buy this, but i cant. it may be the correct way of doing
it, but nothing else in the computing world does it that i can think
of.
anyway, your own argument rebounds on you. what if i want to have
separate partitions by function? is there some scenario under which
many people with little TeX setups burble on happily with just a few
branches, while a central complete server has (eg) all the .pk files
for a central dvi printer? yes, i am contriving it, but its arguable.
the argument that `i want to recognise whats in arabtex as a package'
is only convincing on the surface. IF we have struct adherence to the
TDS we can unequivocally find the arabtex stuff, since it will always
have its own directory at teh relevevant point
> I've never used emtex, so I can't answer this. It would be a strange
> implementation method if it only allowed subdir searching in certain
> predefined unchangeable places, though.
he may only permit wildcards at the *end* of the variable, and have
thought he was doing what people wanted
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:43:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 15:20:58 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091520.AA20021@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
References: <199406081147.AA24787@terminus.cs.umb.edu>
> Because you might not have enough disk space to store all the
> documentation, sources, and binaries in one partition. Just the library
> files. I think making it easy to separate the files that are *necessary*
> to run from the files which are not is a win. (See my message yesterday
> for details.)
writing `extract' scripts would be fairly trivial with the texmf the
other way up anyway?
s
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:44:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 15:17:49 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091517.AA19985@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
References: <199406080340.UAA13723@june.cs.washington.edu>
>
> If we can decide on what the minimum lot of branches under
> texmf/ are, it should be possible to suggest through
> texhax and info-tex something like the following
>
> <package>/
> /doc/<packagename>/*[tex.dvi,ps],README(s)
> /src/<packagename>/*.[c,h] etc.
> /tex/<packagename>/*.[tex,sty]
> /fonts/ . . .
>
> and so on.
>
> src/ would probably be moved somewhere else entirely, but
> if the template were well designed, a simple script could
> spread doc/ tex/ and fonts/ across a texmf/root cleanly and
> quickly.
quite. if we get the structure *unambiguous*, it doesn't matter
what it is.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:44:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 15:24:35 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091524.AA20044@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
References: <199406081147.AA24794@terminus.cs.umb.edu>
> This will lose for an existing installation that uses the current
> scheme, but doesn't use ls-R, because it will end up looking at (say)
> texmf/fonts/*/* for a `tex' directory. But I think the initial pain will
> be worth it in the long run, because new packages will be so much easier
> to deal with. If Mattes and the other TeX distributors agree to this, so
> that we all eventually converge on it, then I think it will succeed.
i think this pain is greater than you think. a big package might have
a very complex tree, which you will search all of for `tex'
directories, and it could impact you badly. consider all the web2c
`package' - unless you rename things, the system will find
web2c/src/tex
on its TEXINPUTS path, will it not? (which is just the source of tex).
ok, so maybe web2c is a special case but you never know what people
will do in their distributions.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:44:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 15:27:37 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091527.AA20066@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/<package>/<filetype>
References: <199406081257.IAA23621@ruby.ora.com>
> Does this mean we'll have directories like all these?
>
> texmf/plain/fonts/cm/src
> texmf/plain/fonts/cm/pk/<mode>/<dpi>/<files>
> texmf/plain/tex/plain/*
>
> texmf/latex/fonts/cm/src
> texmf/latex/fonts/cm/pk/<mode>/<dpi>/<files>
> texmf/latex/tex/latex/*
this directories will all exist under any scheme...
> And we still have a fonts tree for just fonts:
>
> texmf/fonts/adobe/courier/afm
> texmf/fonts/adobe/courier/pfa
> texmf/fonts/adobe/courier/pk/ps2pk/<dpi>/<files>
>
> Or is this now:
>
> texmf/adobe/fonts/courier/afm
> texmf/adobe/fonts/courier/pfa
> texmf/adobe/fonts/courier/pk/ps2pk/<dpi>/<files>
i'd assume the latter if one goes with Karl
> If we use texmf/fonts/adobe (as I'm inclined to), we'll have the problem
> of a package (like ljmetrics) that should be
>
> texmf/fonts/ljmetrics/tfm ...
>
> but might become
>
> texmf/ljmetrics/fonts/tfm
> texmf/ljmetrics/tex/latex/ljfonts.sty
> texmf/ljmetrics/tex/plain/ljfonts.tex
this latter is perfectly rational?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Jun 1994 11:45:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Jun 94 15:44:31 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406091544.AA20161@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406081341.JAA25066@ruby.ora.com> <199406081604.MAA02601@ruby.ora.com> <771090149.836099.BNB@MATH.AMS.ORG>
>
> I'll work on converting the AMS to whatever we decide is best for the TDS
> (as an example, not because I expect the AMS to start using it
> (at least not tomorrow ;-))
i think that a succesful TDS implementation of the AMS stuff will go a
very long way towards assuring acceptance. its such a well-known thorny
problem area that everyone will be happy if we get it right to
Barbara's satisfaction.
> Our most recent discussions have, in fact, been addressing exactly this
> point. If we elect to use the /texmf/<package> scheme, I think it will
> be very possible to keep all of the ams stuff together under /texmf/ams.
> Unfortunately, I fear that there are practical (i.e. technical) problems
> with spreading fonts and input files all over.
i dont think its only technical. i think there are rational and sound
arguments for both systems, its not as simpler as texmf/<package>
being unequivocally the best
by the way, surely the cyracc.def files go in
texmf/ams/tex/generic/cyracc.tex
or
texmf/tex/generic/cyracc.tex
? i dont see the problem
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 13:46:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 11:46:35 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101846.LAA24151@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: ISO-9660 directory levels
I fear that there may be things on a CD that *don't* belong in /texmf (like
the CD copyright gibberish and associated READMEs) so I'm inclined to leave
that level in unless it's torn away by force.
It would make installation from a CD a bit more complex to leave out the
texmf/ level, but unless we find the subdirectories directly under
texmf/ proliferating outrageously, it wouldn't be too bad.
copying fonts/
tex/
mf/
and possibly doc/
from a CD-ROM into $TEXMFROOT is not
hopelessly more complicated than copying texmf/ into the parent of texmf/
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 14:05:19 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 12:05:43 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101905.MAA26590@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Does /texmf only contain TeX inputs?
Karl asks
<package>/
I don't follow the need for this top-level <package>/ directory?
/doc/<packagename>/*[tex.dvi,ps],README(s)
/src/<packagename>/*.[c,h] etc.
/tex/<packagename>/*.[tex,sty]
/fonts/ . . .
(Or maybe it's that I don't follow the need for this subsidiary
<packagename>/ directory.)
I was thinking of what I might send out, for example as ibygrk. I don't like
packages that initially unpack into a number of subdirectories.
xdvik-1.8, for instance, unpacks into the
single directory xdvik-1.8. In that case it is usually
necessary to compile out of xdvik-1.8, but not always.
I like the fact that I can be sure that everything that came in the
package is unloaded into one directory and one only.
So an ibygrk package would initially unpack into
ibygrk/
tex/
ibygrk/ . . .
fonts/
etc, and you might very well discard the root-level ibygrk directory
after distributing tex/ and fonts/ around the texmf/ tree
But at least you would start out with everything altogether in a single
package directory while making the installation decisions.
I guess the point is that the initial <package> directory is not intended
to go into the texmf/ tree, it is simply a wrapper for stuff that is
not automatically included in a texmf/ tree.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 14:11:56 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 12:12:33 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101912.MAA27573@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: texmf/<package>/<filetype>
I still like a few <function>/ branches coming directly off the
texmf/ root and then proliferating, as necessary into <package>/
directories far better than a large lot of <package>/ directories
rooted in texmf/ with the basic <function>/ division one level up
(or down---I can't get used to trees with their roots pointed skyward.)
Yes, it means that each package will have to be split across functions,
but I don't see that that is an excessive burden on an installer.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 14:11:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 12:12:33 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101912.MAA27573@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: texmf/<package>/<filetype>
I still like a few <function>/ branches coming directly off the
texmf/ root and then proliferating, as necessary into <package>/
directories far better than a large lot of <package>/ directories
rooted in texmf/ with the basic <function>/ division one level up
(or down---I can't get used to trees with their roots pointed skyward.)
Yes, it means that each package will have to be split across functions,
but I don't see that that is an excessive burden on an installer.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 14:34:03 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 12:34:34 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101934.MAA01184@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Jun 1994 12:04:51 -0400
From: norm@ora.com (Norman Walsh)
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406081341.JAA25066@ruby.ora.com>
<771090149.836099.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 8 June 1994 at 11:42:29, BNB@math.ams.org wrote:
> sorry, norm, what you have listed as ./texmf/amstex/ is all
> fouled up.
Sorry! I should have been more explicit. What I did was convert the
existing installation to the proposed texmf/<package> scheme. I should
have stated explicitly: the installation that I converted was deficient
in several places *especially* in the /amstex tree which was basically
mangled. I'm the only one who uses TeX and I did some things to make it
easy to print my book that I wouldn't ordinarily allow anyone else to
see ;-)
I've waffled a lot today, but I now have serious doubts about the
practicality of using the texmf/<package> scheme. Am I alone?
Was I responsible for the idea of a texmf/<package> scheme by not
being clear enough? I certainly never intended that arrangement,
and I have just the same doubts as Norm has. When I showed
a template with <package>/ as the initial directory for {\it delivery}
of a package, it was meant to be just that and no more.
and I did not intend to suggest that the <package>/ directory
should be rooted directly in $TEXMFROOT. I meant it as an ephemeral
wrapper in which the package is to be delivered, because I deplore
packages that extract into multiple parallel directories without
warning. I do not think it makes it easier for the installer to
offer a package that can be tarred into an existing structure directly.
Any installer with a modicum of caution is going to want to unpack
<package> into some safe place and look at it before deciding to
transfer the subdirectories into an existing file tree.
The <package> template was intended to set up the tex/ src/ fonts/ etc.
branches in advance so that the installer {\it after duly inspecting
the package} is able to do (Unix example---sorry)
tar cf - ./tex | ( cd $TEXMFROOT; tar xvf - )
After that the <package> wrapper directory can probably be discarded
altogether.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 14:42:54 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 12:43:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406101943.MAA02054@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: texmf: for programs or humans?
From: bob@microprograms.com
Karl observes:
> You can't just have one bin at many sites, where multiple architectures
> are supported. Something trickier has to happen. Local admins have
> probably already dealt with the problem, either by using /usr/local/bin
Arbortxt, in their standard distributions, add one more level, i.e.,
/usr/local/bin/sun
/usr/local/bin/hp
/usr/local/bin/decmips
etc
This is often necessary in Unix sites too. Here, even on a pair of
relatively compatible machines, I have 68010 code for most programs
and 68020 code in a bin/68020 directory where it really matters.
path order takes care of the selection.
(Why on earth are you running 68010 code? It's a long story)
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 15:56:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 10 Jun 1994 16:14:31 -0400
Message-ID: <199406102014.QAA26522@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Proposed change to font tree...
Reply-To: TWG-TDS@SHSU.edu
I'd like to propose the following change; rather than:
texmf/fonts/<source>/<typeface>/src
for MF sources, how about
texmf/fonts/<source>/<typeface>/mf
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 15:56:18 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 10 Jun 1994 16:13:15 -0400
Message-ID: <199406102013.QAA26518@jasper.ora.com>
To: TWG-TDS@shsu.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406081604.MAA02601@ruby.ora.com> <199406101934.MAA01184@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 10 June 1994 at 12:34:34, Pierre MacKay wrote:
> Was I responsible for the idea of a texmf/<package> scheme by not
> being clear enough? [...]
>
> The <package> template was intended to set up the tex/ src/ fonts/ etc.
> branches in advance so that the installer {\it after duly inspecting
> the package} is able to [...]
I don't know who started it (doesn't matter really, it was an interesting
discussion), but I think that opinion has turned against it. Unless there
are objections, I'm willing to call the
texmf/package/format vs. texmf/format/package
debate dead. texmf/package/format died.
The scheme is still:
texmf/<format>/<package>/<files>
texmf/fonts/<source>/<typeface>/{src,tfm,vf,vpl,pfa,pfb...}
texmf/fonts/<source>/<typeface>/pk/<mode>/<dpi>/<files>
etc.
I'm going to write up this proposal and I'll float it on Monday. If there
are no substantive changes by Wednesday, I'll post it again Thursday with
minor corrections and finally to the world (for larger comment) on Friday.
Sound good?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 16:04:12 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 14:04:48 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406102104.OAA12366@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
Uhhhhhhhhhhhhhhhhhhhhhhhhh
(Sigh of relief)
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 16:12:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 14:12:40 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406102112.OAA13243@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Proposed change to font tree...
There are too many things besides mf files that belong in src.
I keep specially tailored vpl files there, unique encodings,
utility scripts.
The cm based Turkish I am working on has a couple of small
mf files in it and a couple of humongous vpl files, along with
scripts to guide in compilation. mf files will be less than 1/4
the content of the directory.
In the case of PostScript fonts the balance is about equal.
half vpl files (edited and merged from a combination of regular and
expert font sets) and half mf files.
So, mf would not cause any really serious trouble as a
directory name, but it would be misleading.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Jun 1994 16:12:44 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Jun 1994 14:12:40 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406102112.OAA13243@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Proposed change to font tree...
There are too many things besides mf files that belong in src.
I keep specially tailored vpl files there, unique encodings,
utility scripts.
The cm based Turkish I am working on has a couple of small
mf files in it and a couple of humongous vpl files, along with
scripts to guide in compilation. mf files will be less than 1/4
the content of the directory.
In the case of PostScript fonts the balance is about equal.
half vpl files (edited and merged from a combination of regular and
expert font sets) and half mf files.
So, mf would not cause any really serious trouble as a
directory name, but it would be misleading.
Email concerned with UnixTeX distribution software should be sent primarily
to: UnixTeX@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
================================================================================
From owner-twg-tds@shsu.edu Sat, 11 Jun 1994 17:50:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Jun 1994 18:51:33 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406112251.SAA01435@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Proposed change to font tree...
References: <199406102014.QAA26522@jasper.ora.com> <199406102112.OAA13243@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 10 June 1994 at 14:12:40, Pierre MacKay wrote:
> There are too many things besides mf files that belong in src.
Proposal withdrawn. .../src it remains.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Sun, 12 Jun 1994 05:35:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 12 Jun 1994 06:35:49 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406121035.AA14453@terminus.cs.umb.edu>
To: TWG-TDS@shsu.edu
Subject: Re: Sample texmf/<package> listing...
Unless there
are objections, I'm willing to call the
texmf/package/format vs. texmf/format/package
debate dead. texmf/package/format died.
The main argument I've recognized against texmf/package/format in the
last N messages is that it's impractical. I don't think it is
technically impractical unless a few hundred K of memory for the
database is considered prohibitive, in which case I give up. Yes, it
requires some work on the part of the implementors (<10 people,
probably). If that work will help the hundreds (thousands?) of TeX
administrators and package creators, to me it seems reasonable to invest
the work.
One thing Pierre said along the way is that we are trying to make a TDS
that will be viable into the future, not just as a representation of
where we are now. I completely agree with. And I still believe that
texmf/package/format is so much easier to administer than
texmf/format/package that it will serve us better as time goes on.
IMHO, the most important thing the TDS can do is make it easier for
people to install useful TeX packages, because then users will have more
stuff available to them, and have a greater appreciation of (and desire
for) TeX. I think texmf/package/format makes both installation of
(new versions of) packages and knowing what you have almost trivial, and
hence ideal.
David raised an interesting technical question about how to get the
latex209 binary to read the latex209 inputs, and ditto for latex2e. This
has come up on the tex-k list several times.
I have two comments:
1) It would take a little programming to make it work cleanly (e.g., you
could have different path values for different executable
names). But, as I argue above, implementors' work should not be the
deciding factor in which way to go.
2) LaTeX is (so far as I know) the only instance of this. Therefore, it
may be feasible to skip the whole issue, and just drop latex209, or
handle it in an ad hoc way with some special script or whatever.
OK, that's enough. If I am standing alone against the tide here, I will
leave the field gracefully. (To mix metaphors rather badly.)
================================================================================
From owner-twg-tds@shsu.edu Sun, 12 Jun 1994 12:10:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 12 Jun 1994 13:10:42 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199406121710.NAA00777@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Handling languages...
Reply-To: TWG-TDS@SHSU.edu
Did we ever come up with a concrete proposal for handling
the language stuff? I haven't done enough multi-lingual
typesetting to have a good feel for it. Can we just move
the language stuff into the macro and font trees?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Sun, 12 Jun 1994 12:24:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 12 Jun 1994 13:25:06 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
To: TWG-TDS@SHSU.edu
Message-ID: <771441906.317423.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
norm asks:
... Can we just move
the language stuff into the macro and font trees?
one more plea for folks who won't be installing the entire cd,
or running directly from the cd. if related files, that happen
to be of different types (fonts, macros, ...), get split up
without *very* good documentation (which many people don't read,
anyhow, sigh), it's likely that quite a few users will get only
part of a package, and then wonder why on earth it doesn't work.
just scan the archives of comp.text.tex ...
this applies to language support packages as it does to any other.
sorry to keep up this boring lament ...
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sun, 12 Jun 1994 13:06:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406121807.AA23839@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Sample texmf/<package> listing...
To: TWG-TDS@SHSU.edu
Date: Sun, 12 Jun 1994 20:07:26 +0100 (MESZ)
Content-Type: text
You wrote:
>
> Unless there
> are objections, I'm willing to call the
>
> texmf/package/format vs. texmf/format/package
>
> debate dead. texmf/package/format died.
>
> The main argument I've recognized against texmf/package/format in the
> last N messages is that it's impractical. I don't think it is
> technically impractical unless a few hundred K of memory for the
> database is considered prohibitive, in which case I give up. Yes, it
> requires some work on the part of the implementors (<10 people,
> probably). If that work will help the hundreds (thousands?) of TeX
> administrators and package creators, to me it seems reasonable to invest
> the work.
As a package creator, it might help me. As a TeX administrator, only
partly. One has to distinguish files that will be used by programs and
those that will be used by humans. The former can (shall?) be
organized in a way that adminstrators benefit. The latter *must* be
organized with the end user in mind.
Again my pet peeve: Where to put the documentation. I think it's
important that documentation is not too far apart. (Humans are not as
good in directory searching as programs... ;-). I.e., that there is a
texmf/doc/ directory, with at most one directory level below (used for
large categories, eg, latex/, plain/, or similar. But not for each
package!)
The point is that I mean explicitely documentation for the end user
(the writer). In previous mails the question of name collisions for
README files came up -- but their contents is typically administration
oriented, they don't explain how to _use_ something. As such they are
an integral part of the distribution and belong to such a unit.
I understand barbara's fear that people will copy only part of some
distribution. But that happens today as well; here folks copy part of
our installation without knowing what they're doing. You won't be able
to care for the MSAU (most stupid assumable user)...
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 06:36:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qDAEp-000073C@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 13 Jun 94 12:31 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, BNB@MATH.AMS.ORG
Subject: Re: texmf/ams and other packages
>The PostScript comment character is "%", so a header of
> % this is header material
> % and this is more
> % still more
> [the PS file]
>should work fine.
It's more complex than that. You HAVE to start the PS file with %! or
it won't be recognized as PS. You should also put comments like these
in an appropriate place wrt the Document Structuring Convention (see
Appendix G of the Red Book). (Why is it that Appendix G of every book
is the one which haunts me :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 08:35:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Jun 94 09:26:45 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406131326.AA06480@owl.HQ.Ileaf.COM>
To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
if related files, that happen
to be of different types (fonts, macros, ...), get split up
Exactly the argument for texmf/<package>/<format>.
>From the amount of mail I get from people saying ``I wanted to toss the
installation of TeX I inherited and start afresh'' [and here are the
bugs I found in web2c :-)], I suspect most people sincerely want to
install TeX to maximally help their users, and are tired of not knowing
what they have installed, let alone what versions they have or how to
disseminate the documentation to the users, etc.
I fear TeX will wither away unless *something* happens in this regard,
whether it be <package>/<format> or a plea that all packages come with
uniform (and uniformly changeable) install scripts, or some other as-yet
unknown option. People are willing to put in some time getting a decent
installation of TeX in place, but very few places have the resources to
dedicate a full-time person (or fraction thereof) to nothing but TeX.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 08:35:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Jun 94 09:26:46 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406131326.AA06483@owl.HQ.Ileaf.COM>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
Again my pet peeve: Where to put the documentation. I think it's
important that documentation is not too far apart. (Humans are not as
good in directory searching as programs... ;-). I.e., that there is a
texmf/doc/ directory, with at most one directory level below (used for
large categories, eg, latex/, plain/, or similar. But not for each
package!)
In my experience, users want two kinds of info -- general descriptions
of how the heck all the parts of TeX fit together, and specific
documentation of how to use xy-pic or bibtex or whatever package.
For the first kind, I agree that it should be in a separate `doc'
directory -- the one I've been arguing should be a sibling of `lib', not
`fonts' and `tex' &c (to make the separation between human-using and
program-using files clearer, and help humans (and
installers/administrators) put the pieces together).
For the second kind, I argue that the most logical place *is* a doc
directory in each (hypothetical) package directory, not in a separate tree.
I understand barbara's fear that people will copy only part of some
distribution. But that happens today as well; here folks copy part of
our installation without knowing what they're doing. You won't be able
to care for the MSAU (most stupid assumable user)...
I bet there would be far fewer problems if packages were copied and
installed as a unit than if the person has to run an install
script, or, even worse, copy things to the right place by hand (the
current method of choice :-( ).
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 11:59:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406131658.AA25438@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Sample texmf/<package> listing...
To: TWG-TDS@SHSU.edu
Date: Mon, 13 Jun 1994 18:58:43 +0100 (MESZ)
Content-Type: text
Karl wrote:
>
> In my experience, users want two kinds of info -- general descriptions
> of how the heck all the parts of TeX fit together, and specific
> documentation of how to use xy-pic or bibtex or whatever package.
>
> For the first kind, I agree that it should be in a separate `doc'
> directory -- the one I've been arguing should be a sibling of `lib', not
> `fonts' and `tex' &c (to make the separation between human-using and
> program-using files clearer, and help humans (and
> installers/administrators) put the pieces together).
Hmm, do you say that it's texmf/lib/fonts/? I thought the current
proposal was texmf/fonts/. If there exists a texmf/lib/, my notion of
texmf/doc/ would conform to your statement. I'm slightly irritated here.
But, it doesn't matter. For the record: I don't care if it's a
sibling or if its below texmf/. I'm interested that such a directory
_is_ part of the TDS.
Actually, I would present two alternative possible directory
structures. One where it doc, lib, bin is below (good for mounting in
/usr/local/lib/texmf, or /opt/texmf/, etc.) and one where doc, lib, bin
is spread around. I.e., like /usr/local/{bin,lib/texmf,doc/texmf} or
similar. Just like the X project did.
I'm sceptic that one can convice system administrater (in
computing centers, I mean ;-) to use one of these methods when their
whole system is organized according to the other method.
> I understand barbara's fear that people will copy only part of some
> distribution. But that happens today as well; here folks copy part of
> our installation without knowing what they're doing. You won't be able
> to care for the MSAU (most stupid assumable user)...
>
> I bet there would be far fewer problems if packages were copied and
> installed as a unit than if the person has to run an install
> script, or, even worse, copy things to the right place by hand (the
> current method of choice :-( ).
I would try it. But then, last week I got mail from somebody who
didn't fetch a README from CTAN, inspite the fact that he had
problems with the package. His comment was ``READMEs are always
boring, I don't read them principally.'' Such folks will make problems
anyhow, it seems like they look for it. :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 17:31:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Jun 1994 17:31:25 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097FE6A.803D5280.532@SHSU.edu>
Subject: Re: Sample texmf/<package> listing...
On Mon, 13 Jun 94 09:26:46 EDT, karl@owl.HQ.ileaf.com (Karl Berry) posted:
> In my experience, users want two kinds of info -- general descriptions of
> how the heck all the parts of TeX fit together, and specific documentation
> of how to use xy-pic or bibtex or whatever package.
>
> For the first kind, I agree that it should be in a separate `doc' directory
> -- the one I've been arguing should be a sibling of `lib', not `fonts' and
> `tex' &c (to make the separation between human-using and program-using
> files clearer, and help humans (and installers/administrators) put the
> pieces together).
>
> For the second kind, I argue that the most logical place *is* a doc
> directory in each (hypothetical) package directory, not in a separate tree.
This is conceptually behind the info/ (broadly about TeX&c) and help/
(about the CTAN and specifics of things in the archives) in the CTAN
hierarchy. I'm not foisting off the CTAN here as the TDS is a distinct
being from the CTAN. However, I think the idea of having a doc/ level at
the texmf/ level (broadly about TeX and general stuff installed -- probably
at the package level if LaTeX is called a package in the TDS syntax) and a
conditional doc/ within packages (documentation specific to the package
itself) is a good idea. Using our (admittedly probably unique in the
world) VMS setup, this is precisely what we try to support locally. A
logical TEX_INFO has things like the TeXbook, MFbook, a documented copy of
LATEX.TEX, etc., in it. Within each of the TEX_INPUTS directories, we have
a locally-created [.USAGE] subdirectory with specific documentation and
brief examples of the package. But, we might be very unique in this
regard.
--GDG
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Jun 1994 17:44:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Jun 1994 17:44:48 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0097FE6C.5F007E60.595@SHSU.edu>
Subject: Re: Sample texmf/<package> listing...
On Mon, 13 Jun 1994 18:58:43 +0100 (MESZ), Joachim Schrod
<schrod@iti.informatik.th-darmstadt.de> posted:
> I would try it. But then, last week I got mail from somebody who didn't
> fetch a README from CTAN, inspite the fact that he had problems with the
> package. His comment was ``READMEs are always boring, I don't read them
> principally.'' Such folks will make problems anyhow, it seems like they
> look for it. :-)
For those anal orifices, we can do little (they are, by and large, lost
cases anyway). However, to fail to include documentation in a well-known
area because of these hemmerroid breaths would be a gross disservice to
users, administrators, and developers alike (and, ultimately, to archivists
coordinating what needs to be pointed where from the CTAN structure to the
TDS structure). Where they're put relative to the mount point is
irrelevant; the fact that they are in a well-known area within the mount
point is not and is critical to the acceptance of thsi structure by al of
the groups identified above -- on this (as well as many other things)
Joachim and I are in apparent agreement.
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Jun 1994 10:18:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Jun 94 14:45:34 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406161445.AA16851@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
References: <199406121710.NAA00777@ruby.ora.com>
Norman Walsh writes:
> Did we ever come up with a concrete proposal for handling
> the language stuff? I haven't done enough multi-lingual
> typesetting to have a good feel for it. Can we just move
> the language stuff into the macro and font trees?
i guess we follow a consistent route (unless we invert a la Karl) and
treat a language like any other package, eg
texmf/tex/latex/icelandic/hyphenation.tex
texmf/fonts/icelandic/tfm/*
etc
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Jun 1994 10:19:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Jun 94 14:47:47 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406161447.AA16895@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
References: <199406121710.NAA00777@ruby.ora.com> <771441906.317423.BNB@MATH.AMS.ORG>
> one more plea for folks who won't be installing the entire cd,
> or running directly from the cd. if related files, that happen
> to be of different types (fonts, macros, ...), get split up
> without *very* good documentation (which many people don't read,
> anyhow, sigh), it's likely that quite a few users will get only
> part of a package, and then wonder why on earth it doesn't work.
> just scan the archives of comp.text.tex ...
lets keep distinguishing the TDS from the CD from the archives. people
install from archives into a TDS. Norm and I have as yet no detailed
plans on how to recommend partial installtion into a harddisk TDS from
a CD TDS, but i dont think that technical issue shoudl affect TDS per
se
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Jun 1994 10:19:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Jun 94 14:51:09 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406161451.AA17017@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <199406121035.AA14453@terminus.cs.umb.edu> <9406121807.AA23839@spice.iti.informatik.th-darmstadt.de>
> Again my pet peeve: Where to put the documentation. I think it's
> important that documentation is not too far apart. (Humans are not as
> good in directory searching as programs... ;-). I.e., that there is a
> texmf/doc/ directory, with at most one directory level below (used for
> large categories, eg, latex/, plain/, or similar. But not for each
> package!)
why not for each package? so long as its *rational*, and you know that
for package 'foo' there will or will not be texmf/doc/foo, its easy to
work with. orthogonality will work wonders
> README files came up -- but their contents is typically administration
> oriented, they don't explain how to _use_ something. As such they are
> an integral part of the distribution and belong to such a unit.
but we are not discussing distribution or archiving, but a working
structure
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Jun 1994 11:55:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 16 Jun 1994 09:55:44 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406161655.JAA15356@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
Complete agreement with sepastian, once again.
"Why not for each package?" barbara has expressed
concern about tying enough documentation to any
package to make it properly useful, and the
obvious place for such documentation seems to
be doc/<package>
If it is understood that even README files are in
doc/<package>, the problem of protecting them from
being overwritten is very much reduced. We don't have
to get into naming conventions like README.<truncated package name>
<package>/ % The "wrapper directory" for shipment
doc/<package name>
tex/<package name>
fonts/<package name>
. . .
seems a reasonable minimum arrangement for the majority of
packages. If it were followed, it would certainly be possible
to work out a standard script to parcel out the doc/ tex/ and fonts/
Unix tar does this very nicely, since it has no trouble
laying down a directory tree over an existing tree without
damage to parallel branches. I suppose VMS can do this, and
maybe there are now some ways to get the same effect in DOS.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Jun 1994 07:30:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 18 Jun 1994 06:46:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406181046.AA22459@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
lets keep distinguishing the TDS from the CD from the archives. people
install from archives into a TDS. Norm and I have as yet no detailed
plans on how to recommend partial installtion into a harddisk TDS from
a CD TDS, ...
I must not be making myself clear.
A `make install' or `install' procedure to get from the archives or a CD
to a working structure is certainly feasible. That's where we are now,
after all. But there are many drawbacks:
1) Not all package creators provide such a thing.
2) Even if they do, it's typically not for every operating system, nor
can package creators be reasonably expected to be familiar with every
operating system.
3) Different installation procedures inevitably require different
customization procedures (e.g., specifying the root of the tree).
Perhaps there could be a common install script that worked for many
packages on many systems, but there certainly isn't one now.
4) Even forgetting about all of the above, inevitably there will be
times when it is more convenient to just copy a few files. And then,
equally inevitably, stuff (the doc files) will get left behind.
Now, you can say ``well, it's up to the installer to do it right'', but
wouldn't it be nice for everyone if there *was* no installation to get
right or wrong? You just unpack the tar (or whatever!) archive in
texmf, and boom, you're done.
This seems feasible to me with <package>/<format>. (Which, by the way,
George initially suggested, though I'm the one wanting to carry it to
such extremes :-) Package creators can make their stuff in the
musictex-1.1/{doc,tex,fonts/src,whatever-we-decide-on} hierarchy, which
many people already do, anyway.
There are other advantages to <package>/<format> which I've blabbed
about in previous messages.
Now, obviously there are lots of details to work out about the exact
structure to put the basic Knuthian and whatever files into, but it's
pointless to spend time at that level when there is no consensus yet
about <package>/<format> vs. <format>/<package>.
Pierre and Sebastian and whoever, maybe you could recapitulate the
objections? I still don't see the problem. Sorry.
Let me include Norm's original message on this debate, which I still
think is the best summary of the whole thing.
Date: Wed, 8 Jun 1994 08:38:26 -0400
From: norm@ora.com (Norman Walsh)
To: TWG-TDS@SHSU.edu
Subject: texmf/<filetype>/<package> vs. texmf/<package>/<filetype>
On 7 June 1994 at 08:48:25, K. Berry wrote:
>
> texmf/<package>. But I like it too, *if* Karl really does think that
> texmf//tex is going to be efficient enough, and the emtex subdir
> searching permits this
There is a certain logic to inverting the order of <filetype> and
<package>, but I have some reservations:
- It's a radical departure from what everyone does now.
[ devils advocate: what's wrong with being radical? ]
- It scatters similar files all over the place. Fonts are now in
a whole bunch of directories.
[ da: so what? It moves *packages* back together ]
- It complicates subdirectory searching. I'm already worried that we
will have trouble convincing commercial implementors to do subdir
searching. I think we can argue that it's *necessary* so I'm willing
to put up the fight.
On the other hand, this scheme requires *a lot* more searching *or* a
more sophisticated searching algorithm.
[ da: with an ls-R file, this is a moot point, so stop worrying ]
Consider the difference between
TEXINPUTS=/texmf/tex/latex//:/texmf/tex/latex209:/texmf/tex/plain//
and
TEXINPUTS=/texmf/latex//:/texmf/latex209//:/texmf/plain//
Whereas KB can do TEXINPUTS=/texmf//tex//, that's more complex than
simple subdir searching.
- It moves the documentation and other non input files right back into
the way of the path searching algorithm.
[ da: so what? ]
- It really clutters up the top level /texmf directory with a lot of
directories.
[ da: no it doesn't, it makes the top level really clear; everything's
a package. ]
Gulp. I started this message firmly opposed and now I'm not so sure...
I'll try rearranging some of the /tex tree here and see what I get.
Cheers,
norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Jun 1994 17:58:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 20 Jun 1994 18:57:05 -0400
Message-ID: <199406202257.SAA29658@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Sample texmf/<package> listing...
References: <9406131326.AA06483@owl.HQ.Ileaf.COM> <9406131658.AA25438@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 13 June 1994 at 18:58:43, Joachim Schrod wrote:
> Karl wrote:
> >
> > In my experience, users want two kinds of info -- general descriptions
> > of how the heck all the parts of TeX fit together, and specific
> > documentation of how to use xy-pic or bibtex or whatever package.
> >
> > For the first kind, I agree that it should be in a separate `doc'
> > directory -- the one I've been arguing should be a sibling of `lib', not
> > `fonts' and `tex' &c (to make the separation between human-using and
> > program-using files clearer, and help humans (and
> > installers/administrators) put the pieces together).
>
> Hmm, do you say that it's texmf/lib/fonts/? I thought the current
> proposal was texmf/fonts/. If there exists a texmf/lib/, my notion of
> texmf/doc/ would conform to your statement. I'm slightly irritated here.
> But, it doesn't matter. For the record: I don't care if it's a
> sibling or if its below texmf/. I'm interested that such a directory
> _is_ part of the TDS.
I really think that a number of sibling directories is a bad idea.
Let's put everything in one place.
> Actually, I would present two alternative possible directory
> structures. One where it doc, lib, bin is below (good for mounting in
> /usr/local/lib/texmf, or /opt/texmf/, etc.) and one where doc, lib, bin
> is spread around. I.e., like /usr/local/{bin,lib/texmf,doc/texmf} or
> similar. Just like the X project did.
> I'm sceptic that one can convice system administrater (in
> computing centers, I mean ;-) to use one of these methods when their
> whole system is organized according to the other method.
Joachim's got a point. There is a precedent for allowing both. And it's
pretty easy to transform one into the other. What say you, should we
allow it?
The danger, as I see it, is that it makes two systems using the TDS
potentially different. This is a serious problem, IMHO. Especially since
I'm determined that we should create something that is *easy to document*
and *understand*.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Jun 1994 18:13:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 20 Jun 1994 19:11:40 -0400
Message-ID: <199406202311.TAA29690@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: format/package or package/format
Reply-To: TWG-TDS@SHSU.edu
Shortly after I proclaimed the debate dead, Karl offered further arguments in
favor of the package/format structure. I think I have a better understanding
of his position now, so I'll paraphrase it:
- Using /texmf/<package> makes it easier to distribute packages, since
everything remains together.
- Using /texmf/<package> makes it easier for users to find what they
need and (hopefully) reduces the number of incorrect installations
because something was left out.
- Neither system is particularly more efficient if subdir searching
is implemented right. In web2c, using /texmf//latex// will presumably
find only files in /texmf/<package>/latex/*, so there's no danger
of bad matches---in /texmf/<package>/doc, for example.
- The fact that there are a lot more files to search doesn't matter either
if subdir searching is done right.
As I see it, there are two problems:
- /texmf/<package> *really* clutters up the /texmf directory. And
yet, <package> can't occur deeper in the tree because it *contains*
everything deeper in the tree.
- It requires more sophisticated subdirectory searching than is available
currently in any implementation besides web2c. One of the strongest
arguments (or excuses) for it being acceptable to require subdir searching,
IMHO, is that *both* web2c and emTeX support it. If we switch to a
scheme that only web2c can use, we may get less cooperation from commercial
vendors. It will look, to the untrained eye, like a real Unix bias.
I think that that is potentially *DISASTEROUS* the the whole TDS.
It will also require commercial vendors to implement smarter subdir
searching in order to be TDS compatible. Ok, we all probably agree
they should implement it intelligently anyway. However, I think we'll
get more cooperation if we make it *possible* for them to implement
it in a fast, stupid manner.
I firmly believe that this issue needs to be decided *now*. I think it's
really bogging us down.
As the chair, I guess I could insist that the issue is closed and go with my
earlier statement that the issue is dead, but I'm very reluctant to do that.
Let's try an informal vote. Cast your ballots for one or the other with a
few words of justification, if you want, and let's see how we stand...
If anyone has a better suggestion, please tell me!
Pushing for cooperation,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Jun 1994 18:15:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 20 Jun 1994 19:14:25 -0400
Message-ID: <199406202314.TAA29696@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: format/package vs. package/format
Reply-To: TWG-TDS@SHSU.edu
I'm in favor of the /texmf/format/package scheme. I recognize that the
alternative has some strong points in its favor, but I think that the
difficulties (technical or political, as the case may be) could dramatically
hinder the acceptance of the TDS.
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Jun 1994 11:08:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Jun 1994 12:08:52 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406211608.AA00841@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: siblings
The danger, as I see it, is that it makes two systems using the TDS
potentially different. This is a serious problem, IMHO. Especially since
I don't follow.
No matter what winds up in the document, nothing is going to make
sysadmins think it's a good idea to conform to something that doesn't
meet their needs. If site X dumps everything in /usr/local/bin, and site
Y has separate directories (/opt/texmf) for everything, then that seems
fine. What business is of it of the TDS to dictate such decisions?
The things that I think is useful for the TDS to talk about is
1) the library files (.tex, .mf, .tfm, .pool, .fmt, ...)
2) additional tex-specific but not-read-by-programs files (tex-index,
tex-faq*, ams guides, ...)
Not binary executables or man pages.
I've been arguing for a separation (conceptual, at least) of 1) and 2)
above, but maybe it's not worth it, since there are few enough things at
the top level, i.e., /opt/texmf/{tex,fonts,doc,help,info} or
/usr/local/lib/texmf/{blah,blah,blah}, whatever.
Forget the extra lib/ level I suggested before.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Jun 1994 11:08:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Jun 1994 12:08:53 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406211608.AA00848@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: format/package or package/format
Let's try an informal vote. Cast your ballots for one or the other with a
Maybe we don't need to vote.
As the primary (only?) proponent of the <package>/<format> scheme, I am
willing to forget it as the thing for the TDS to recommend to
everyone. There's hasn't been enough (any?) experience with it to do
that -- we shouldn't standardize something untried.
Instead, we can let people who feel the need (perhaps including me :-)
try it at their sites and see how it goes.
If the TDS document describes this alternative, fine. I'll put something
about it in kpathsea anyway for people to try if they want.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Jun 1994 13:35:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Jun 94 17:26:34 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406211726.AA14829@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <199406211608.AA00848@terminus.cs.umb.edu>
"K. Berry" writes:
> As the primary (only?) proponent of the <package>/<format> scheme, I am
> willing to forget it as the thing for the TDS to recommend to
> everyone. There's hasn't been enough (any?) experience with it to do
> that -- we shouldn't standardize something untried.
i feel attracted to the package/format scheme, but i dont see its
advantages are so overwhelming that its the only choice. both methods
have advantages, so my vote (if needed) is for the existing scheme.
> If the TDS document describes this alternative, fine. I'll put something
> about it in kpathsea anyway for people to try if they want.
i think the TDS could well describe a recommended archive/distribution
tree, with notes on how it can be transformed to the working system,
but i'd want to play down the idea it is an alternative for daily use.
lets not give people choices....
i am also reluctant to suggest now that TDS94 might be superceded by
TDS95 if experiments go well with the alternative layout. but in some
ways an inversion of the same names in a tree is not half as bad as
small changes in names from eg <dpinnn> to <nnn> or vice versa for pk
directories.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Jun 1994 14:46:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Jun 1994 14:46:44 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098049C.D1F7B1A0.2561@SHSU.edu>
Subject: RE: siblings
On Tue, 21 Jun 1994 12:08:52 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> No matter what winds up in the document, nothing is going to make sysadmins
> think it's a good idea to conform to something that doesn't meet their
> needs. If site X dumps everything in /usr/local/bin, and site Y has
> separate directories (/opt/texmf) for everything, then that seems fine.
> What business is of it of the TDS to dictate such decisions?
Been thinking about this for quite some time as I know that many (if not
most) of you have rather strong feelings about mount points for the TDS.
Admittedly, I am probably the least technowledgable (and possibly
TeXnowledgable) among everyone here, but here's an idea I wanted to float
which might be a possible option. As Karl, Joachim, Pierre, and others
have pointed out, sites X and Y above represent a problem for just one
operating system, and the differentiation is admittedly defensible on many
grounds -- add that to the mix of other OS concepts and we've got a mess.
Using the concepts of the various OSes involved, with logicals, paths,
aliases, environment variables, whatevers, here's a potential solution I
would like to air out. I think it's been more or less agreed that there is
to be a root texmf/ upon which the TDS tree is to be built (correct?). I'm
assuming that texmf/ is NOT a root-level directory and it has to be mounted
somewhere, although it could be a root-level if desired (correct?). Why
not specify and define something along the lines of TDSROOT as a logical,
path, alias, environment variable -- definable as anything anyone or any
site wants -- which is the COMMON mount point which texmf/ ties to?
TDSROOT can be /usr/local/bin/ or /usr/local/ or /opt/ or C:\TEX\ or
$1$DUA14:[TEX.] or \ldots. That way, no matter what OS you are on, you
have TDSROOT/texmf/ (TDSROOT\TEXMF\ TDSROOT:[TEXMF] or whatever; it becomes
a syntax based upon and consistent with the OS itself) and the physical
location of the mount point is left wholly as a local administrative item
-- precisely as it should.
Ladies and gentlemen have I missed something or is this a workable solution
around the local control issue?
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Jun 1994 07:16:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Jun 1994 08:17:17 -0400
From: "K. Berry" <karl@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406221217.AA16473@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
i think the TDS could well describe a recommended archive/distribution
tree, with notes on how it can be transformed to the working system,
I forgot to mention this in yesterday's message, but I still think that
my previous idea of asking package creators to put their stuff in the
same hierarchy that we are suggesting (tex/, fonts/, etc.) (so the
distributions can be used as is with the flipped search path) is a good
idea.
small changes in names from eg <dpinnn> to <nnn> or vice versa for pk
directories.
We decided on fonts/source/typeface/pk/dpi300/cmr10.pk for the canonical
form of this, I thought.
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Jun 1994 07:16:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Jun 1994 08:17:17 -0400
From: "K. Berry" <karl@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406221217.AA16479@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RE: siblings
have I missed something or is this a workable solution
around the local control issue?
Sure.
My point was that the TDS should talk about the TeX files, not about the
binary executables or man pages. bin/ and man/ may or may be under
texmf/ (along with fonts/ and tex/ and doc/) but it is useless to
dictate that it must be so.
================================================================================
From owner-twg-tds@shsu.edu Fri, 24 Jun 1994 18:19:49 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 24 Jun 1994 16:20:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406242320.QAA11864@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: format/package or package/format
I have one strong, and I think valid, reason for preferring
texmf/<format>/package
On most machines I use, /fonts is a completely separate partition, which
I link into texmf. If I can ever afford it, I will probably use
some reasonably fast sort of removable disk on the /fonts partition so
that I can be a little more selective about what is there.
I suppose texmf/<package>/fonts COULD be linked, but it seems
to me to run the risk of having to read across the entire spectrum
of fonts directories for every package, over and over again.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 24 Jun 1994 18:19:52 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 24 Jun 1994 16:20:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406242320.QAA11864@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: format/package or package/format
I have one strong, and I think valid, reason for preferring
texmf/<format>/package
On most machines I use, /fonts is a completely separate partition, which
I link into texmf. If I can ever afford it, I will probably use
some reasonably fast sort of removable disk on the /fonts partition so
that I can be a little more selective about what is there.
I suppose texmf/<package>/fonts COULD be linked, but it seems
to me to run the risk of having to read across the entire spectrum
of fonts directories for every package, over and over again.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 24 Jun 1994 18:23:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 24 Jun 1994 16:23:44 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406242323.QAA12068@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: siblings
George certainly understands the mount point of texmf
in the same way I do.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 24 Jun 1994 18:27:22 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 24 Jun 1994 16:28:02 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406242328.QAA12336@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: siblings
We should definitely not try to legislate about bin and man
as part of texmf.
It happens that putting them in texmf works on Solaris2, but that
is a happy accident. It is not something
that we should suggest seriously for any other system.
================================================================================
From owner-twg-tds@shsu.edu Fri, 24 Jun 1994 18:35:15 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 24 Jun 1994 16:35:45 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199406242335.QAA12992@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
From: "K. Berry" <karl@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
We decided on fonts/source/typeface/pk/dpi300/cmr10.pk for the canonical
form of this, I thought.
Not quite. The distinction between cx and ricoh
has to be allowed for
fonts/source/typeface/pk/dpi300/cx/cmr10.pk
fonts/source/typeface/pk/dpi300/ricoh/cmr10.pk
I am willing to put in the dpi300 branch,
but I am still unwilling, in a purely Unix environment
to have multiple versions of files all named
cmr10.pk. It's bad enough in the 300-400 dpi world
t0 be stuck with multiple versions of cmr10.300pk.
But I do recognize that the platform-independent
version of the tree will have to have multiple
versions of files all named cmr10.pk
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Jun 1994 07:15:15 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9406271157.AA13332@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
Date: Mon, 27 Jun 94 07:10:29 -0400
From: bob@microprograms.com
Sebastian suggests:
> i guess we follow a consistent route (unless we invert a la Karl) and
> treat a language like any other package, eg
> texmf/tex/latex/icelandic/hyphenation.tex
> texmf/fonts/icelandic/tfm/*
> etc
Why put hyphenation files under latex? Aren't they used by both tex and latex?
Sorry about the slow comment on this---I was out of the country last week.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Jun 1994 09:39:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Jun 94 14:18:25 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9406271418.AA20286@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Handling languages...
References: <9406161445.AA16851@ftp.tex.ac.uk> <9406271157.AA13332@uu3.psi.com>
> > treat a language like any other package, eg
> > texmf/tex/latex/icelandic/hyphenation.tex
> > texmf/fonts/icelandic/tfm/*
> > etc
>
> Why put hyphenation files under latex? Aren't they used by both tex and latex?
ok, sorry, texmf/generic/icelandic/hyphenation.tex
or whatever
sevastian
From owner-twg-tds@shsu.edu Sat, 02 Jul 1994 14:12:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 2 Jul 1994 11:35:37 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407021835.LAA07311@june.cs.washington.edu>
To: tex-k@cs.umb.edu, TWG-TDS@SHSU.edu
Subject: making up some packages.
I have extracted that part of Sebastian's larger work
on postscript fonts that gives you access to the
ubiquitous 35-font package.
I propose to make up a package called lw35nfss
with the following structure
lw35nfss/
INSTALL % instructions
tex/latex/psnfss % *.sty and *.fd
fonts/adobe/times
/helvetic % tfm, vf, and afm
. % but what to do about
. % afm versions? Better
. % stick with what the
/zapfding % tfms are based on.
/dvips % *.map and config.*
% for all faces in the set.
I don't know how other systems will handle it, but in Unix
it will be possible to cd to $TEXMFROOT and tar out
all three directories in the package in place.
INSTALL will have to include a warning about moving latex209-style
style files from $TEXMFROOT/dvips to $TEXMFROOT/latex209/dvips
Since this affects the way the final UnixTeX distribution is organized
I have also made the following changes in two makefiles
First, in web2c/tex/Makefile.in
> *** Makefile.in.dist Thu Feb 3 04:48:36 1994
> --- Makefile.in Sat Jul 2 10:48:45 1994
> ***************
> *** 58,64 ****
>
> # The formats we know how to make.
> fmts = amslatex.fmt amstex.fmt etex.fmt inrstex.fmt latex.fmt \
> ! picplus.fmt slitex.fmt tex.fmt texinfo.fmt
>
> # And how to make them.
> initex = TEXPOOL=. ./initex
> --- 58,64 ----
>
> # The formats we know how to make.
> fmts = amslatex.fmt amstex.fmt etex.fmt inrstex.fmt latex.fmt \
> ! picplus.fmt tex.fmt texinfo.fmt # slitex.fmt
>
> # And how to make them.
> initex = TEXPOOL=. ./initex
> ***************
> *** 122,131 ****
> # 4) a ``preload'' file, (I use preload.ori),
> # 5) and a ``basefont'' file. (I use basefont).
> # How automatic, huh? I can hardly wait for LaTeX 3.
> ! amslatex.fmt: initex
> ! $(initex) lplain \\dump
> ! mv lplain.fmt amslatex.fmt
> ! mv lplain.log amslatex.log
>
> # As of AMSTeX 2.1, the initialization file is named `amstex.ini'.
> # Because it explicitly reads plain.tex, we cannot use &./tex; that
> --- 122,131 ----
> # 4) a ``preload'' file, (I use preload.ori),
> # 5) and a ``basefont'' file. (I use basefont).
> # How automatic, huh? I can hardly wait for LaTeX 3.
> ! #amslatex.fmt: initex
> ! # $(initex) lplain \\dump
> ! # mv lplain.fmt amslatex.fmt
> ! # mv lplain.log amslatex.log
>
> # As of AMSTeX 2.1, the initialization file is named `amstex.ini'.
> # Because it explicitly reads plain.tex, we cannot use &./tex; that
> ***************
> *** 142,159 ****
> inrstex.fmt: initex
> $(initex) inrstex \\dump
>
> latex.fmt: initex
> ! $(initex) lplain \\dump
> ! mv lplain.fmt latex.fmt
> ! mv lplain.log latex.log
>
> picplus.fmt: tex.fmt
> $(initex) \&./tex picplus \\dump
>
> ! slitex.fmt: initex
> ! $(initex) splain \\dump
> ! mv splain.fmt slitex.fmt
> ! mv splain.log slitex.log
>
> tex.fmt: initex
> $(initex) plain \\dump
> --- 142,165 ----
> inrstex.fmt: initex
> $(initex) inrstex \\dump
>
> + #latex.fmt: initex
> + # $(initex) lplain \\dump
> + # mv lplain.fmt latex.fmt
> + # mv lplain.log latex.log
> + # The dump command for LaTeX2e is included
> + # in latex.ltx. This probably provides all
> + # you need for amslatex as well.
> +
> latex.fmt: initex
> ! $(initex) latex.ltx
>
> picplus.fmt: tex.fmt
> $(initex) \&./tex picplus \\dump
>
> ! #slitex.fmt: initex
> ! # $(initex) splain \\dump
> ! # mv splain.fmt slitex.fmt
> ! # mv splain.log slitex.log
>
> tex.fmt: initex
> $(initex) plain \\dump
> ***************
> *** 279,288 ****
> rm -f *.o $(program) $(lib) $(programs)
>
> clean:: mostlyclean
> ! rm -f *.dvi *.pool
>
> distclean:: clean
> ! rm -f Makefile config.status c-auto.h
>
> # Although we can remake configure and c-auto.h.in, we don't remove
> # them, since many people may lack Autoconf. Use configclean for that.
> --- 285,294 ----
> rm -f *.o $(program) $(lib) $(programs)
>
> clean:: mostlyclean
> ! rm -f *.dvi
>
> distclean:: clean
> ! rm -f Makefile config.status c-auto.h *.p *.pool
>
> # Although we can remake configure and c-auto.h.in, we don't remove
> # them, since many people may lack Autoconf. Use configclean for that.
And in dvipsk/PSfonts/Makefile.in (Sorry, this is not a diff.)
> oldlatexinputdir = $(texmf_prefix)/latex209
> psmacrodir = $(oldlatexinputdir)/dvips
> # These were the original macros, before LaTeX2e
> # texinputdir = $(texmf_prefix)/tex
> # psmacrodir = $(texinputdir)/dvips
I want to pass this by interested parties before I actually do it.
The next thing is to repackage ibygrk to conform as closely as possible
with the TDS recommendations. If I do that, I should also do the
same for Levy's stuff (I am in correspondence with him at present)
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Jul 1994 15:58:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 2 Jul 94 19:56:11 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407021956.AA01535@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
CC: tex-k@cs.umb.edu
Subject: Re: making up some packages.
References: <199407021835.LAA07311@june.cs.washington.edu>
not entirely sure what you mean by a `package' in this context,
Pierre? but the concept seems good to me. my only question is
compatibility with the `traditional' .sty files described eg in the
latex companion, like times.sty. the .sty files under fonts/metrucs
load one family only, consistently, but the ones in psnfss load
several. its a mess, complained about elsewhere often. one day we have
to bite the bullet and change the expectation that
`\usepackage{times}' sets sans to Helvetica, and tt to Courier
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Jul 1994 15:58:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 2 Jul 94 19:59:22 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407021959.AA01557@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
CC: tex-k@cs.umb.edu
Subject: Re: making up some packages.
References: <199407021835.LAA07311@june.cs.washington.edu>
by the way, lets all keep track of this business of auto-making a
latex2e format in the web2c setup. Someone (Joel) is already working
on configure scripts for latex2e to fold in to web2c, and Karl is in
touch with him, so anyone else doing similar should keep Karl aware of
what they are doing, or we'll all go mad(der).
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Jul 1994 16:07:44 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 2 Jul 1994 14:08:24 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407022108.OAA15105@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu, spqr@ftp.tex.ac.uk
Subject: Re: making up some packages.
CC: tex-k@cs.umb.edu
Maybe package is the wrong word, but when I started using it
a while ago, I did not appreciate how absolutely LaTeX2e
wanted to take over the word. What I mean is a collection
of files under a single wrapper, arranged so that they
can be distributed with relative ease in a "standard"
$TEXMFROOT/ tree. That is the reason for the extra levels
ov directory in what is a rather simple lot of files. They
are supposed to match the most probable arrangement
of directories in a TeX installation.
About three weeks ago we were discussing the possibility
of setting up---I can't think of any word but---packages
whose organization would reflect the broad arrangement of
the TDS, and I suggested that contributors might be asked
to arrange their stuff accordingly. I am trying to practice
what I preach.
As for the current arrangement of times. I see no harm in it
as a basic lot of choices. Helvetica and Courier are both
part of the 35font set, and are accessible to the vast majority
of people who have PostScript printers. The times.sty file is
available as a model for someone who wants to change the defaults
and make up a timesg, with GillSans in place of the Helvetica.
I just want to get enough of a collection of models and working
files out that people can use them and learn from them It is
clearly not going to be possible to provide all the permutations
even of the 35font resource, but there is enough in the files
I have got from your larger set to get people started.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Jul 1994 16:14:18 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 2 Jul 1994 14:14:58 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407022114.OAA15507@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu, spqr@ftp.tex.ac.uk
Subject: Re: making up some packages.
CC: tex-k@cs.umb.edu
The changes I have made in the UnixTeX version of the Makefiles
are the simplest stopgap I can manage. There is no attempt
to play configuration games. They simply recognize that
LaTeX2e is the default now, and not latex209. I shall
be very happy to chuck this stopgap in favor of a more
systematic configuration plan, but I can't send out a
Makefile asking for lplain when lplain is no longer in the
normal paths.
Likewise for the placement of the old-style times.sty and its
cousins. I have to divert them so that thay don't overwrite
the ones that work with LaTeX2e.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Sun, 03 Jul 1994 11:49:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 3 Jul 94 16:44:11 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407031644.AA23339@ftp.tex.ac.uk>
To: mackay@cs.washington.edu
CC: TWG-TDS@SHSU.edu, tex-k@cs.umb.edu
Subject: Re: making up some packages.
References: <199407022108.OAA15105@june.cs.washington.edu>
Pierre MacKay writes:
> a while ago, I did not appreciate how absolutely LaTeX2e
> wanted to take over the word. What I mean is a collection
the bit that CTAN hasnt taken over already....
> the TDS, and I suggested that contributors might be asked
> to arrange their stuff accordingly. I am trying to practice
> what I preach.
i am just thinking back to CTAN and how to integrate things like these
"packages" into that. i sometimes think CTAN needs a much clearer
split into `archive' and `production'
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Jul 1994 05:21:55 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qKl3R-0006TwC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 4 Jul 94 11:15 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, tex-k@cs.umb.edu
Subject: Re: making up some packages.
>to bite the bullet and change the expectation that
>`\usepackage{times}' sets sans to Helvetica, and tt to Courier
Or create new packages fnttimes, fntpalat, (or fontptm, fontppl) etc.
that do the right thing.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Jul 1994 13:17:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Jul 94 18:11:32 GMT
From: spqr@ftp.tex.ac.uk (Sebastian Rahtz)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407041811.AA19516@ftp.tex.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: making up some packages.
References: <9407021956.AA01535@ftp.tex.ac.uk> <m0qKl3R-0006TwC@rsuna.crn.cogs.susx.ac.uk>
oh sigh. shades of nftimes ....
s
================================================================================
From owner-twg-tds@shsu.edu Tue, 05 Jul 1994 12:00:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Tue, 5 Jul 1994 12:59:21 -0400
Message-ID: <199407051659.MAA25935@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <199406221217.AA16473@terminus.cs.umb.edu> <199406242335.QAA12992@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 24 June 1994 at 16:35:45, Pierre MacKay wrote:
>
> From: "K. Berry" <karl@cs.umb.edu>
> Reply-To: TWG-TDS@SHSU.edu
> To: TWG-TDS@SHSU.edu
> Subject: Re: format/package or package/format
>
> We decided on fonts/source/typeface/pk/dpi300/cmr10.pk for the canonical
> form of this, I thought.
>
> Not quite. The distinction between cx and ricoh
> has to be allowed for
>
> fonts/source/typeface/pk/dpi300/cx/cmr10.pk
> fonts/source/typeface/pk/dpi300/ricoh/cmr10.pk
Actually, I'd been shooting for
fonts/<source>/<typeface>/pk/<mode>/<dpi>/cmr10.pk
> I am willing to put in the dpi300 branch,
> but I am still unwilling, in a purely Unix environment
> to have multiple versions of files all named
> cmr10.pk. It's bad enough in the 300-400 dpi world
> t0 be stuck with multiple versions of cmr10.300pk.
I don't see anything wrong with using
fonts/<source>/<typeface>/pk/<mode>/dpi300/cmr10.300pk
in a Unix environment, but I'd like to leave the 'dpi300' level in there.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 05 Jul 1994 13:57:48 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 5 Jul 1994 11:58:31 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407051858.LAA05231@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Norm has got it right, and I have no problem with the
slight redundancy of
fonts/<source>/<typeface>/pk/<mode>/dpi300/cmr10.300pk
I got the <mode> level in the wrong place, and
Norm's version is what I should have written.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 04:47:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 6 Jul 1994 05:48:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407060948.AA13842@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Why do you want to keep the dpi300/ level?
I mean, yes, the TDS should recommend that for maximum portability,
obviously, but if a site does not care about DOS programs
and Unix programs reading from the same filesystem, then I
think it is an unnecessary burden -- cmr10.300pk and dpi300/cmr10.pk
seem like two different ways of representing the same thing to me.
dpi300/cmr10.300pk just seems to add confusion.
However, I don't want to argue too strongly about the whole thing.
I already changed kpathsea so it will support both (simultaneously).
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 06:54:20 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 6 Jul 1994 07:52:46 -0400
Message-ID: <199407061152.HAA27027@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <199407060948.AA13842@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 6 July 1994 at 05:48:21, K. Berry wrote:
> Why do you want to keep the dpi300/ level?
> I mean, yes, the TDS should recommend that for maximum portability,
> obviously, but if a site does not care about DOS programs
> and Unix programs reading from the same filesystem, then I
> think it is an unnecessary burden -- cmr10.300pk and dpi300/cmr10.pk
> seem like two different ways of representing the same thing to me.
> dpi300/cmr10.300pk just seems to add confusion.
My feeling was that the TDS should specify a _single_ structure if at all
possible. I don't see anything wrong with using different filenames in
the Unix case, but suggesting that Unix sites flatten the TDS by one directory
level makes it look "uncomfortably" different, in my eyes.
And it didn't seem too outrageous to duplicate the information in the Unix
case. I suppose I could argue that it would also make it easier for users
at that site to tar up the whole thing and take it home to their PCs,
but that's a pretty weak argument :-(
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 07:48:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 06 Jul 1994 07:48:41 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098102B.E760FB24.5815@SHSU.edu>
Subject: Re: format/package or package/format
On Wed, 6 Jul 1994 05:48:21 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> Why do you want to keep the dpi300/ level? I mean, yes, the TDS should
> recommend that for maximum portability, obviously, but if a site does not
> care about DOS programs and Unix programs reading from the same filesystem,
> then I think it is an unnecessary burden -- cmr10.300pk and dpi300/cmr10.pk
> seem like two different ways of representing the same thing to me.
> dpi300/cmr10.300pk just seems to add confusion.
I would completely trash any and all references (especially future
references) to a name such as dpi300/cmr10.300pk as it (a) adds confusion,
(b) is not portable, and (c) requires unnecessary additional maintenance to
software authors/maintainers. I completely understand that the X.300pk is
an existing more or less de facto standard which is a result of an
evolutionary process, especially focused on Unix operating systems, but it
is a standard whose time has come and gone if we are anywhere near
interested in getting a close to generic installation based on a common
directory structure. I also completely understand that the use of the new
and explicitly stated standard will require some retrofitting for existing
software, but this is a move in which the larger TeX community (i.e., all
operating systems) gains in the short-run and in which existing
implementations using the older syntax gain in the long-run since we can
focus on a specific and known syntax which does not require any porting
efforts to anywhere else.
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 08:17:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 6 Jul 1994 09:14:37 -0400
Message-ID: <199407061314.JAA27571@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <0098102B.E760FB24.5815@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 6 July 1994 at 07:48:41, George D. Greenwade wrote:
>
> I would completely trash any and all references (especially future
> references) to a name such as dpi300/cmr10.300pk as it (a) adds confusion,
> (b) is not portable, and (c) requires unnecessary additional maintenance to
> software authors/maintainers. I completely understand that the X.300pk is
> an existing more or less de facto standard which is a result of an
> evolutionary process, especially focused on Unix operating systems, but it
> is a standard whose time has come and gone if we are anywhere near
> interested in getting a close to generic installation based on a common
> directory structure. I also completely understand that the use of the new
> and explicitly stated standard will require some retrofitting for existing
> software, but this is a move in which the larger TeX community (i.e., all
> operating systems) gains in the short-run and in which existing
> implementations using the older syntax gain in the long-run since we can
> focus on a specific and known syntax which does not require any porting
> efforts to anywhere else.
As usual, I find myself in complete agreement with George. I have resisted
the temptation to deprecate the X.300pk naming convention because I know
how widely and strongly entrenched it is in the Unix community. Personally,
I think it's better than the alternative (and have considered using it on
my OS/2 box, actually) but it will not be a portable solution any time in
the near future.
Although there is nothing that we can do to prevent existing sites from
continuing in the old ways, perhaps we shouldn't encourage it. Comments?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 08:46:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 06 Jul 1994 09:46:56 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
To: TWG-TDS@SHSU.edu
Message-ID: <773502416.302631.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i asked something like this once before, and don't remember being
completely satisfied by the answer.
how to distinguish between cmr10 generated at 300dpi at 20pt and
cmr10 generated at 600dpi for the same printer (which can use
fonts at either 300 or 600dpi)? surely they'd both get filed in
.../printer-type/dpi600/cmr10.pk
so something else would need to be done to differentiate them.
if the mode_defs are not identical in all respects excopt for the
resolution, the rasters won't be identical. if one wants the *best*
results, then (i would think) there should be provision made for
both. maybe this is picking nits to too great a degree, but i
think it needs a conscious decision, not just doing what is most
convenient.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 08:49:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 06 Jul 1994 08:49:39 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981034.6BC84504.5847@SHSU.edu>
Subject: Re: format/package or package/format
I hate too keep on and on about something, but,....
On Wed, 6 Jul 1994 09:14:37 -0400, norm@ora.com (Norman Walsh) ended his
post with:
> Although there is nothing that we can do to prevent existing sites from
> continuing in the old ways, perhaps we shouldn't encourage it. Comments?
Precisely! How existing implementations are run (and how any
implementation is set up) is purely a local matter. My larger concern is
that we have some form of semblence which is consistent for recommended
future installations. How I have my old and trusy Epson QX-10 (one of the
best ever CP/M machines ever made) set up is my business and I will
probably never move to any other standards on it, regardless of any edict
from anyone anywhere. How I set up my new Pentium is something I certainly
would appreciate guidance on and would hope that a consistently-used set of
instructions could be available, especially for something which is touted
so strongly as being platform independent such as TeX and friends. Also, I
would love to have a one-peaked learning curve which I could apply,
virtually directly, on my also-new Alpha box.
The issue for the TDS, at least in my mind and my understanding of the
exercise, is NOT placating existing installations; instead, it is helping
future installations move toward some agreed-upon and useful standard which
is extensible into the foreseeable future. Quite possibly, every existing
installation will have something to change -- the important aspect is that
that change makes sense for the bigger picture.
--George
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 08:56:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 6 Jul 1994 09:54:47 -0400
Message-ID: <199407061354.JAA27675@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <199407061314.JAA27571@jasper.ora.com> <773502416.302631.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 6 July 1994 at 09:46:56, BNB@math.ams.org wrote:
>
> how to distinguish between cmr10 generated at 300dpi at 20pt and
> cmr10 generated at 600dpi for the same printer (which can use
> fonts at either 300 or 600dpi)? surely they'd both get filed in
> .../printer-type/dpi600/cmr10.pk
> so something else would need to be done to differentiate them.
That's no different than saying they'd both get stored in
.../printer-type/cmr10.600pk
now. But...
> if the mode_defs are not identical in all respects excopt for the
> resolution, the rasters won't be identical. if one wants the *best*
> results, then (i would think) there should be provision made for
> both. maybe this is picking nits to too great a degree, but i
> think it needs a conscious decision, not just doing what is most
> convenient.
What you have identified as /printer-type/ is actually supposed to be (derived
from) the MF mode name used to build the bitmaps. So for a 300/600dpi
switchable printer, you might have
.../foothree/dpi600/cmr10.pk
and
.../foosix/dpi600/cmr10.pk
respectively. On the other hand, there is no difference between
cmr10 at 20pt for a 300dpi printer and cmr10 for a 600dpi printer if
the same mode is used to build both bitmaps.
[ The name of the /printer-type/ directory is probably not something
we can specify for every possible mode, but I'm open to suggestions ]
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 08:57:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 6 Jul 1994 15:56:02 GMT+200
From: Erik Frambach <E.H.M.Frambach@eco.rug.nl>
Subject: Re: format/package or package/format
To: TWG-TDS@SHSU.EDU
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <217B8CC33E9@eco3.eco.rug.nl>
Content-Transfer-Encoding: 7BIT
> how to distinguish between cmr10 generated at 300dpi at 20pt and
> cmr10 generated at 600dpi for the same printer (which can use
> fonts at either 300 or 600dpi)? surely they'd both get filed in
> .../printer-type/dpi600/cmr10.pk
> so something else would need to be done to differentiate them.
Any printer that has `x' personalities should have `x' directories.
We should treat them as different printers. Directories reflect
printer-TYPES, not physical printers.
Erik Frambach
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 09:04:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 6 Jul 1994 10:02:31 -0400
Message-ID: <199407061402.KAA27692@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Spec: First Draft
Reply-To: TWG-TDS@SHSU.edu
Folks,
Here's the first draft of a spec for the TDS. Comments, suggestions, and
improvements, please!
I've also made the spec available via anon. ftp in
jasper.ora.com:/private/twg-tds/*
\documentstyle{article}
\def\ext#1{\texttt{#1}}
\def\env#1{\texttt{#1}}
\def\tds{\TeX\ Directory Structure}
\def\MF{{\fontfamily{logo}\selectfont METAFONT}}
\def\filename#1{\texttt{#1}}
\def\dir#1{\texttt{#1}}
\title{A Directory Structure for Implementation-Independent \TeX\ Material}
\author{The \TeX\ Working Group on a \TeX\ Directory Structure%
\thanks{%
Barbara Beeton,
Karl Berry,
Vicki Brown,
David Carlisle,
Erik Frambach,
Michel Goossens,
George D. Greenwade,
Bob Harris,
Alan Jeffrey,
Pierre MacKay,
Rich Morin,
Sebastian Rahtz (TUG Technical Council Liaison),
Joachim Schrod,
Elizabeth Tachikawa, and
Norman Walsh (Chair)}}
\begin{document}
\maketitle
\tableofcontents
\section{Introduction}
\TeX\ is a widely used, highly successful document preperation system.
One of the reasons that it has been successful is that it is
powerful---there are very few typesetting tasks that \TeX\ cannot
handle. Another reason is that it's free.
Because it is cheap and powerful, thousands of people around the
world have installed it and use it every day. Unfortunately, power
breeds complexity and \TeX\ can be more than a little difficult to
install. This has resulted in hundreds of slightly different installed
configurations.
The purpose of this document is to describe a standard directory
structure for macros, fonts, and other implementation-independent \TeX\
files. We hope that developers of both free and commercial implementations
of \TeX\ will adopt this standard immediately. It has been designed to
work on all modern architectures. In particular, it can be used
on Unix workstations, MS-DOS and OS/2 PC's, Macintoshes, and VMS machines.
\subsection{Technical Requirements}
Many \TeX\ installations currently store large numbers of related files in
single directories. Frequently, for example, all \ext{TFM} files go in a
single directory and most, if not all, \TeX\ input files (\LaTeX\
style files, Plain \TeX\ macro files, etc.) go in another single directory.
This monolithic arrangement makes maintainance of \TeX\ software
a nightmare. It can also be the source of catastrophic error if two or
more macro packages happen to have input files with the same name.
Most implementations provide some ability to load files from different
directories by specifying a list of directories to search (in the
\env{TEXINPUTS} environment variable or a system configuration file,
for example), but this is insufficient in the general case.
As a result, the TWG decided that a comprehensive \tds\ required
some form of subdirectory searching. In other words, it must be possible
to specify that \TeX\ (and other \TeX\ utilities) search in both a
specified directory and recursively through all subdirectories of that
directory when looking for an input file.
This feature is already supported by the \textit{web2c} distributions of
\TeX\ (available for UNIX workstations and ported to MS-DOS, OS/2,
Windows-NT, Macintosh, NeXT, and other systems) and the \textit{em\TeX}
distribution for MS-DOS and OS/2.
\subsection{Constraints}
Having accepted that subdirectory searching was necessary, the TWG
agreed to adhere to the following constraints in designing the \tds.
\begin{itemize}
\item One use of this proposed standard will be on mountable media
such as CD-ROMs. The limitations of CD-ROMs are similar to the
limitations of the MS-DOS file system. In particular, the ISO 9660
CD-ROM standard\footnote{Unix users may be familiar with the Rock
Ridge extensions which circumvent these limitations and provide a
much more flexible file system. Since the \tds\ is designed for
many architectures, we cannot rely on these extensions.} requires
monocase, 8.3 filenames with no more than eight levels of
subdirectories. In addition, filenames may only contain letters,
digits and underscores and directory names may not have extensions.
The most troubling limitation is monocase names because \LaTeX\
uses mixed case names for font descriptor files. However, this
problem is surmountable. In particular, note that MS-DOS, OS/2,
Windows-NT, and Macintosh file systems are not case-sensitive,
therefore a request for \filename{OT1cmr.fd} can always be
satisfied by \filename{ot1cmr.fd}. In addition, UNIX file systems
support symbolic links, which allows a CD-ROM to be accessed
through a ``link farm'' with little space overhead on a local disk.
\item Automatic font generation is a big win on systems that do not have
access to scalable fonts. It is important that the \tds\ not restrict
the applicability of automatic font generation. The arrangement
described in this document has been succesfully used for automatic
font generation on a number of systems.
\end{itemize}
\section{Rooting the Tree}
The \tds\ is rooted at a directory called \dir{texmf}. The location of
this directory within the file system is up to the installer. On
many systems, this may be at the root of the filesystem; however, on
UNIX systems, this would traditionally be located in \dir{/usr/local}.
The name \dir{texmf} was chosen for several reasons: it reflects the
fact that the directory contains more than \TeX\ files (it also contains
fonts), it is likely to be unused, and it is descriptive of a generic
installation rather than a particular implementation (such as \dir{emtex},
or \dir{pctex}).
The \dir{texmf} root \textit{should not} be placed under a system-dependent
directory. For example, \dir{texmf} should not be created in the
\dir{emtex} or \dir{pctex} directories!
\subsection{Top Level Directories}
The top level directories in the \dir{texmf} directory identify the major
components of a \TeX\ system for which implementation-independent input files
exist.
The directories specified in this document are:
\begin{description}
\item [tex] for the input files used by \TeX.
\item [fonts] for the font-related files.
\item [doc] for \textit{user} documentation.
\end{description}
As mentioned in Section~\ref{sec:otherdirs}, additional directories may
be used for other, standard, purposes (at the discretion of the installer
and system administrator): \dir{bin}, \dir{man}, \dir{ini}, $\ldots$
\section{Macros}
The current practice of lumping files into a single directory (or a
few directories) has the disadvantage of making it difficult to
determine which input files are associated with which macro packages,
and may result in version mismatches and other errors when a package
is upgraded, especially if the names of some files change.
To combat this maintainance problem, the \tds\ specifies that macros
should be stored in seperate directories, one for each package:
\begin{center}
\dir{texmf/tex/}%
\textit{format}\dir{/}%
\textit{package}\dir{/}%
\textit{files}
\end{center}
\begin{description}
\item[format] is the name of the \TeX\ format file that uses these
files. \dir{plain}, \dir{latex209},
\dir{latex}, and \dir{musictex} are examples of \textit{formats}.
By providing a format directory, subdirectory searching can be limited
to only those directories that contain relevant files.
For some formats, it may be natural to search more than one format
directory. For example, both the \dir{latex} and \dir{plain}
directories may be searched when using \LaTeX. In cases like this,
packages should be installed at the end of the natural search order.
For example, a package usable under \LaTeX, \LaTeX209, and Plain \TeX\
should be stored in the \dir{plain} tree.
\item[package] is the name of the package
\dir{ams}, \dir{seminar}, and \dir{pstricks} are examples of
\textit{packages}.
Packages that consist of only a single file, or a small number of
independent files, may be installed in the \dir{misc} package
directory. This usage is discouraged unless the package really consists
of only a single file.
\end{description}
\section{Fonts}
Like macros, fonts need to be stored in a hierarchical structure in order to
make maintainance possible. The \tds\ specifies that fonts should be stored
in seperate directories, one for each family:
\begin{center}
\dir{texmf/fonts/}%
\textit{source}\dir{/}%
\textit{typeface}\dir{/}%
\end{center}
\begin{description}
\item[source] is the name of the font vendor or ``\dir{public}'' for
freely available fonts. \dir{adobe},
\dir{monotype}, and \dir{public} are examples of \textit{source}.
\item[typeface] is the name of the typeface family. \dir{cm}, \dir{concrete},
\dir{bookman}, and \dir{courier} are examples of \textit{typeface}.
\end{description}
Additional directories within the \textit{typeface} directory hold
specific types of files. These directories are summarized in
Table~\ref{tab:src}.
\begin{table}
\begin{tabular}{l|l}
Directory & Contains \\
\hline
\dir{src} & Font sources (\MF\ files, property lists, etc.)\\
\dir{tfm} & \ext{TFM} files\\
\dir{vf} & Virtual fonts\\
\dir{afm} & Adobe font metrics\\
\dir{pfa} & Type 1 fonts in \ext{PFA} format\\
\dir{pfb} & Type 1 fonts in \ext{PFB} format\\
\dir{pk} & \ext{PK} bitmapped fonts\\
\hline
\end{tabular}
\caption{The directories under \textit{typeface}.}
\label{tab:src}
\end{table}
\subsection{Font Bitmaps}
The \ext{PK} bitmaps for each font require special attention. In
addition to the name of the font, two more characteristics are
required to uniquely identify a bitmap font: the type of printer
(mode) for which the font was created and the resolution of the
bitmap.
To identify the mode, fonts are typically segregated into different
directories. To identify the resolution, there are two common ways of
naming bitmap font files. On systems which allow long filenames, the
convention is usually to include the resolution in the filename. For
example, the 300dpi bitmap of \filename{cmr10} is named
\filename{cmr10.300pk}. On other systems, for example MS-DOS, the
fonts are generally segregated into different directories for each
resolution. For example, the same 300dpi bitmap would be named
\filename{cmr10.pk} in the directory \filename{300dpi}.
Since long filenames are technically impossible on many file systems,
the \tds\ has adopted the latter sheme for naming fonts. Under the \dir{pk}
directory, two more subdirectory levels are used:
\begin{center}
$\ldots$\dir{/pk/}%
\textit{mode}\dir{/}%
\textit{dpi}\dir{/}%
\textit{files}
\end{center}
\begin{description}
\item[mode] is the mode name which identifies the printer type. This
is usually the name of the \MF\ mode used to build the \ext{PK} file.
\dir{ljfour}, \dir{canoncx}, and \dir{linotype} are examples of \textit{mode}.
For PostScript fonts rendered as bitmaps with the \textit{ps2pk} program,
the mode \dir{ps2pk} should be used.
\item[dpi] is the resolution of the font. The directory name should
consist of the string \dir{dpi} followed by the numeric value of the
resolution in decimal. \dir{dpi300}, \dir{dpi328}, and
\dir{dpi1404} are examples of \textit{dpi}.
It is necessary to place \dir{dpi} in front of the resolution because
some file systems require names to begin with a letter.
\end{description}
%% Up for discussion...
%In order to retain some degree of compatability with existing systems
%that use long names, the \tds\ allows the use of long names within the
%\ext{dpi}\textit{res} directory (for example,
%$\ldots$\dir{/pk/}\textit{mode}\dir{/dpi300/cmr10.300pk}
%However,
%the two conventions should not be mixed on the same system!
\section{Documentation}
Most packages come with some form of documentation. In order to make
it easier for users to find this documentation, the \tds\ specifies that
documentation should be stored in a structure that parallels the fonts
and macros directories.
\begin{center}
\dir{texmf/doc/}%
\textit{package}\dir{/}%
\textit{files}
\end{center}
\begin{description}
\item[package] is the name of the package.
\dir{ams}, \dir{seminar}, and \dir{pstricks} are examples of
\textit{packages}.
Packages that consist of only a single file, or a small number of
independent files, may be installed in the \dir{misc} package
directory.
\item[files] are determined by the package documenter.
Below the level of the \textit{package}, the \tds\ does not make any
demands on the arrangement of files. The documentation directory
may contain \TeX\ sources, \ext{DVI} files, text files, or whatever
form of documentation will best explain the package.
\end{description}
The documentation for \textit{formats} may be stored in the directory
\dir{texmf/doc/}\textit{format}\dir{/}.
\section{Other Directories}
\label{sec:otherdirs}
Although designed to be implementation-independent, the TWG recognizes
that some insallers may wish to place other files in the \tds. For
example, UNIX sites may wish to place all \TeX\ related files including
binaries, manual pages, pool files, and formats in the \dir{texmf} tree
(this greatly simplifies administration if the \TeX\ tree is maintained
by someone other than the system administrator).
In order to ease the transition from existing arrangements to the \tds,
these extensions are allowed. However, commercial vendors and
system distributors are encouraged to keep system dependent files seperate
from the \tds. This facilitates the installation of several \TeX\
implementations on the same system without either duplication of the
\tds\ or collision between systems.
\section{Package Distribution}
We encourage package authors to build their distribution archives in
a structure that parallels the \tds. This will make package installation
much easier for the installer and much more regular across packages.
For example, a package for Martian language typesetting might include
the following files:
\begin{verbatim}
doc/martian/read.me
doc/martian/martdoc.tex
doc/martian/example.tex
tex/plain/martian/marthyph.tex
tex/latex/martian/martian.sty
tex/latex/martian/OT1mart.fd
fonts/martian/src/martian.mf
fonts/martian/src/mart10.mf
fonts/martian/tfm/mart10.tfm
\end{verbatim}
\section{Example}
The following example shows how the directories of a very small
\TeX\ system might be arranged:
\begin{verbatim}
texmf/tex/plain/base
texmf/tex/plain/ams
texmf/tex/latex/base
texmf/tex/latex/ams
texmf/fonts/public/cm
texmf/fonts/public/cm/src
texmf/fonts/public/cm/tfm
texmf/fonts/public/cm/pk
texmf/fonts/public/cm/pk/canoncx
texmf/fonts/public/cm/pk/canoncx/dpi300
texmf/fonts/ams/euler/...
texmf/fonts/ams/cyrillic/...
texmf/fonts/ams/cmextra/...
texmf/fonts/ams/symbol/...
texmf/doc/local/...
texmf/doc/plain/...
texmf/doc/latex/...
texmf/doc/ams/...
\end{verbatim}
\end{document}
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 09:10:47 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Date: Wed, 06 Jul 1994 14:56:47 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:223930:940706135657"@cl.cam.ac.uk>
>
> how to distinguish between cmr10 generated at 300dpi at 20pt and
> cmr10 generated at 600dpi for the same printer (which can use
> fonts at either 300 or 600dpi)? surely they'd both get filed in
> .../printer-type/dpi600/cmr10.pk
> so something else would need to be done to differentiate them.
surely the mode name is what we should use, to differntiate `printer
at 300' and `printer at 600'?
how many printers are there like this?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 10:41:28 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Date: Wed, 06 Jul 1994 16:31:16 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:265060:940706153141"@cl.cam.ac.uk>
i'm with George as well. the TDS should say dpi/font.pk, no two ways
about it.
i think we should get this TDS on the road, or it will get even more
TeDiouS
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 12:38:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 6 Jul 94 10:36:15 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407061736.AA07041@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Spec: First Draft
First, I'd like to thank Norman for creating and posting this. After a
few weeks of stealthy lurking on this list, I now begin to feel I have
some idea of what is being discussed. Now, as requested:
1. Nits:
"insallers" -> "installers"
"maintainance" -> "maintenance" (several times)
"seperate" -> "separate" (several times)
"sheme" -> "scheme"
\item[package] is the name of the package.
^
2. Additions:
Monolithic directories also result in:
slow search times (linear or worse)
difficulty in examination by humans
difficulty and errors in wild-card usage
3. Questions:
Is there any problem with using texmf, based on the fact that
web2c already uses it?
4. Comments:
Using "public" as the name for all freely available fonts is
an invitation to frequent name clashes. Might I suggest that
"ctan" be used for all names conforming to the CTAN's naming
structure, and that "other" be used for the rest? In fact,
some generalization of this might be in order for other areas.
I see some possibility for clashes in the doc area, for two
reasons. First, there is nothing to keep multiple developers
from naming packages identically. Second, I wonder if there
might not be situations where, for instance, a font and a
macro package had the same name.
My own suggestion would be to place doc directories in the
directories they document. This resolves the possibility of
name clashes, at the cost of a somewhat scattered set of
documentation. Also, if done properly, it causes doc files
to cover issues of relevance at the level in question.
Yours, Rich
rdm@cfcl.com
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 15:47:46 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: rdm@cfcl.com
Subject: Re: Spec: First Draft
Date: Wed, 06 Jul 1994 21:40:37 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:079660:940706204044"@cl.cam.ac.uk>
> Using "public" as the name for all freely available fonts is
> an invitation to frequent name clashes. Might I suggest that
> "ctan" be used for all names conforming to the CTAN's naming
> structure, and that "other" be used for the rest? In fact,
well, the distinction (which i never belived in) was betwene free and
notfree fonts, nowt to do with their comformance.
> reasons. First, there is nothing to keep multiple developers
> from naming packages identically. Second, I wonder if there
> might not be situations where, for instance, a font and a
> macro package had the same name.
hmmmm
> My own suggestion would be to place doc directories in the
> directories they document. This resolves the possibility of
> name clashes, at the cost of a somewhat scattered set of
i think the problem with that was that people wanted to isolate the
*real* `lib' needed to keep TeX alive (perhaps on some readonly
central disk) as opposed to the `luxuries' like documentation. i dont
buy that, myself, but then again i do like having all the docs in one
place. i dont like anything which might hold up the path searching
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 06 Jul 1994 18:46:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 6 Jul 1994 19:46:27 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407062346.TAA20539@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <9407061736.AA07041@cfcl.com> <"swan.cl.cam.:079660:940706204044"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 6 July 1994 at 21:40:37, Sebastian Rahtz wrote:
> > Using "public" as the name for all freely available fonts is
> > an invitation to frequent name clashes. Might I suggest that
> > "ctan" be used for all names conforming to the CTAN's naming
> > structure, and that "other" be used for the rest? In fact,
> well, the distinction (which i never belived in) was betwene free and
> notfree fonts, nowt to do with their comformance.
I'm sceptical about 'public' myself, but the real goal, as Sebastian
mentioned, is to let people keep their fonts segregated by vendor (for
commercial fonts). This will help with naming collisions and make
it easier for users unwilling or unfamiliar with KB's naming scheme
to find fonts.
> > reasons. First, there is nothing to keep multiple developers
> > from naming packages identically. Second, I wonder if there
> > might not be situations where, for instance, a font and a
> > macro package had the same name.
> hmmmm
Not much that can be done about it. Luckily, most authors want to have
unique, recognizable names.
> > My own suggestion would be to place doc directories in the
> > directories they document. This resolves the possibility of
> > name clashes, at the cost of a somewhat scattered set of
> i think the problem with that was that people wanted to isolate the
> *real* `lib' needed to keep TeX alive (perhaps on some readonly
> central disk) as opposed to the `luxuries' like documentation. i dont
> buy that, myself, but then again i do like having all the docs in one
> place. i dont like anything which might hold up the path searching
Path searching is the real problem. I think we want to make sure that
documentation is "out of the way" during execution. There have already
been some concerns raised about seperating things at all, but I think
it's necessary and, at present, not too confusing. Having the documentation
spread about would seem to be an invitation to confusion.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 07 Jul 1994 07:04:46 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407071203.AA15521@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Date: Thu, 07 Jul 94 07:40:32 -0400
From: bob@microprograms.com
I don't have a comprehensive list, but an increasing number of printers
are capable of dual resolutions---often thru the addition of an "image
enhancement kit."
In one such printer that I evaluated (the Samsung Finale), the effect
of the increased resolution (from 300 dpi to 1200 dpi) on letter
quality was marginal and at small type sizes was detrimental. However,
uses will want pk files for both resolutions in similiar cases.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Thu, 07 Jul 1994 14:52:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 07 Jul 1994 14:52:49 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Message-ID: <00981130.525E8DC4.4398@SHSU.edu>
Subject: An example of what we can fix!!
I know that I'm preaching to the choir here, but I was tracing how our new
news machine (yes, we finally have a real local news host) was running and
came across this post on comp.text.tex:
> Message-ID: <PLANK.94Jul5093626@entropy.phys.uva.nl>
> From: plank@phys.uva.nl (R.W.F. van der &)
> Date: 05 Jul 1994 07:36:26 GMT
> References: <1994Jul4.151120.28631@news.yale.edu>
>....
> There is a config.ps file somewhere (perhaps in
> /usr/TeX/lib/[...]/dvips/ ?) that probably has a line 'o !lpr' in it.
> Uncommenting this line should give the result you wanted.
Think about it -- with a reliable, widely-propagated TDS, the "perhaps"
above can become a quasi-authoritative response as to what to look for and
fix to get things working as desired! Again, I know you are all aware of
this, but is we can get the TDS design accepted, support and communications
can really be enhanced!
--George
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 08:04:23 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qMFVh-00007HC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 8 Jul 94 13:58 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Spec: First Draft
All looks pretty sound. One minor quibble in the fonts directory:
>\dir{src} & Font sources (\MF\ files, property lists, etc.)
This is the only case where the directory name isn't the same as the
file extension. Splitting this into \dir{mf}, \dir{pl}, \dir{vpl}
etc. seems better. Although I doubt many sites would keep the pl and
vpl files around...
Also having a directory for TrueType fonts would probably be a Good
Idea.
BTW, does anyone have a good idea what this structure is meant to say
about systems like the Mac where fonts have their own very specific
heirachy (eg fonts come in bundles and must live in the Fonts folder
in the System directory). I can imagine having a slight problem
trying to work out how to implement the TDS font structure under
Textures!
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 08:56:48 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407081346.AA15831@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Fri, 08 Jul 94 09:26:03 -0400
From: bob@microprograms.com
Alan asked the question:
> BTW, does anyone have a good idea what this structure is meant to say
> about systems like the Mac where fonts have their own very specific
> heirachy (eg fonts come in bundles and must live in the Fonts folder
> in the System directory). I can imagine having a slight problem
> trying to work out how to implement the TDS font structure under
> Textures!
I have discussed the TDS with Barry and he is not particularly
interested (at this point, at least) in implementing it for Textures
because of the pecularities of the Mac environment.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 18:34:45 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 8 Jul 1994 16:35:31 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407082335.QAA15522@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
I too would far rather drop the dpi300 level, but I think
there is so much to be said for keeping the same hierarchy
across even crippled systems like DOS that I am willing to
put up with it. I haven't introduced this irrelevance into
the UnixTeX stuff yet, but I will if I am sure that it
has become official.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 19:14:55 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 8 Jul 1994 17:15:08 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407090015.RAA18952@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: unixtex@u.washington.edu, mackay@cs.washington.edu
Subject: Re: format/package or package/format
I would completely trash any and all references (especially future
references) to a name such as dpi300/cmr10.300pk as it (a) adds confusion,
(b) is not portable, and (c) requires unnecessary additional maintenance to
software authors/maintainers. I completely understand that the X.300pk is
an existing more or less de facto standard which is a result of an
evolutionary process, especially focused on Unix operating systems, but it
Nope, derived directly from the original SAIL environment
and established in VMS and TOPS20 long before the first
Unix port was completed.
is a standard whose time has come and gone if we are anywhere near
interested in getting a close to generic installation based on a common
directory structure. I also completely understand that the use of the new
and explicitly stated standard will require some retrofitting for existing
software, but this is a move in which the larger TeX community (i.e., all
operating systems) gains in the short-run and in which existing
implementations using the older syntax gain in the long-run since we can
focus on a specific and known syntax which does not require any porting
efforts to anywhere else.
Yeah, I guess I see your point, but it is so depressing to make a mess
of a sensible distinction and proliferate hundreds of files all with
exactly the same name just because Bill Gates takes an irresponsible
view of software. Even in X-fonts, there are only two or three
ncen14.pcf files to get confused with one another. Some TeX installations
may have 30--50. X.300pk is not an archaic and obsolescent
quasi-standard, it is a sensible way of distinguishing one font from
another. It is not the trouble of retrofitting that causes pain, it
is the destruction of evidence and the introduction of a very real
posssibility of unsalvageable confusion. O.K. it is a "syntax" but it
is a "syntax" in the same sense that pidgin is. It makes a low level
of communication possible by excluding the possibility of rising above
that low level. It reminds me of the current pressure on myself and my
colleagues to lecture on Homer and Plato exclusively in words of one
syllable so that we won't be damned as elitist.
Flame over.
There is one concession, however, that I think we must insist on if
we ultimately give in to this nonsense.
The content and format of every *.pk file must be checked, and any
font that lacks the "mode_special" history at the end of the pk file
must be absolutely excluded from all archives. It is bad enough to
encourage confusion by requiring hundreds of cmr10.pk files (think of
a large networked site with 120, 300, 400, 600, 1000, 1200 and
1270---all real-world values---dpi printers all requiring service)
but it will be an impossible mess if there is no way of validating the
content of the files. Without the "mode_specials" there isn't any
reasonable way of ever knowing what you have.
I don't yet know what this does to ransom.300pk, (one of my all-time
favorite fonts), but I am sure the needed special can be forced in
somehow if it is not there
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 19:30:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 8 Jul 1994 17:31:03 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407090031.RAA20258@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Spec: First Draft
From: rdm@cfcl.com (Rich Morin)
Using "public" as the name for all freely available fonts is
an invitation to frequent name clashes. Might I suggest that
"ctan" be used for all names conforming to the CTAN's naming
structure, and that "other" be used for the rest? In fact,
some generalization of this might be in order for other areas.
I see some possibility for clashes in the doc area, for two
reasons. First, there is nothing to keep multiple developers
from naming packages identically. Second, I wonder if there
might not be situations where, for instance, a font and a
macro package had the same name.
These two observations may address a non-issue. Somebody maintains
archives. (Thanks again, George) and an archive maintainer is
not likely to be careless about accepting name clashes *at that level*.
Above that level, as I have just rather ill-temperedly pointed
out, we plan to go out of our way to produce files by the dozens
with exactly the same name.
If a package developer is so ignorant of the general contents of
the archive as to appropriate a name that is already on it, that
developer will just have to be told that the name is already
in use, and the package cannot be included until a new, unique name
is found.
My own suggestion would be to place doc directories in the
directories they document. This resolves the possibility of
name clashes, at the cost of a somewhat scattered set of
documentation. Also, if done properly, it causes doc files
to cover issues of relevance at the level in question.
For the most part, people don't look at packages level by level. It
is hard enough to get to read documentation at all. If the
documentation is squirrelled away at several different levels
it will rarely be found and even less often read.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Jul 1994 21:41:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 08 Jul 1994 21:41:48 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981232.9ED393A4.5846@SHSU.edu>
Subject: Re: format/package or package/format
On Fri, 8 Jul 1994 17:15:08 -0700, mackay@cs.washington.edu (Pierre MacKay)
posted:
> Yeah, I guess I see your point, but it is so depressing to make a mess of a
> sensible distinction and proliferate hundreds of files all with exactly the
> same name just because Bill Gates takes an irresponsible view of software.
Agreed by and large, but the fact of the matter is that his limiting
approach to the design of an operating system is undeniably on the world's
largest number of operating boxes out there. Not necessarily the largest
number of users, mind you, since just one good multi-user machine handles a
heck of a lot more users, but undeniably the largest number of boxes. And
if we want to have access to those boxes and not hold those users
individually responsible for one of little Billy's more massive design
flaws (let's not even get into memory handling), we either have to have an
accomodating default environment which is portable and extensible or we
have to settle for differences no matter what. The latter is far from
preferable. And the earlier report today that Mac developers may hold
their proprietary noses against what we are trying to achieve makes me
almost want to vomit. Someone needs to convince them that having
portability with an agreeable design is A Good Thing for the longer run
picture here for both their current users and (more important from a
commercial or proprietary perspective) their future users. If they have
problems with what we have so far, state them and let's try to accomodate
them also -- don't run off telling us that multiple approaches are the
superior solution unless it is demonstrably something impossible.
> Flame over.
Yeah; I guess mine too. 8-)
> There is one concession, however, that I think we must insist on if we
> ultimately give in to this nonsense.
>
> The content and format of every *.pk file must be checked, and any font
> that lacks the "mode_special" history at the end of the pk file must be
> absolutely excluded from all archives.
Pierre, thanks ever so much for this suggestion -- precisely why we need
people with your history, experience, and expertise working on this. I'll
be very honest -- you are waaaay over my head on this one, but this may be
the precise ticket to making the multiple and parallel filenames work in
this area. My (very uninformed) guess here is that the subsequent
requirement along these lines, which now makes this naming possibly
workable and verifiable might even be something which driver developers can
exploit. In other words, potentially a very nice, desirable, and useful
by-product of what we have, to date, viewed as a limitation. Maybe this
wasn't a limitation after all??
> North American academic institutions have been taken over by MBA
> bean-counters and genuine or wannabe industry CEOs. Just when American
> industry is beginning to doubt the wisdom of autocratic pyramidal
> dictatorship, most American Universities have adopted that style of
> management, which is nice for refugees from defense industry boardrooms,
> but rather sickening for the rest of us.
An oh-so-true sentiment -- makes me glad I hold an MS and not an MBA,
though! 8-)
Regards, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Jul 1994 02:45:52 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Date: Sat, 09 Jul 1994 08:46:27 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:171640:940709074636"@cl.cam.ac.uk>
i have nothing against Pierre's suggestion that the pk files be forced
to have a special in them declaring what the hell they are, but we
before we say so in print or cast iron, we had better be very sure
that its easy to do. What *does* currently write these specials? does
a `normal' gftopk? We need to persuade (at least)
Karl - web2c gftopk
Eberhard - emtex gftopk
Piet = ps2pk
? - gsftopk
to at least promise to support it properly, if they dont already, and
we need a trivial program to retrofit zillions of .pk files...
I guess only Pierre here really understands the technology. Can you
elaborate on this, Pierre? Whats involved?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Jul 1994 09:17:21 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 9 Jul 1994 07:18:01 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407091418.HAA28370@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
CC: unixtex@u.washington.edu
It is automatically included by any run of METAFONT
which uses Karl's modes.mf. The effect is to produce
a copy of the mode under which the font was generated
as a special at the end of the file. You can see it
(in Unix) by running strings on a pk file. The information
is designed to make it possible to regenerate the font exactly
Here is a fairly typical example from the first pk file I
could find in this directory tree.
identifier MINTMARKS
codingscheme ASCS Mint Marks
fontfacebyte
mintmarks10
mag:=1.44;
mode:=CanonCX;
pixels_per_inch:=300;
blacker:=0;
fillin:=0.2;
o_correction:=0.6;
all of that is exactly as recorded at the end of mintmarks10.432pk
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Jul 1994 10:20:00 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
Date: Sat, 09 Jul 1994 16:20:34 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:003590:940709152041"@cl.cam.ac.uk>
ok, i see. thats fine, so its independent of everything except MF. Now
all we need do is persuade Piet to put it in psp2k and Karl in
gsftopk.
Recall, by the way, that one of the starting points of this discussion is the
O'Reilly TDS reference CD. Since Norm and I will generate all the pks
from scratch for this, we *can* be sure that the pks will have the
special info in. good news for modern man
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 05:03:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 10 Jul 1994 06:03:45 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101003.AA10731@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: mode specials
What *does* currently write these specials?
modes.mf, and other such localmodes files.
does
a `normal' gftopk?
No, this isn't a gftopk thing. It's a Metafont thing.
It may be difficult to mandate this.
We need to persuade (at least)
Karl - web2c gftopk
Eberhard - emtex gftopk
Piet = ps2pk
? - gsftopk
? = Paul Vojta <vojta@math.berkeley.edu>.
to at least promise to support it properly, if they dont already, and
we need a trivial program to retrofit zillions of .pk files...
If they were generated with a decent localmodes file in the first place,
it shouldn't be necessary. I'd think it would be preferable to
regenerate them than to write a program to hack the values in directly.
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 05:03:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 10 Jul 1994 06:03:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101003.AA10724@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: mf vs. src
This is the only case where the directory name isn't the same as the
file extension. Splitting this into \dir{mf}, \dir{pl}, \dir{vpl}
etc. seems better. Although I doubt many sites would keep the pl and
vpl files around...
But `src' conveys the idea that these are the progenitor files.
For example, the sauter stuff has shell scripts, and I can imagine
Makefiles sometime also. Naming the directory `mf' would make that
confusing. Then there is dummy.pl.
I can't imagine anyone wanting to store pl and vpl files that are
generated, but if they did, I would make pl and vpl subdirectories. (But
I would still put dummy.pl in src!)
Also having a directory for TrueType fonts would probably be a Good
Idea.
So what's the extension? Or should it just be `truetype'?
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 05:03:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 10 Jul 1994 06:03:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101003.AA10718@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: dpi300/cmr10.pk vs. cmr10.300pk
Norm has the following commented-out paragraph:
%% Up for discussion...
%In order to retain some degree of compatability with existing systems
%that use long names, the \tds\ allows the use of long names within the
%\ext{dpi}\textit{res} directory (for example,
%$\ldots$\dir{/pk/}\textit{mode}\dir{/dpi300/cmr10.300pk}
%However,
%the two conventions should not be mixed on the same system!
I don't see so much as compatibility with ``existing systems'', I see it
as compatibility with Metafont, and simplicity of use: the simplest
thing to do with the file generated by mf/gftopk is move it
somewhere. Why penalize texadmins who do not need to support 8.3
filesystems?
The TDS can't allow or disallow anything, anyway; it's a question of
conformance. And the consequences of non-conformance have to be taken up
on a case-by-case basis.
In this case, the consequences of people installing cmr10.300pk in cx/,
instead of making cx/dpi300/cmr10.300pk are, in my opinion,
neglible.
Will it affect how easily *people* can find fonts, and how
easily they can decipher a font's meaning? No.
Will it affect how easily *programs* can find fonts? No -- programs
meant for 8.3 filesystem operation already read the dpi300/cmr10.pk
form; programs meant for reasonable (sorry :-) filesystems already read
the cmr10.300pk, thus they will have to add support for dpi300/cmr10.pk,
but I see no reason to *forbid* supporting cmr10.300pk
simultaneously. (Up to the smarts of the program maintainer, I'd say.)
Therefore, I suggest that the TDS *recommend* dpi300/cmr10.pk, as the
least-common-denominator-and-therefore-most-portable form, but using
cmr10.300pk instead be optionally supported. I.e., using cmr10.300pk
does not make you non-conformant.
For what it's worth, Kpathsea will support finding both.
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 05:22:31 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
Date: Sun, 10 Jul 1994 11:22:45 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:024460:940710102251"@cl.cam.ac.uk>
>
> I don't see so much as compatibility with ``existing systems'', I see it
> as compatibility with Metafont, and simplicity of use: the simplest
> thing to do with the file generated by mf/gftopk is move it
to what extent is the output <font>.<dpi>gf standard output from
Metafont? is that whats in the original? Knuth had long extensions way
back when?
> somewhere. Why penalize texadmins who do not need to support 8.3
> filesystems?
because the rest (most) of the TeX world is portable, why cavil here?
its a very great pity LaTeX2e messed it up with case sensitive
filenames.
its worth noting that some Unixes do have file name length
restrictions. Not that I think we are near them, but lets not get
carried away implying that the sky is the limit in Gods Own Operating System
> The TDS can't allow or disallow anything, anyway; it's a question of
> conformance. And the consequences of non-conformance have to be taken up
> on a case-by-case basis.
I think whats important is that if Unix people dont conform, they know
what they are not conforming to, if you see what I mean. Once we have
a fixed point, we can refer to it and document differences from it. So
longas the web2c people *can* use the TDS (whcih you have changed
web2c so that they can), they can non-conform happily so long as they
say what they are doing
> but I see no reason to *forbid* supporting cmr10.300pk
> simultaneously. (Up to the smarts of the program maintainer, I'd say.)
i am perfectly in agrement there
> Therefore, I suggest that the TDS *recommend* dpi300/cmr10.pk, as the
> least-common-denominator-and-therefore-most-portable form, but using
> cmr10.300pk instead be optionally supported. I.e., using cmr10.300pk
> does not make you non-conformant.
if it helps get the TDS finished and accepted, i'd be willing to
compromise on the wording of the document. I think George is the most
adamant against it - can you accept the change, George?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 12:16:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 10 Jul 1994 10:16:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101716.KAA08035@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: mode specials
If they were generated with a decent localmodes file in the first place,
it shouldn't be necessary. I'd think it would be preferable to
regenerate them than to write a program to hack the values in directly.
Agreed. I want to get in touch with Klaus Lagally about this,
because after Greek, I would like to get arabtex into TDS
"compliant" state, and Lagally is always particularly cooperative
in such matters.
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 12:22:43 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 10 Jul 1994 10:23:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101723.KAA08321@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 10 Jul 1994 06:03:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: dpi300/cmr10.pk vs. cmr10.300pk
Norm has the following commented-out paragraph:
%% Up for discussion...
%In order to retain some degree of compatability with existing systems
%that use long names, the \tds\ allows the use of long names within the
%\ext{dpi}\textit{res} directory (for example,
%$\ldots$\dir{/pk/}\textit{mode}\dir{/dpi300/cmr10.300pk}
%However,
%the two conventions should not be mixed on the same system!
Therefore, I suggest that the TDS *recommend* dpi300/cmr10.pk, as the
least-common-denominator-and-therefore-most-portable form, but using
cmr10.300pk instead be optionally supported. I.e., using cmr10.300pk
does not make you non-conformant.
For what it's worth, Kpathsea will support finding both.
I think that's what Norm and George intended. The question
is not how you choose to run your system, it is how a system-independent
package is to be made up. My font names mbvr-ascs10.*
don't conform with anything, but my own local needs, however
the kpathsea stuff handles them as if they were perfectly normal
As soon as you have the two-track support worked out, let me at it,
and I will try to live up to my threat to tie dvipage to kpathsea
Pierre
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 12:31:41 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 10 Jul 1994 10:32:20 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407101732.KAA08692@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: mf vs. src
From: "K. Berry" <kb@cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: mf vs. src
I can't imagine anyone wanting to store pl and vpl files that are
generated, but if they did, I would make pl and vpl subdirectories. (But
I would still put dummy.pl in src!)
Also having a directory for TrueType fonts would probably be a Good
Idea.
So what's the extension? Or should it just be `truetype'?
As it happens, I do store many vpl files (I won't go into why at the
moment) and occasional pl files. The way I have to use them, I
would find it a distinct inconvenience to split them up into
vpl/ and pl/ directories. I would simply have to link them
back into src/.
So, as one who is actually affected by the choice NOT to have
separate vpl/ and pl/ directories I vote enthusiastically
for NOT having them. (I think Karl and I hashed this out a
little over a year ago, and could think of no good reason
for separating sub-categories of source. I sometimes wonder
about even afm/ as a separate directory, but I would not
want to change now.)
Pierre
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 15:35:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 10 Jul 1994 15:35:12 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981391.BD6D1EC4.5811@SHSU.edu>
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
On Sun, 10 Jul 1994 11:22:45 +0100, Sebastian Rahtz
<Sebastian.Rahtz@cl.cam.ac.uk> posted in reply to Karl's earlier post:
> > Therefore, I suggest that the TDS *recommend* dpi300/cmr10.pk, as the
> > least-common-denominator-and-therefore-most-portable form, but using
> > cmr10.300pk instead be optionally supported. I.e., using cmr10.300pk
> > does not make you non-conformant.
>
> if it helps get the TDS finished and accepted, i'd be willing to compromise
> on the wording of the document. I think George is the most adamant against
> it - can you accept the change, George?
Based on your post and the exact reasoning that it is important to know
what you are non-conforming with, I have no problems with this. So long as
things, by default, support the more portable form, I have no problems with
extensions or enhancements which operating systems might provide. However,
I think it is critical that developers be expected to support the
short-form in all cases. Therefore, I would change the wording to
something more along the lines of
The TDS recommends the use of dpi300/cmr10.pk for font naming syntax
as it is the least-common-denominator-and-therefore-most-portable
form. Extensions to this recommendation, such as cmr10.300pk, may
optionally be employed on those systems which support this file name
syntax so long as (a) the portable form of the file name is also
supported and (b) no gain nor loss of functionality accrues from this
variation.
Would that be aceptable to everyone??
--George
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 15:44:38 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
Date: Sun, 10 Jul 1994 21:45:10 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:200390:940710204521"@cl.cam.ac.uk>
you can tell George hangs out with lawyers. his wording seems fine to
me
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sun, 10 Jul 1994 18:53:40 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 10 Jul 1994 16:54:24 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407102354.QAA27955@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
CC: unixtex@u.washington.edu
Hmmm this is all more prescriptive with regard to working
*systems* than I thought was intended. I thought we were
dealing with archives and distributions. Still, it is perfectly
true that Unix CAN work with this stuff, so I suppose
there is no great harm in it.
A certain amount of care is needed, however, to make sure that we
don't get to shutting off functionality. I mean the sort of thing
that distinguishes the way SAIL, VMS and TOPS20 specified
options to things like gftype (you can still see it in
the way dvitype works) and the way I changed Unix gftype
to use the command line switch instead. I ran that change
past Knuth, by the way, to get his "nil obstat".
Over the years, I have heard a lot of outrage about
"Unix cultural imperialism", but lets be just a bit on guard
against DOS cultural imperialism. I can easily see somone
saying that since some DOS implementation of gftype
is incapable of the command line
gftype -i <gf file> then nobody should be allowed to
distribute software with that capability. As Karl has
more than once pointed out, when a "standard" gets that far
out of line withwhat is actually happening, it becomes
too irrelevant to be followed.
Over what range of applications is the criterion
"so long as no gain nor loss of functionality accrues"
likely to take effect? I understand exactly what Knuth
means when he makes similar provisions about the use of
the name TeX, because it is involved with the use of
trip and trap. I just want to be sure that I understand the
limitations of the provision in this case. Even more I want
to know that the provision really is firmly limited in its
range of application.
.signature
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Jul 1994 02:30:03 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
Date: Mon, 11 Jul 1994 08:30:18 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:091680:940711073041"@cl.cam.ac.uk>
> Hmmm this is all more prescriptive with regard to working
> *systems* than I thought was intended. I thought we were
> dealing with archives and distributions. Still, it is perfectly
i thought the whole point of the TDS *was* to specify a working
system!
> Over the years, I have heard a lot of outrage about
> "Unix cultural imperialism", but lets be just a bit on guard
> against DOS cultural imperialism. I can easily see somone
i see what you are saying, but its fact of life that you/we are in a
considerable minority using GOOS, despite the fact that decent
software development comes from GOOS. ignore DOS, and we are just
painting ourselves into a corner. and its not DOS, really, its ISO9960.
isnt this a storm in a teacup? the only contention is the name of a PK
file, and we have a viable compromise whose only consequence is that
some Unix applications have to add some functionality which lots of us
prefer anyway - i *hate* those huge monolithic directories full of
***.***pk.
keep on guard, yes, but let this one past
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Jul 1994 08:42:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Jul 1994 08:41:56 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981421.2BD19144.5857@SHSU.edu>
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
On Sun, 10 Jul 1994 16:54:24 -0700, mackay@cs.washington.edu (Pierre
MacKay) posted:
> Over what range of applications is the criterion "so long as no gain nor
> loss of functionality accrues" likely to take effect?
I completely understand your concerns here and also completely recognize
that there may be things which are OS-specific in nature. Moreover, I am
not seeking DOS imperialism -- I am seeking a portability imperialism which
I believe can be useful for broad-range implementations. What my intent
was in that provisio could probably be better stated along the lines of "if
something works, it should be capable of handling the short-extension form
of the font filename, even if the `something' is OS-specific and impossible
to port elsewhere at the moment. If it also supports another filename
syntax, great; however, it should make every effort to utilize the
short-extension format."
Reasoning -- if it works with the short-form name, there would not be a
need for a site to have the long-form extension. As soon as something
popular somes along which relies on the long-form, we are back to square
one with the wide variety of possibilities, including having multiple sets
of fonts so that one thing will work and another will also work. Fonts are
something TeX and friends will virtually always have to deal with and if we
can get an agreeable standard in the area of fonts, then this critical part
of the system can get to some standard which developers can know and expect
to exist. If the short-form extension makes something now in existence
irreparably inoperable, I would have to re-think this, but I am unaware of
anything which *has* to have long-forms to operate.
My intent is not to impact switches or command lines; if I had my way, all
"-" switches would be used as "command line qualifiers" as in VMS with "/"
and allowable at any point in the command line (something I find harrowing
about other OSes is the fact that ordering of switches matter which I
simply don't have to deal with if a proper VMS interface is present, but
that's another story altogether) -- and I don't intend to even get into
that as it is definitely an OS issue at the utility level. My concern is
that the utilities look in the (basically) same place for the (absolutely)
same font files independent of OS.
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Jul 1994 09:14:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 11 Jul 1994 07:15:07 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407111415.HAA07948@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
O.K. Yours, and a later message from George make this specific,
and that's what is needed.
(Isn't it ISO 9660? ;-)
Maybe a 30-year experience of academic "legislation" has made
me paranoid, but I like to have these things clear before I sign
on. (Authoritarianism is always imagined as increasing hand in
hand with age, but I suspect that anarchism is commoner.)
I brought up the ISO9660 (I hope that really is right) question
way back, and I agree that it is a constraint that we should
try to accommodate. So, with the present understanding clear
that we are dealing with only the question of
A: length of filenames in the common, system-independent parts
of a working TeX support tree.
B: limits on levels of sub-directory in that tree.
I am prepared
to start work on the script that will rearrange the UnixTeX
offerings into TDS format.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Jul 1994 10:04:56 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
Date: Mon, 11 Jul 1994 16:04:44 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:010810:940711150521"@cl.cam.ac.uk>
> that we are dealing with only the question of
>
> A: length of filenames in the common, system-independent parts
> of a working TeX support tree.
>
> B: limits on levels of sub-directory in that tree.
>
> I am prepared
> to start work on the script that will rearrange the UnixTeX
> offerings into TDS format.
>
and actual names. no foo_bar.pk, and suchlike
s
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24058@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: subdir searching spec
As a result, the TWG decided that a comprehensive \tds\ required
some form of subdirectory searching. In other words, it must be possible
to specify that \TeX\ (and other \TeX\ utilities) search in both a
specified directory and recursively through all subdirectories of that
directory when looking for an input file.
Does the TDS want to recommend a method for specifying subdir searching,
so that each implementation does not do it differently to no good
reason? I doubt we should mandate anything, but I think it would be
useful for the document to describe the various ways in use now. (In
general, I think it would be very helpful if the TDS doesn't just lay
down the law, but explain common practices and reasoning for the decisions.)
kpathsea uses dir//.
Vojta's xdvi uses dir// to mean search only the directories under dir;
you get recursive searching with dir//*.
Tom's dvips uses the old web2c/kpathsea method -- a separate envvar
TEXFONTS_SUBDIR.
I don't know what emtex does.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24076@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: doc/ constituents
Aside from the <package> directories under doc/, I suggest we also have
directories a la CTAN -- help/ for meta-documentation (FAQ, unixtex.ftp,
etc.), and base/ (?) for general documentation (texbook.tex, webman.tex,
gentle-introduction, metafont-for-beginners, etc.).
CTAN uses doc, documentation, and info for this latter, but I don't
think any of those are suitable. texmf/doc/doc is too weird,
documentation is too long, and info/ commonly means the stuff generated
by makeinfo and texinfo-format-buffer.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:49 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24064@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: other tds dirs
\begin{description}
\item [tex] for the input files used by \TeX.
\item [fonts] for the font-related files.
\item [doc] for \textit{user} documentation.
\end{description}
As mentioned in Section~\ref{sec:otherdirs}, additional directories may
be used for other, standard, purposes (at the discretion of the installer
and system administrator): \dir{bin}, \dir{man}, \dir{ini}, $\ldots$
bin and man I agree are discretionary. I would also add dvips to the list.
But is there any problem with the TDS specifying ini/ as the place for
pool files and, if system-independent, .fmt/.base files?
Also, how about the TDS specifying bibtex/ at the top level (with
subdirectories bib/ and bst/)?
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:52 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24082@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: implementation-dependent files
However, commercial vendors and
system distributors are encouraged to keep system dependent files seperate
from the \tds.
Hmm. I don't think there are any system-dependent files in practice,
only implementation-dependent ones -- .fmt/.base. Also config files and
other extras (i.e., ls-R). I think these files must go somewhere in
texmf. Anything else would be vastly painful.
This mean format files should go somewhere other than texmf/ini. Hmm.
texmf/web2c, maybe, for those folks who want both (say) emtex and web2c
on their system, and yet want both to use the same common files? This
seems analogous with the other top-level directories. Shall the TDS
specify it?
This means the ini/ directory can become pool/ again, since those files
are implementation-independent, but there's no other files in that
bag. Sigh. It was nice while it lasted.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:50 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24070@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tex/ constituents
I'll append Norm's description of the tex/ directory. It brings up
some issues. Let me state what I think we agreed the macros/ directory
would consist of (mostly hashed out in the ctan discussion, actually):
plain/ -- standard files written by Knuth -- plain.tex, testfont.tex,
story.tex, null.tex, etc.
misc/ -- non-Knuth plain-compatible standalone files. (If they
work with latex, too, they still go here.) Perhaps eplain.tex,
btxmac.tex, arrow.tex, paths.sty, texinfo.tex, etc., all go
here, since they all work alone.
latex/ and latex209/ -- subdirectories base/ (for the distributed files)
and contrib/ (for, at least, single-file contributed files).
<package>/ for other packages -- amstex/{amstex.tex,amsppt.sty,...},
pstricks/, etc.
QUESTION #1: do multiple-file contributed latex packages go in
subdirectories of latex/contrib, or are they siblings of contrib/ and base/?
QUESTION #2: do multiple-file contributed plain (+whatever else)
packages go in their own directories (siblings of plain/), or do we
have subdirectories `base', `contrib', `texdraw', etc., of `plain', the
same with latex? Maybe that would make sense.
Then what goes in misc/, if single-file contributions go in
plain/contrib? Maybe files that work with multiple formats, e.g.,
paths.sty, btxmac.tex (works with amstex), texnames.sty, but *not*
eplain.tex, arrow.tex (only work with plain).
(Sorry for the eplain-centrism, but I don't know much about other
contributed files.)
Looked at another way, there's
0) basic plain files [plain.tex] (plain/base?);
1) single files [eplain.tex] that work only with plain (plain/contrib?);
2) multiple-file packages [texdraw] that only with plain (plain/<package>?)
3) single files that work with plain + other format(s) (misc/)?
4) basic latex files [latex.ltx] (latex/base?);
5) single files [cite.sty] that work only with latex (latex/contrib?);
6) multiple-file packages [psnfss] that work only with latex (latex/<package>>)
(Deep breath.) What do you think?
Here's Norm's posted description for reference:
\begin{center}
\dir{texmf/tex/}%
\textit{format}\dir{/}%
\textit{package}\dir{/}%
\textit{files}
\end{center}
\begin{description}
\item[format] is the name of the \TeX\ format file that uses these
files. \dir{plain}, \dir{latex209},
\dir{latex}, and \dir{musictex} are examples of \textit{formats}.
By providing a format directory, subdirectory searching can be limited
to only those directories that contain relevant files.
For some formats, it may be natural to search more than one format
directory. For example, both the \dir{latex} and \dir{plain}
directories may be searched when using \LaTeX. In cases like this,
packages should be installed at the end of the natural search order.
For example, a package usable under \LaTeX, \LaTeX209, and Plain \TeX\
should be stored in the \dir{plain} tree.
\item[package] is the name of the package
\dir{ams}, \dir{seminar}, and \dir{pstricks} are examples of
\textit{packages}.
Packages that consist of only a single file, or a small number of
independent files, may be installed in the \dir{misc} package
directory. This usage is discouraged unless the package really consists
of only a single file.
\end{description}
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 05:48:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 06:48:53 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121048.AA24088@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: package distribution
One last thing.
\section{Package Distribution}
We encourage package authors to build their distribution archives in
a structure that parallels the \tds. This will make package installation
much easier for the installer and much more regular across packages.
For example, a package for Martian language typesetting might include
the following files:
\begin{verbatim}
doc/martian/read.me
doc/martian/martdoc.tex
doc/martian/example.tex
tex/plain/martian/marthyph.tex
tex/latex/martian/martian.sty
tex/latex/martian/OT1mart.fd
fonts/martian/src/martian.mf
fonts/martian/src/mart10.mf
fonts/martian/tfm/mart10.tfm
\end{verbatim}
I'm not sure we should do this.
To quote from an earlier message of mine (thank God, er, George, that
this list is archived!):
I strongly believe the only reasonable way to do distributions is to
have them unpack into a *single* directory <package>-<version>, e.g.,
gcc-2.5.8. [...] But if something unpacked into many sibling directories
[as above], it would be extremely difficult and painful to track the
different versions.
What we've been doing up to now is providing installation scripts or
Makefiles or instructions to copy stuff from the distribution hierarchy
to the installation one.
(End quote.) What I would like to have us suggest to distributors
is the following:
1) A top-level directory that is the name of the package, hopefully
including a version number, where feasible. (Could make the name too long.)
2) subdirectories a la tds, but don't repeat the package name:
doc/readme
tex/plain/marthyph.tex
tex/latex/martian.sty
fonts/src/mart10.mf [except I don't like that name! fmzr10.mf would be
more like it; should I reserve mz for Martian :-)]
fonts/tfm/mart10.tfm
3) a top-level installation script or makefile that copies the files to
the right place.
This approach makes dealing with successive versions of packages much
more feasible, imho.
It *also* makes it possible to experiment with the <package>/<format>
(instead of <format>/<package>) style. Speaking of which, there is no
trace of that biggest of debates in the document. I think we should
mention that we considered it but did not adopt it because it was so
different from current practice.
Whew. (Finally finished reading the draft.) We've come a long way in
less than two months ...
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 08:18:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 94 14:18:26 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407121318.AA07061@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Karl:
Looked at another way, there's
0) basic plain files [plain.tex] (plain/base?);
1) single files [eplain.tex] that work only with plain (plain/contrib?);
2) multiple-file packages [texdraw] that only with plain (plain/<package>?)
3) single files that work with plain + other format(s) (misc/)?
4) basic latex files [latex.ltx] (latex/base?);
5) single files [cite.sty] that work only with latex (latex/contrib?);
6) multiple-file packages [psnfss] that work only with latex (latex/<package>)
(Deep breath.) What do you think?
Looks good, except that in the case of latex/packages (on ctan at
least, and there seems no reason for TDS not to follow).
In general contributed packages go in subdirs of latex/contrib, except
for single file submissions wich go in misc.
latex/contrib/seminar/*
latex/contrib/misc/cite.sty
or whatever.
The latex/packages directory is reserved for those packages supported
by the latex maintainers, in particular those for which bugs/comments
can be sent to latex-bugs@uni-mainz.de
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 10:17:50 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 12 Jul 1994 08:18:33 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121518.IAA25718@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: implementation-dependent files
I wonder whether it might be possible to rescue texmf/ini
Karl has worked out a moderately system-independent way of
writing and reading format and base files. It is at least
independent of byte ordering, and the last time I tried it out,
some 6 months ago, it worked. Is it reasonable to argue that
that style of format and base file belongs in texmf/ini, and that
format and base files which cannot be read outside a single
operating system are what is meant by "system dependent files."
This might create a certain subtle pressure to move toward
exportable format files, which can be very useful. In a publishing
environment, job-specific formats make a great deal of sense, and
I have sometimes been relieved to be able to ftp <book>.fmt from
one architecture to another.
I like texmf/ini, and have got very used to it on numerous machines.
I'd like to retain it if possible.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 10:17:53 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 12 Jul 1994 08:18:33 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121518.IAA25718@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: implementation-dependent files
I wonder whether it might be possible to rescue texmf/ini
Karl has worked out a moderately system-independent way of
writing and reading format and base files. It is at least
independent of byte ordering, and the last time I tried it out,
some 6 months ago, it worked. Is it reasonable to argue that
that style of format and base file belongs in texmf/ini, and that
format and base files which cannot be read outside a single
operating system are what is meant by "system dependent files."
This might create a certain subtle pressure to move toward
exportable format files, which can be very useful. In a publishing
environment, job-specific formats make a great deal of sense, and
I have sometimes been relieved to be able to ftp <book>.fmt from
one architecture to another.
I like texmf/ini, and have got very used to it on numerous machines.
I'd like to retain it if possible.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 11:19:20 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 12 Jul 1994 09:20:02 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407121620.JAA01152@june.cs.washington.edu>
To: TWG-TDS@shsu.edu
Subject: Karl's documentation directories.
CC: unixtex@u.washington.edu
help/ seems to me a very good idea. There is a world of difference
between the formal report in texinfo or LaTeX doc format and the
FAQ quick-fix documentation.
base/ won't do as a name. Not in the same world as METAFONT.
If it is decided that a separate directory is in order,
bookdoc/ would be reasonably informative, and meet the 8char constraint.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 14:37:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Jul 1994 14:37:28 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: info-tex@SHSU.edu, Sebastian.Rahtz@cl.cam.ac.uk, mackay@cs.washington.edu, ctan-ann@SHSU.edu, twg-tds@SHSU.edu
Message-ID: <0098151C.0142ECC4.5815@SHSU.edu>
Subject: CTAN: macros/latex/packages/psnfss/lw35nfss/
Pierre MacKay has created a much-called-for sub-set of the PSNFSS files for
LaTeX2e which has been installed in
/tex-archive/macros/latex/packages/psnfss/lw35nfss/lw35nfss.zip
just now installed at ftp.SHSU.edu. Attached is the supplied README file,
which requires nominal discussion -- the "TDS" he refers to (and this
archive conforms to) is aimed at a standard TeX Directory Structure which
is evolving from a TUG Technical Working Group on that topic which Norm
Walsh has chaired in with a yeomanlike effort. I feel confident that more
on this topic will follow in the somewhat near future, but the good news is
that this TDS is targeted at defining and creating a platform-independent
standard TeX directory hierarchy which can be implemented on every
operating system. Thanks to Pierre, this newly installed package
represents a first effort at conforming to that standard.
--George
===========================================================================
This file is texmf/doc/lw35nfss/README
P. A. MacKay 11 July, 1994. mackay@cs.washington.edu
This is a limited selection from the much larger set of
NFSS support files developed by Sebastian Rahtz. If you
want more than the barest functional access to the printer
resident fonts on your PostScript output device, you need to
go beyond this. The purpose of this set of files is to
make the use of "packages" such as |times.sty| available
in the simplest and most direct way.
The rest of this file shows the directory trees, all rooted
in $TEXMFROOT, contained in the lw35nfss package. These
trees have been arranged to conform with the TDS (TeX
Directory Standard), and should require no rearrangement
in a TDS conformant installation.
INSTALL # Discard this file after use. Do not leave it in
# the texmf/ directory
doc/
/lw35nfss/README
dvips/
config.pag config.pbk config.pcr config.phv config.pnc config.ppl
config.psy config.ptm config.pzc config.pzd pag.map pbk.map pcr.map
phv.map pnc.map ppl.map psy.map ptm.map pzc.map pzd.map
fonts/
adobe/
avantgar/
README
afm/
pagd0.afm pagdo0.afm pagk0.afm pagko0.afm
tfm/
pagd0.tfm pagd7t.tfm pagdc7t.tfm pagdcq.tfm
pagdo0.tfm pagdo7t.tfm pagdoq.tfm pagdq.tfm pagk0.tfm
pagk7t.tfm pagkc7t.tfm pagkcq.tfm pagko0.tfm pagko7t.tfm
pagkoq.tfm pagkq.tfm
vf/
pagd7t.vf pagdc7t.vf pagdcq.vf pagdo7t.vf
pagdoq.vf pagdq.vf pagk7t.vf pagkc7t.vf pagkcq.vf
pagko7t.vf pagkoq.vf pagkq.vf
bookman/
README
afm/
pbkd0.afm pbkdi0.afm pbkl0.afm pbkli0.afm
tfm/
pbkd0.tfm pbkd7t.tfm pbkdc7t.tfm pbkdcq.tfm
pbkdi0.tfm pbkdi7t.tfm pbkdiq.tfm pbkdo0.tfm pbkdo7t.tfm
pbkdoq.tfm pbkdq.tfm pbkl0.tfm pbkl7t.tfm pbklc7t.tfm
pbklcq.tfm pbkli0.tfm pbkli7t.tfm pbkliq.tfm pbklo0.tfm
pbklo7t.tfm pbkloq.tfm pbklq.tfm
vf/
pbkd7t.vf pbkdc7t.vf pbkdcq.vf pbkdi7t.vf
pbkdiq.vf pbkdo7t.vf pbkdoq.vf pbkdq.vf pbkl7t.vf
pbklc7t.vf pbklcq.vf pbkli7t.vf pbkliq.vf pbklo7t.vf
pbkloq.vf pbklq.vf
courier/
README
afm/
pcrb0.afm pcrbo0.afm pcrr0.afm pcrro0.afm
tfm/
pcrb0.tfm pcrb7t.tfm pcrbc7t.tfm pcrbcq.tfm
pcrbo0.tfm pcrbo7t.tfm pcrboq.tfm pcrbq.tfm pcrr0.tfm
pcrr7t.tfm pcrrc7t.tfm pcrrcq.tfm pcrro0.tfm pcrro7t.tfm
pcrroq.tfm pcrrq.tfm
vf/
pcrb7t.vf pcrbc7t.vf pcrbcq.vf pcrbo7t.vf
pcrboq.vf pcrbq.vf pcrr7t.vf pcrrc7t.vf pcrrcq.vf
pcrro7t.vf pcrroq.vf pcrrq.vf
helvetic/
README
afm/
phvb0.afm phvbo0.afm phvboc0.afm phvbon0.afm
phvbrc0.afm phvbrn0.afm phvbrp0.afm phvc0.afm phvco0.afm
phvcoc0.afm phvcrc0.afm phvr0.afm phvro0.afm phvroc0.afm
phvron0.afm phvrrc0.afm phvrrn0.afm phvrrq0.afm
phvrru0.afm
tfm/
phvb0.tfm phvb7t.tfm phvbc7t.tfm phvbcn7t.tfm
phvbcnq.tfm phvbcq.tfm phvbo0.tfm phvbo7t.tfm phvbon0.tfm
phvbon7t.tfm phvbonq.tfm phvboq.tfm phvbq.tfm phvbrn0.tfm
phvbrn7t.tfm phvbrnq.tfm phvr0.tfm phvr7t.tfm phvrc7t.tfm
phvrcn7t.tfm phvrcnq.tfm phvrcq.tfm phvro0.tfm phvro7t.tfm
phvron0.tfm phvron7t.tfm phvronq.tfm phvroq.tfm phvrq.tfm
phvrrn0.tfm phvrrn7t.tfm phvrrnq.tfm
vf/
phvb7t.vf phvbc7t.vf phvbcn7t.vf phvbcnq.vf
phvbcq.vf phvbo7t.vf phvbon7t.vf phvbonq.vf phvboq.vf
phvbq.vf phvbrn7t.vf phvbrnq.vf phvr7t.vf phvrc7t.vf
phvrcn7t.vf phvrcnq.vf phvrcq.vf phvro7t.vf phvron7t.vf
phvronq.vf phvroq.vf phvrq.vf phvrrn7t.vf phvrrnq.vf
newcentu/
README
afm/
pncb0.afm pncbi0.afm pncr0.afm pncri0.afm
tfm/
pncb0.tfm pncb7t.tfm pncbc7t.tfm pncbcq.tfm
pncbi0.tfm pncbi7t.tfm pncbiq.tfm pncbo0.tfm pncbo7t.tfm
pncboq.tfm pncbq.tfm pncr0.tfm pncr7t.tfm pncrc7t.tfm
pncrcq.tfm pncri0.tfm pncri7t.tfm pncriq.tfm pncro0.tfm
pncro7t.tfm pncroq.tfm pncrq.tfm
vf/
pncb7t.vf pncbc7t.vf pncbcq.vf pncbi7t.vf
pncbiq.vf pncbo7t.vf pncboq.vf pncbq.vf pncr7t.vf
pncrc7t.vf pncrcq.vf pncri7t.vf pncriq.vf pncro7t.vf
pncroq.vf pncrq.vf
palatino/
README
afm/
pplb0.afm pplbi0.afm pplr0.afm pplri0.afm
tfm/
pplb0.tfm pplb7t.tfm pplbc7t.tfm pplbcq.tfm
pplbi0.tfm pplbi7t.tfm pplbiq.tfm pplbo0.tfm pplbo7t.tfm
pplboq.tfm pplbq.tfm pplr0.tfm pplr7t.tfm pplrc7t.tfm
pplrcq.tfm pplri0.tfm pplri7t.tfm pplriq.tfm pplro0.tfm
pplro7t.tfm pplroq.tfm pplrq.tfm
vf/
pplb7t.vf pplbc7t.vf pplbcq.vf pplbi7t.vf
pplbiq.vf pplbo7t.vf pplboq.vf pplbq.vf pplr7t.vf
pplrc7t.vf pplrcq.vf pplri7t.vf pplriq.vf pplro7t.vf
pplroq.vf pplrq.vf
symbol/
README
afm/
psyr.afm
tfm/
psyr.tfm
times/
README
afm/
ptmb0.afm ptmbi0.afm ptmr0.afm ptmri0.afm
tfm/
ptmb0.tfm ptmb7t.tfm ptmbc7t.tfm ptmbcq.tfm
ptmbi0.tfm ptmbi7t.tfm ptmbiq.tfm ptmbo0.tfm ptmbo7t.tfm
ptmboq.tfm ptmbq.tfm ptmr0.tfm ptmr7t.tfm ptmrc7t.tfm
ptmrcq.tfm ptmri0.tfm ptmri7t.tfm ptmriq.tfm ptmro0.tfm
ptmro7t.tfm ptmroq.tfm ptmrq.tfm
vf/
ptmb7t.vf ptmbc7t.vf ptmbcq.vf ptmbi7t.vf
ptmbiq.vf ptmbo7t.vf ptmboq.vf ptmbq.vf ptmr7t.vf
ptmrc7t.vf ptmrcq.vf ptmri7t.vf ptmriq.vf ptmro7t.vf
ptmroq.vf ptmrq.vf
zapfchan/
README
afm/
pzcmi0.afm
tfm/
pzcmi0.tfm pzcmi7t.tfm pzcmiq.tfm
vf/
pzcmi7t.vf pzcmiq.vf
zapfding/
README
afm/
pzdr.afm
tfm/
pzdr.tfm
tex/
latex/
psnfss/
OT1pag.fd OT1pbk.fd OT1pcr.fd OT1phv.fd OT1pnc.fd OT1ppl.fd
OT1ptm.fd OT1pzc.fd README T1pag.fd T1pbk.fd T1pcr.fd T1phv.fd
T1pnc.fd T1ppl.fd T1ptm.fd T1pzc.fd Upsy.fd Upzd.fd avant.sty
avantgar.sty bookman.sty chancery.sty courier.sty helvet.sty
helvetic.sty mathptm.sty newcent.sty newcentu.sty palatino.sty
pifont.sty times.sty zapfchan.sty
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 16:48:28 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: doc/ constituents
Date: Tue, 12 Jul 1994 22:48:48 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:146900:940712214855"@cl.cam.ac.uk>
> Aside from the <package> directories under doc/, I suggest we also have
> directories a la CTAN -- help/ for meta-documentation (FAQ, unixtex.ftp,
> etc.), and base/ (?) for general documentation (texbook.tex, webman.tex,
> gentle-introduction, metafont-for-beginners, etc.).
yes to the concept, no to the name `base'
> CTAN uses doc, documentation, and info for this latter, but I don't
> think any of those are suitable. texmf/doc/doc is too weird,
> documentation is too long, and info/ commonly means the stuff generated
but i agree with that comment.
doc/general?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 16:50:22 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: subdir searching spec
Date: Tue, 12 Jul 1994 22:50:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:147330:940712215100"@cl.cam.ac.uk>
> Does the TDS want to recommend a method for specifying subdir searching,
> so that each implementation does not do it differently to no good
i think this a very valid point.
> general, I think it would be very helpful if the TDS doesn't just lay
> down the law, but explain common practices and reasoning for the decisions.)
yes, i agree
> kpathsea uses dir//.
> Vojta's xdvi uses dir// to mean search only the directories under dir;
> you get recursive searching with dir//*.
> Tom's dvips uses the old web2c/kpathsea method -- a separate envvar
> TEXFONTS_SUBDIR.
> I don't know what emtex does.
dir/* for one level and dir/** i think
maybe Karl (:-}) could draft a section for the TDS - bearing in mind
that the web2c scheme doesnt let you limit it to just one level down, i
think? should it?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 16:55:38 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
Date: Tue, 12 Jul 1994 22:56:01 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:148650:940712215611"@cl.cam.ac.uk>
> 1) A top-level directory that is the name of the package, hopefully
> including a version number, where feasible. (Could make the name too long.)
and illegal in ISO. you can have directory suffixes. this is a
non-starter, i am afraid.
otherwise, fine
> It *also* makes it possible to experiment with the <package>/<format>
> (instead of <format>/<package>) style. Speaking of which, there is no
> trace of that biggest of debates in the document. I think we should
> mention that we considered it but did not adopt it because it was so
> different from current practice.
hmm. maybe. do we want to confuse people? ok, it should go in
somewhere, but in a general philosophical bit
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 17:20:08 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: implementation-dependent files
Date: Tue, 12 Jul 1994 23:20:30 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:154200:940712222042"@cl.cam.ac.uk>
> Hmm. I don't think there are any system-dependent files in practice,
> only implementation-dependent ones -- .fmt/.base. Also config files and
> other extras (i.e., ls-R). I think these files must go somewhere in
> texmf. Anything else would be vastly painful.
>
> This mean format files should go somewhere other than texmf/ini. Hmm.
> texmf/web2c, maybe, for those folks who want both (say) emtex and web2c
> on their system, and yet want both to use the same common files? This
> seems analogous with the other top-level directories. Shall the TDS
> specify it?
>
> This means the ini/ directory can become pool/ again, since those files
> are implementation-independent, but there's no other files in that
> bag. Sigh. It was nice while it lasted.
oh yuck. lets pretend you never brought this up! I am with Pierre, i
liked that ini directory...
can we have texmf/ini/<product>?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 17:20:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: other tds dirs
Date: Tue, 12 Jul 1994 23:21:20 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:154530:940712222127"@cl.cam.ac.uk>
>
> Also, how about the TDS specifying bibtex/ at the top level (with
> subdirectories bib/ and bst/)?
yes please
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 17:37:07 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Tue, 12 Jul 1994 23:37:42 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:161550:940712223749"@cl.cam.ac.uk>
> plain/ -- standard files written by Knuth -- plain.tex, testfont.tex,
> story.tex, null.tex, etc.
> misc/ -- non-Knuth plain-compatible standalone files. (If they
> work with latex, too, they still go here.) Perhaps eplain.tex,
> btxmac.tex, arrow.tex, paths.sty, texinfo.tex, etc., all go
> here, since they all work alone.
eh? i thoought we were thinking
plain/base
plain/<package>
??
>
> QUESTION #1: do multiple-file contributed latex packages go in
> subdirectories of latex/contrib, or are they siblings of contrib/ and base/?
latex/misc, IMHO
> QUESTION #2: do multiple-file contributed plain (+whatever else)
> packages go in their own directories (siblings of plain/), or do we
> have subdirectories `base', `contrib', `texdraw', etc., of `plain', the
skip the contrib level, i say. not meaningful here
> Then what goes in misc/, if single-file contributions go in
> plain/contrib? Maybe files that work with multiple formats, e.g.,
> paths.sty, btxmac.tex (works with amstex), texnames.sty, but *not*
> eplain.tex, arrow.tex (only work with plain).
i thought we had
texmf/tex/generic
for such-like?
> Looked at another way, there's
> 0) basic plain files [plain.tex] (plain/base?);
> 1) single files [eplain.tex] that work only with plain (plain/contrib?);
plain/misc
> 2) multiple-file packages [texdraw] that only with plain (plain/<package>?)
> 3) single files that work with plain + other format(s) (misc/)?
generic/misc
etc
surely we must have generic, because everyone will need that on their
search path? where else do we put eg hyphenation patterns?
talking of which, we have to solve that question. where does Martian
hyphenation go (do they hyphenate on Mars?). I almost feel inclined to
make them a special case and always have a `package' generic/hyphen
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Jul 1994 17:40:32 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Tue, 12 Jul 1994 23:40:51 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:162420:940712224059"@cl.cam.ac.uk>
>
> The latex/packages directory is reserved for those packages supported
> by the latex maintainers, in particular those for which bugs/comments
> can be sent to latex-bugs@uni-mainz.de
>
i am not sure the distinction is meaningful in production. at CERN, I
have simply put texmf/tex/package, whether it be seminar or mfnss. i
think a whole contrib level on everyones disk is quite confusing
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 04:24:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Jul 94 10:24:41 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407130924.AA08112@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>
> >
> > The latex/packages directory is reserved for those packages supported
> > by the latex maintainers, in particular those for which bugs/comments
> > can be sent to latex-bugs@uni-mainz.de
> >
> i am not sure the distinction is meaningful in production. at CERN, I
> have simply put texmf/tex/package, whether it be seminar or mfnss. i
> think a whole contrib level on everyones disk is quite confusing
>
> sebastian
>
The main reason is support, already we get messages sent to the
latexbug address concerning packages we have never heard of.
Having the distinction, even in a running system between `core latex'
files which we support and other stuff for which you must look in the
documentation to find out where to report bugs is a valuable
distinction.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 04:43:19 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Wed, 13 Jul 1994 10:43:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:087490:940713094401"@cl.cam.ac.uk>
> The main reason is support, already we get messages sent to the
> latexbug address concerning packages we have never heard of.
>
> Having the distinction, even in a running system between `core latex'
> files which we support and other stuff for which you must look in the
> documentation to find out where to report bugs is a valuable
> distinction.
yes, but you want it twice, by distinguishing 'base' from `other' and
`packages' from `contrib' within 'other'. This doesnt occur elsewhere
and it would be a shame to impose it on the TDS. Surely the correct
answer is to put all the LaTeX2e packages as subdirs under base?
i see why we have to deal with it, but its a mess as proposed
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 05:06:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Jul 94 11:05:11 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407131005.AA08126@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
> yes, but you want it twice, by distinguishing 'base' from `other' and
> `packages' from `contrib' within 'other'. This doesnt occur elsewhere
> and it would be a shame to impose it on the TDS. Surely the correct
> answer is to put all the LaTeX2e packages as subdirs under base?
The latex core distribution is larger than most other `similar' parts
of the tds, eg plain is essentially one file so some diferences in
structure are inevitable.
Currently on ctan we have
latex
base
packages
graphics
babel
...
contrib
supported
...
other
...
That looks OK to me as a tds structure as well, but if you would
rather have ctan look like
latex
ISO-allowed-name-for-main-latex-distribution
base
graphics
babel
...
contrib
supported
...
other
...
That is OK with me (would need to check with others), on a tds
dropping the supported other distinction would be reasonable, ie
latex
ISO-allowed-name-for-main-latex-distribution
base
graphics
babel
...
contrib
...
...
except that means moving files around more after you pick the stuff up
from ctan.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 05:41:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Jul 1994 06:42:18 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407131042.AA24825@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc/ constituents
doc/bookdoc seems wrong because it's not just books.
doc/general seems ok.
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 13:43:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 14:41:49 -0400
Message-ID: <199407131841.OAA27713@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: subdir searching spec
References: <199407121048.AA24058@terminus.cs.umb.edu> <"swan.cl.cam.:147330:940712215100"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 22:50:53, Sebastian Rahtz wrote:
> > kpathsea uses dir//.
> > Vojta's xdvi uses dir// to mean search only the directories under dir;
> > you get recursive searching with dir//*.
> > Tom's dvips uses the old web2c/kpathsea method -- a separate envvar
> > TEXFONTS_SUBDIR.
> > I don't know what emtex does.
> dir/* for one level and dir/** i think
Nope, it's path! for one level and path!! for multiple levels:
c:\emtex\texiput!;d:\texmf\tex!!
[ More on all the other messages I haven't replied to soon ;-) ]
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 13:57:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 14:55:22 -0400
Message-ID: <199407131855.OAA27741@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <199407061402.KAA27692@jasper.ora.com> <m0qMFVh-00007HC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 8 July 1994 at 13:58, Alan Jeffrey wrote:
>
> Also having a directory for TrueType fonts would probably be a Good
> Idea.
I vote for 'ttf' since it has a similar flavor to afm, pfa, src, etc.,
and is a not-uncommon extension for TrueType fonts.
> BTW, does anyone have a good idea what this structure is meant to say
> about systems like the Mac where fonts have their own very specific
> heirachy
This ugly problem has been lurking under the surface for weeks. I've
been ignoring it 'cause it's so gawdawful. I think the practical answer
is that we can't do a damn thing about it.
Some OSs require that some files go in some very specific places. Fine.
So be it. I *still* think that the rest of the TDS will work fine. My
experience with, for example, the OzTeX distribution on the Mac leads
me to conclude that the TDS is perfectly workable on the Mac (modulo
nasty things like fonts have to go in the System:Fonts folder).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 13:58:30 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 14:56:36 -0400
Message-ID: <199407131856.OAA27745@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <m0qMFVh-00007HC@csrj.crn.cogs.susx.ac.uk> <9407081346.AA15831@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 8 July 1994 at 09:26:03, bob@microprograms.com wrote:
>
> I have discussed the TDS with Barry and he is not particularly
> interested (at this point, at least) in implementing it for Textures
> because of the pecularities of the Mac environment.
Sigh. I'm hoping that the Mac (and Windows) developers will look at
the spec when we make it public and let us know if it's practical. If
there are real problems, we'll have to address them. But if they just
don't plan to implemented it right away, what can we do?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:00:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 14:59:02 -0400
Message-ID: <199407131859.OAA27749@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: format/package or package/format
References: <0098102B.E760FB24.5815@SHSU.edu> <199407090015.RAA18952@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 8 July 1994 at 17:15:08, Pierre MacKay wrote:
> There is one concession, however, that I think we must insist on if
> we ultimately give in to this nonsense.
We have to give in. The ISO committee that defined ISO9660 did a Bad
Thing.
> The content and format of every *.pk file must be checked, and any
> font that lacks the "mode_special" history at the end of the pk file
> must be absolutely excluded from all archives.
Sounds fair to me.
> North American academic institutions have been taken over by MBA
> bean-counters and genuine or wannabe industry CEOs. Just when
> American industry is beginning to doubt the wisdom of autocratic
> pyramidal dictatorship, most American Universities have adopted
> that style of management, which is nice for refugees from defense
> industry boardrooms, but rather sickening for the rest of us.
Indeed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:13:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:04:36 -0400
Message-ID: <199407131904.PAA27847@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <9407061736.AA07041@cfcl.com> <199407090031.RAA20258@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 8 July 1994 at 17:31:03, Pierre MacKay wrote:
> If a package developer is so ignorant of the general contents of
> the archive as to appropriate a name that is already on it, that
> developer will just have to be told that the name is already
> in use, and the package cannot be included until a new, unique name
> is found.
Right on!
> For the most part, people don't look at packages level by level. It
> is hard enough to get to read documentation at all. If the
> documentation is squirrelled away at several different levels
> it will rarely be found and even less often read.
That's my feeling too. Putting it all in /doc will help keep things
together. Consistent use of package names elsewhere should make it
easy for users to find the documentation.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:21:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:19:33 -0400
Message-ID: <199407131919.PAA27928@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
References: <199407101003.AA10718@terminus.cs.umb.edu> <"swan.cl.cam.:024460:940710102251"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 10 July 1994 at 11:22:45, Sebastian Rahtz wrote:
> > somewhere. Why penalize texadmins who do not need to support 8.3
> > filesystems?
> because the rest (most) of the TeX world is portable, why cavil here?
> its a very great pity LaTeX2e messed it up with case sensitive
> filenames.
Indeed.
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:22:26 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qO9nh-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 13 Jul 94 20:17 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
>> Also having a directory for TrueType fonts would probably be a Good
>> Idea.
>I vote for 'ttf' since it has a similar flavor to afm, pfa, src, etc.,
>and is a not-uncommon extension for TrueType fonts.
Seconded. It's either that or `truetype' but I think ttf fits in
better with the other directories. And it makes it easier for people
to follow instructions cp *.pfa .../pfa *.ttf .../ttf etc.
>Some OSs require that some files go in some very specific places. Fine.
>So be it. I *still* think that the rest of the TDS will work fine. My
>experience with, for example, the OzTeX distribution on the Mac leads
>me to conclude that the TDS is perfectly workable on the Mac (modulo
>nasty things like fonts have to go in the System:Fonts folder).
... and the fonts being in different formats, and and and... Yes,
there's not much we can do about that one...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:22:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:20:26 -0400
Message-ID: <199407131920.PAA27968@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
References: <199407101003.AA10718@terminus.cs.umb.edu> <199407101723.KAA08321@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 10 July 1994 at 10:23:28, Pierre MacKay wrote:
> Therefore, I suggest that the TDS *recommend* dpi300/cmr10.pk, as the
> least-common-denominator-and-therefore-most-portable form, but using
> cmr10.300pk instead be optionally supported. I.e., using cmr10.300pk
> does not make you non-conformant.
>
> For what it's worth, Kpathsea will support finding both.
>
> I think that's what Norm and George intended. The question
> is not how you choose to run your system, it is how a system-independent
> package is to be made up. My font names mbvr-ascs10.*
> don't conform with anything, but my own local needs, however
> the kpathsea stuff handles them as if they were perfectly normal
>
> As soon as you have the two-track support worked out, let me at it,
> and I will try to live up to my threat to tie dvipage to kpathsea
Sorry, Pierre, you lost me. What's "two-track" support?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:26:30 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:24:32 -0400
Message-ID: <199407131924.PAA28019@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
References: <00981391.BD6D1EC4.5811@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 10 July 1994 at 15:35:12, George D. Greenwade wrote:
>
> The TDS recommends the use of dpi300/cmr10.pk for font naming syntax
> as it is the least-common-denominator-and-therefore-most-portable
> form. Extensions to this recommendation, such as cmr10.300pk, may
> optionally be employed on those systems which support this file name
> syntax so long as (a) the portable form of the file name is also
> supported and (b) no gain nor loss of functionality accrues from this
> variation.
>
> Would that be aceptable to everyone??
Done.
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:35:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:33:12 -0400
Message-ID: <199407131933.PAA28040@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: subdir searching spec
References: <199407121048.AA24058@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:48, K. Berry wrote:
> Does the TDS want to recommend a method for specifying subdir searching,
> so that each implementation does not do it differently to no good
> reason? I doubt we should mandate anything, but I think it would be
> useful for the document to describe the various ways in use now. (In
> general, I think it would be very helpful if the TDS doesn't just lay
> down the law, but explain common practices and reasoning for the decisions.)
I think it's a great idea. Can I second the request that you draft that
section? Please ;-) ?
> kpathsea uses dir//.
> Vojta's xdvi uses dir// to mean search only the directories under dir;
> you get recursive searching with dir//*.
> Tom's dvips uses the old web2c/kpathsea method -- a separate envvar
> TEXFONTS_SUBDIR.
> I don't know what emtex does.
Emtex uses !
So we have
dir// (and dir//dir which is unique to kpathsea, I guess)
dir//, dir//*
another env var
dir!, dir!!
Karl, what do you have in mind for searching only one level? Is that
not a feature you consider worth supporting? Personally, I don't see
any great need (given that we've already discussed the nearly infinite
advantages of an ls-R file, anyway), but I can see why EM chose another
character to support it...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:43:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:41:56 -0400
Message-ID: <199407131941.PAA28054@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: doc/ constituents
References: <199407121048.AA24076@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:51, K. Berry wrote:
> Aside from the <package> directories under doc/, I suggest we also have
> directories a la CTAN -- help/ for meta-documentation (FAQ, unixtex.ftp,
> etc.), and base/ (?) for general documentation (texbook.tex, webman.tex,
> gentle-introduction, metafont-for-beginners, etc.).
(Since I'm coming in late) Are we settled on
doc/general
and
doc/help
Those seem fine to me...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 14:53:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 15:47:30 -0400
Message-ID: <199407131947.PAA28080@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: other tds dirs
References: <199407121048.AA24064@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:49, K. Berry wrote:
> \begin{description}
> \item [tex] for the input files used by \TeX.
> \item [fonts] for the font-related files.
> \item [doc] for \textit{user} documentation.
> \end{description}
>
> As mentioned in Section~\ref{sec:otherdirs}, additional directories may
> be used for other, standard, purposes (at the discretion of the installer
> and system administrator): \dir{bin}, \dir{man}, \dir{ini}, $\ldots$
>
> bin and man I agree are discretionary. I would also add dvips to the list.
Discretionary, or part of the standard? I assume you mean discretionary
since not everyone uses a PS printer ;-)
Should we try to list all the discrtionary names? And make a one liner
for what should go in there?
> Also, how about the TDS specifying bibtex/ at the top level (with
> subdirectories bib/ and bst/)?
You got it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 15:06:07 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 16:04:21 -0400
Message-ID: <199407132004.QAA28139@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation-dependent files
References: <199407121048.AA24082@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:52, K. Berry wrote:
> However, commercial vendors and
> system distributors are encouraged to keep system dependent
> files seperate from the \tds.
>
> Hmm. I don't think there are any system-dependent files in practice,
> only implementation-dependent ones -- .fmt/.base.
Ahh, bad wording on my part. I meant *implementation* dependent.
(I was thinking of Unix and PC *systems* ... )
> Also config files and
> other extras (i.e., ls-R). I think these files must go somewhere in
> texmf. Anything else would be vastly painful.
True.
> This mean format files should go somewhere other than texmf/ini. Hmm.
> texmf/web2c, maybe, for those folks who want both (say) emtex and web2c
> on their system, and yet want both to use the same common files?
They should go in c:\emtex\formats and c:\web2c\ini, if you ask me. Why
are you putting these things under /texmf? I think the discretionary
directories are really only appropriate on systems where only a *single*
implementation is in use.
Sebastian suggested /texmf/ini/<system>. I guess that wouldn't be too
bad? ...
> This
> seems analogous with the other top-level directories. Shall the TDS
> specify it?
I think I'm getting tired. Analogous to which directories?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 15:07:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 13 Jul 1994 13:08:14 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407132008.NAA05427@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: dpi300/cmr10.pk vs. cmr10.300pk
Karl intends to make sure that both dpi300/cmr10.pk and <whatever>/cmr10.300pk
will both work. That is the only to be fair to sites that
have depended on cmr10.300pk for years---hence two-track support.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 15:10:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 13 Jul 1994 16:09:00 -0400
Message-ID: <199407132009.QAA28153@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
References: <199407121048.AA24088@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:53, K. Berry wrote:
> One last thing.
>
> \section{Package Distribution}
>
> We encourage package authors to build their distribution archives in
> a structure that parallels the \tds. This will make package installation
> much easier for the installer and much more regular across packages.
> For example, a package for Martian language typesetting might include
> the following files:
>
> \begin{verbatim}
> doc/martian/read.me
> doc/martian/martdoc.tex
> doc/martian/example.tex
> tex/plain/martian/marthyph.tex
> tex/latex/martian/martian.sty
> tex/latex/martian/OT1mart.fd
> fonts/martian/src/martian.mf
> fonts/martian/src/mart10.mf
> fonts/martian/tfm/mart10.tfm
> \end{verbatim}
>
> I'm not sure we should do this.
AUUGRHH!
I *meant* to say
\begin{verbatim}
martian-0.1/doc/martian/read.me
martian-0.1/doc/martian/martdoc.tex
martian-0.1/doc/martian/example.tex
martian-0.1/tex/plain/martian/marthyph.tex
martian-0.1/tex/latex/martian/martian.sty
martian-0.1/tex/latex/martian/OT1mart.fd
martian-0.1/fonts/martian/src/martian.mf
martian-0.1/fonts/martian/src/mart10.mf
martian-0.1/fonts/martian/tfm/mart10.tfm
\end{verbatim}
Is that better? I *entirely* and *emphatically* agree that packages should
unpack into a single directory. Making the internal structure mirror the
TDS should make installation easier.
[ Sebastian, your comment that the directory name must be ISO9660 isn't
necessarily true. The *package* name must be (i.e. martian) but there's
no reason the distribution archive can't include a package+version name. ]
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Jul 1994 15:22:57 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 13 Jul 1994 13:23:31 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407132023.NAA06841@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
What I have seen so far still suggests that texmf/ini is a lost cause.
I previously suggested that Karl's byte-order-independent *.fmt
and *.base files might save it. I have in the past been able to
pass byte-order-independent *.fmt files between Big-Endian and
Little-Endian systems with success, and that sounds pretty
system independent. I have no objection to
texmf/ini/<system> where it is needed, but what system would
you specify for a byte-order-independent format file?
Pierre
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:14:12 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
Date: Thu, 14 Jul 1994 14:14:19 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:110050:940714131428"@cl.cam.ac.uk>
texmf/ini/emtex
texmf/ini/pctex
texmf/ini/web2c
texmf/ini/general
texmf/ini/alpha % if you wanted the incompatible format file
i dont see why this wouldnt work. if we have that level, people can
use it as they like.
Karl's runtime config files for web2c are going to make all this a
real joy
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:16:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:14:50 -0400
Message-ID: <199407141314.JAA29476@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407121048.AA24070@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 06:48:50, K. Berry wrote:
> Looked at another way, there's
> 0) basic plain files [plain.tex] (plain/base?);
plain/base
> 1) single files [eplain.tex] that work only with plain (plain/contrib?);
plain/eplain (eplain comes with several files, no?)
plain/misc (for things that are really one file)
> 2) multiple-file packages [texdraw] that only with plain (plain/<package>?)
plain/texdraw
> 3) single files that work with plain + other format(s) (misc/)?
plain/misc (if they work with plain and plain-derived formats)
generic (i.e. texmf/tex/generic, if they work with *any* format
[ I'm thinking of hyphenation patterns here ])
> 4) basic latex files [latex.ltx] (latex/base?);
latex/base
> 5) single files [cite.sty] that work only with latex (latex/contrib?);
latex/misc
> 6) multiple-file packages [psnfss] that work only with latex
latex/psnfss
Agreed?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:24:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:22:47 -0400
Message-ID: <199407141322.JAA29522@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407121048.AA24070@terminus.cs.umb.edu> <9407121318.AA07061@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 14:18:26, David Carlisle wrote:
>
> Looks good, except that in the case of latex/packages (on ctan at
> least, and there seems no reason for TDS not to follow).
>
> In general contributed packages go in subdirs of latex/contrib, except
> for single file submissions wich go in misc.
>
> latex/contrib/seminar/*
> latex/contrib/misc/cite.sty
>
> or whatever.
>
> The latex/packages directory is reserved for those packages supported
> by the latex maintainers, in particular those for which bugs/comments
> can be sent to latex-bugs@uni-mainz.de
The TDS doesn't (yet) have a "packages" directory. What it has is
latex/<package> and I think this is what Karl meant. To mirror CTAN,
we'd need something like this:
texmf/tex/latex/base/<files>
texmf/tex/latex/contrib/seminar/<files>
texmf/tex/latex/contrib/misc/cite.sty
texmf/tex/latex/packages/babel/<files>
but my understanding of the TDS proposal has always been this:
texmf/tex/latex/base/<files>
texmf/tex/latex/seminar/<files>
texmf/tex/latex/misc/cite.sty
texmf/tex/latex/babel/<files>
I understand that the additional level has considerable significance
and meaning *in an archive*, but I don't think it adds much in the TDS.
Except, possibly, confusion ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:30:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 94 14:27:18 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407141327.AA08884@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Norman,
> > 5) single files [cite.sty] that work only with latex (latex/contrib?);
> latex/misc
> > 6) multiple-file packages [psnfss] that work only with latex
> latex/psnfss
> Agreed?
As I said before this layout makes the latex directory very broad
There are a *lot* of multiple-file packages for latex.
The distinction between contributed and centrally supported packages
is worth maintaining in a running system, otherwise it is unreasonable
to expect the user (ie the person generating bug reports) to know that
stuff is contributed. We have made it easy to contact us without
having to read loads of docs, just type latex latexbug, and follow the
instructions, but this will only be viable if people can easily tell
which packages are supported in this way.
latex/contrib/misc/cite.sty
latex/contrib/seminar
please?
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:43:56 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:42:15 -0400
Message-ID: <199407141342.JAA29627@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407141314.JAA29476@jasper.ora.com> <9407141327.AA08884@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 14:27:18, David Carlisle wrote:
> > > 5) single files [cite.sty] that work only with latex (latex/contrib?);
>
> > latex/misc
>
> > > 6) multiple-file packages [psnfss] that work only with latex
>
> > latex/psnfss
>
> > Agreed?
>
> As I said before this layout makes the latex directory very broad
> There are a *lot* of multiple-file packages for latex.
> The distinction between contributed and centrally supported packages
> is worth maintaining in a running system, otherwise it is unreasonable
> to expect the user (ie the person generating bug reports) to know that
> stuff is contributed. We have made it easy to contact us without
> having to read loads of docs, just type latex latexbug, and follow the
> instructions, but this will only be viable if people can easily tell
> which packages are supported in this way.
>
> latex/contrib/misc/cite.sty
> latex/contrib/seminar
>
> please?
I'm certainly willing (I'll do anything I can to make things most
useful for the most people) but I'm a little bit reluctant. What does
everyone else think?
Personally, I think it adds confusion (I'm looking for seminar.sty is that
in latex/contrib/seminar or latex/packages/seminar? Gosh darn it, why did
the TDS make these things so hard to find!?) and doesn't help the
LaTeX maintainers at all:
Joe User uses foobar.cls (\documentclass{foobar}...) and it doensn't handle
widgets correctly. He fires up "latex latexbug" and reports the problem.
Joe doesn't know if it's packages/misc/foobar.cls or contrib/misc/foobar.cls
that he's using, and he probably doesn't care.
Am I mistaken? Is there a way that the added level *really helps*?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:46:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:45:09 -0400
Message-ID: <199407141345.JAA29638@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation-dependent files
References: <199407121048.AA24082@terminus.cs.umb.edu> <199407121518.IAA25718@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 July 1994 at 08:18:33, Pierre MacKay wrote:
>
> I like texmf/ini, and have got very used to it on numerous machines.
> I'd like to retain it if possible.
>
Me too. Is everyone happy with Sebastian's suggestion:
texmf/ini/emtex
texmf/ini/web2c
texmf/ini/oztex
etc.?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:49:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:47:46 -0400
Message-ID: <199407141347.JAA29690@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407121048.AA24070@terminus.cs.umb.edu> <"swan.cl.cam.:161550:940712223749"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
>
> talking of which, we have to solve that question. where does Martian
> hyphenation go (do they hyphenate on Mars?). I almost feel inclined to
> make them a special case and always have a `package' generic/hyphen
>
Aren't hyphenation patterns read by TeX before/during iniTeX so they
have a fixed format? Can't they *all* go in /texmf/tex/generic?
Why add texmf/tex/generic/hyphen? Just for clarity...are there
really going to be many *other* things in /generic?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:53:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:51:42 -0400
Message-ID: <199407141351.JAA29695@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <9407130924.AA08112@r8d.cs.man.ac.uk> <"swan.cl.cam.:087490:940713094401"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 13 July 1994 at 10:43:53, Sebastian Rahtz wrote:
>
> yes, but you want it twice, by distinguishing 'base' from `other' and
> `packages' from `contrib' within 'other'. This doesnt occur elsewhere
> and it would be a shame to impose it on the TDS. Surely the correct
> answer is to put all the LaTeX2e packages as subdirs under base?
Now there's an idea...how *does* everyone feel about
texmf/tex/latex/base/<files>
texmf/tex/latex/base/psnfss/<files>
texmf/tex/latex/base/babel/<files>
On second thought, I'm not sure that's any better than /contrib and
/packages...
> i see why we have to deal with it, but its a mess as proposed
I would dearly love to find a solution to help with the problem, but
we've got all our TeX users running subdir searching over the TDS.
I don't think any of them *know* where the packages even come from
so ... how does separating them *really* help?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 08:57:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:55:45 -0400
Message-ID: <199407141355.JAA29731@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
References: <199407132009.QAA28153@jasper.ora.com> <199407132023.NAA06841@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 July 1994 at 13:23:31, Pierre MacKay wrote:
> I previously suggested that Karl's byte-order-independent *.fmt
> and *.base files might save it. I have in the past been able to
> pass byte-order-independent *.fmt files between Big-Endian and
> Little-Endian systems with success, and that sounds pretty
> system independent. I have no objection to
> texmf/ini/<system> where it is needed, but what system would
> you specify for a byte-order-independent format file?
/<implementation>, I guess. Is it really the case that two *different* TeX
implementations could share the same format file? Seems unlikely to me...
--norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 09:13:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 1994 09:13:43 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981681.1BF989A4.5963@SHSU.edu>
Subject: Re: tex/ constituents
> > As I said before this layout makes the latex directory very broad
> > There are a *lot* of multiple-file packages for latex.
> > The distinction between contributed and centrally supported packages
> > is worth maintaining in a running system, otherwise it is unreasonable
> > to expect the user (ie the person generating bug reports) to know that
> > stuff is contributed. We have made it easy to contact us without
> > having to read loads of docs, just type latex latexbug, and follow the
> > instructions, but this will only be viable if people can easily tell
> > which packages are supported in this way.
> >
> > latex/contrib/misc/cite.sty
> > latex/contrib/seminar
> >
> > please?
>
> I'm certainly willing (I'll do anything I can to make things most useful
> for the most people) but I'm a little bit reluctant. What does everyone
> else think?
>
> Personally, I think it adds confusion (I'm looking for seminar.sty is that
> in latex/contrib/seminar or latex/packages/seminar? Gosh darn it, why did
> the TDS make these things so hard to find!?) and doesn't help the LaTeX
> maintainers at all:
>
> Joe User uses foobar.cls (\documentclass{foobar}...) and it doensn't handle
> widgets correctly. He fires up "latex latexbug" and reports the problem.
> Joe doesn't know if it's packages/misc/foobar.cls or
> contrib/misc/foobar.cls that he's using, and he probably doesn't care.
>
> Am I mistaken? Is there a way that the added level *really helps*?
In a perfect world, where users can and do distinguish between officially
distributed files and contributed files (and, further, between the concepts
of "supported", "packages" and "other" for these contributed files, as we
archive them on the CTAN), the extra layer makes sense. Hence, from an
archival perspective, the extra layer(s) make extraordinarily significant
sense.
In the real world, were users know to type "latex <file>" and the thing
works for whatever mysterious reason (often not even recognizing that a
call to TeX has actually been issued), I see no intrinsic advantage to the
extra layer[s] (especially if the number of directory levels should ever
come into play as a constraint). The LaTeX team has created, quite
unintentionally, a monster with latexbug. Forget about \documentclass as
those will nearly always be distributed or well known to the LaTeX team.
The real scare factor (which I shared with a few people previosuly and was
kindly told not to concern myself about) is the \usepackage command (or
\input for that matter). How and why does the LaTeX team intend to
efficiently inform users, a priori, that the reason something appears to
break while running LaTeX is attributable to a contributed file and not a
distributed file? Look at past traffic on the TeX-related lists/groups and
it amazes me that people cannot even recognize that the underlying TeX
engine is pretty good about giving information about what command,
sequence, syntax, or structure caused a failure. Regardless of where a
file gets placed for whatever reason or whatever that file's source, if it
is an \input to LaTeX, the LaTeX team is liable to hear about it whether
they like it or not since it "is LaTeX".
On the other hand, I have to admit that LaTeX is a significant package.
Hence, to keep everyone happy from a structural perspective, why not use
something such as:
latex/distrib/<officially distributed files> (or latex/base or whatever --
let the LaTeX team call it what they choose).
latex/<package>/<files or hierarchy in multiple file packages>
latex/misc/<single file distributions>
With this syntax, the contrib is removed and the LaTeX team can point to a
single location where "their" files reside. The benefit from a real world
perspective is that it makes maintenance of a multi-file package, whether
official or contributed (such as David's "tools" or Sebastian's "psnfss" or
the "babel" or the "amslatex" package on the CTAN) an awful lot easier to
follow. This way, the LaTeX team gets what it wants and we more or less
avoid the extra directory level.
Waddayathink?
--George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 09:40:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 10:38:03 -0400
Message-ID: <199407141438.KAA29848@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <00981681.1BF989A4.5963@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 09:13:43, George D. Greenwade wrote:
> On the other hand, I have to admit that LaTeX is a significant package.
> Hence, to keep everyone happy from a structural perspective, why not use
> something such as:
> latex/distrib/<officially distributed files> (or latex/base or whatever --
> let the LaTeX team call it what they choose).
> latex/<package>/<files or hierarchy in multiple file packages>
> latex/misc/<single file distributions>
> With this syntax, the contrib is removed and the LaTeX team can point to a
> single location where "their" files reside. The benefit from a real world
I think this is essentially what Sebastian suggested (B, below). The
three possible formats (so far ;-) for this extra level of distinction
are:
0) (my original proposal, for reference)
/texmf/tex/latex/base/*
/texmf/tex/latex/<package>/*
A) (CTAN)
/texmf/tex/latex/base/*
/texmf/tex/latex/contrib/<package>/*
/texmf/tex/latex/packages/<package>/*
B) (SR)
/texmf/tex/latex/base/*
/texmf/tex/latex/base/<package>/*
/texmf/tex/latex/<package>/*
C) (DC)
/texmf/tex/latex/SOMENAME/base/*
/texmf/tex/latex/SOMENAME/<package>/*
/texmf/tex/latex/contrib/<package>/*
where SOMENAME indicates that what follows is supported by 'latexbug'
I've flip-flopped and conceed that 0) is insufficient. That said, I
think I prefer option C, especially if we can come up with a good
SOMENAME.
What say you?
--norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:00:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 1994 10:00:12 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00981687.9A731AC4.5759@SHSU.edu>
Subject: Re: tex/ constituents
> B) (SR)
>
> /texmf/tex/latex/base/*
> /texmf/tex/latex/base/<package>/*
> /texmf/tex/latex/<package>/*
>
> C) (DC)
>
> /texmf/tex/latex/SOMENAME/base/*
> /texmf/tex/latex/SOMENAME/<package>/*
> /texmf/tex/latex/contrib/<package>/*
>
> where SOMENAME indicates that what follows is supported by 'latexbug'
>
> I've flip-flopped and conceed that 0) is insufficient. That said, I think
> I prefer option C, especially if we can come up with a good SOMENAME.
There is no such thing (unless I'm sadly mistaken in my archiving duties,
which is a possibility) as a "package" under the "base" LaTeX files. The
base LaTeX files are in macros/latex/base/ on the CTAN; the
macros/latex/packages/ are packages which meet pre-specified archival
criteria, but are contributed all the same. The use of SOMENAME is
pointless, IMO, since the "base" files are the "official" files; anything
not in /texmf/tex/latex/base/ is not subject to latexbug and is, by
definition, a "contributed" package/file as far as I am aware, so the
distinction is already inherent in the design without the extra directory
layer. Hence, option B feasibly becomes:
/texmf/tex/latex/base/*
/texmf/tex/latex/<package>/*
/texmf/tex/latex/misc/<individual files>
with the reservation of "misc" as a non-package name (which probably ought
to be stipulated).
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:09:54 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOSL6-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 16:04 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>The
>base LaTeX files are in macros/latex/base/ on the CTAN; the
>macros/latex/packages/ are packages which meet pre-specified archival
>criteria, but are contributed all the same.
Not quite. The contents of macros/latex/packages are packages
produced by the LaTeX team (and partners in crime such as Sebastian).
Anything in macros/latex/packages is subject to latexbug. Everything
else is in macros/latex/contrib, and is not under latexbug. (Not that
A. N. User understands this, so we still get bug reports on non-L3
material, but what can you do...)
Assuming that bug reporters read the instructions, the distinction
between latex/SOMETHING/<package> and latex/contrib/<package> is
useful, since the former are `what you can report with latexbug'. But
that `assuming' is quite large...
Perhaps:
latex/
base/
latex/<files> (the current latex/base)
graphics/<files>
color/<files>
...
contrib/
...
but latex/base/latex does look a bit odd...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:18:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 11:16:47 -0400
Message-ID: <199407141516.LAA29956@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <00981687.9A731AC4.5759@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 10:00:12, George D. Greenwade wrote:
> >
> > C) (DC)
> >
> > /texmf/tex/latex/SOMENAME/base/*
> > /texmf/tex/latex/SOMENAME/<package>/*
> > /texmf/tex/latex/contrib/<package>/*
> >
> > where SOMENAME indicates that what follows is supported by 'latexbug'
> >
> > I've flip-flopped and conceed that 0) is insufficient. That said, I think
> > I prefer option C, especially if we can come up with a good SOMENAME.
>
> There is no such thing (unless I'm sadly mistaken in my archiving duties,
> which is a possibility) as a "package" under the "base" LaTeX files. The
> base LaTeX files are in macros/latex/base/ on the CTAN; the
> macros/latex/packages/ are packages which meet pre-specified archival
> criteria, but are contributed all the same. The use of SOMENAME is
> pointless, IMO, since the "base" files are the "official" files; anything
> not in /texmf/tex/latex/base/ is not subject to latexbug and is, by
> definition, a "contributed" package/file as far as I am aware, so the
> distinction is already inherent in the design without the extra directory
> layer.
Wait! I thought that the distinction was *precisely* that (on CTAN)
/macros/latex/base/* and
macros/latex/packages/<package>/* were supported by latexbug and
macros/latex/contrib/<packages>/* were not
That's why we needed two layers.
> Hence, option B feasibly becomes:
> /texmf/tex/latex/base/*
> /texmf/tex/latex/<package>/*
> /texmf/tex/latex/misc/<individual files>
> with the reservation of "misc" as a non-package name (which probably ought
> to be stipulated).
This is just the original proposal (option 0) with 'misc' as a reserved
name.
I'm all confused again...
--norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:25:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 94 16:24:15 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407141524.AA08924@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
> Joe doesn't know if it's packages/misc/foobar.cls or
> contrib/misc/foobar.cls
but he does if he looks at the first line of TeX's typeout.
most (all?) TeX's give the full path name, I just thought that seeing
`contrib' in that pathname would be a key that this wasnt part of the
core distribution, however it is not a life and death issue.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:25:59 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOSas-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 16:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>Why add texmf/tex/generic/hyphen? Just for clarity...are there
>really going to be many *other* things in /generic?
The fontinst macros run in plain and LaTeX (I've not checked them with
other formats) so they may as well be in generic/fontinst I guess.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:27:20 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Thu, 14 Jul 1994 16:21:51 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:164990:940714152157"@cl.cam.ac.uk>
I agree with Norm. Joe User with his problem is not going to trace the
route his TeX took to find the .sty file, he's going to mail you guys
anyway. let latexbug.tex read the log file and reject it if it doesnt
contain a magic string ...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:27:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 1994 10:27:24 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098168B.674E0204.5992@SHSU.edu>
Subject: Re: tex/ constituents
On Thu, 14 Jul 94 16:04 BST, alanje@cogs.susx.ac.uk (Alan Jeffrey) kindly
corected me:
> >The
> >base LaTeX files are in macros/latex/base/ on the CTAN; the
> >macros/latex/packages/ are packages which meet pre-specified archival
> >criteria, but are contributed all the same.
>
> Not quite. The contents of macros/latex/packages are packages produced by
> the LaTeX team (and partners in crime such as Sebastian). Anything in
> macros/latex/packages is subject to latexbug. Everything else is in
> macros/latex/contrib, and is not under latexbug. (Not that A. N. User
> understands this, so we still get bug reports on non-L3 material, but what
> can you do...)
And, looking back in the correspondence as we set this up, this is
obviously correct. As I said, I might be sadly mistaken and I was.
> Assuming that bug reporters read the instructions, the distinction between
> latex/SOMETHING/<package> and latex/contrib/<package> is useful, since the
> former are `what you can report with latexbug'. But that `assuming' is
> quite large...
>
> Perhaps:
> latex/
> base/
> latex/<files> (the current latex/base)
> graphics/<files>
> color/<files>
> ...
> contrib/
> ...
> but latex/base/latex does look a bit odd...
Why not kill off the "contrib" though -- if you use
latex/base/distrib/<canonical files>
latex/base/packages/<files>
latex/<package>/<files>
everything in "base" is easily identifiable as subject to latexbug isn't
it? Essentially, this is a taggig element being sought and instructions
along the lines of "if it ain't somewhere in latex/base, don't bother us"
(which, as you note, is a huge assumption) gets the same point across
doesn't it? I still must be dense as I don't see the benefit of creating
the extra "contrib" layer. Sorry.
BTW, how do we handle "local" files -- specify a latex/contrib/local as
allowable (or latex/local or latex/SOMENAME/contrib/local or....)? This
probably needs some specification also.
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:33:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Thu, 14 Jul 1994 16:32:12 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:172530:940714153228"@cl.cam.ac.uk>
one could always have
texmf/tex/latexbase/<package>
texmf/tex/latexother/<package>
but i dont think i'll argue it
SOMENAME -> {official,supported,canonical} > 8 or hopeess
why are these names so difficult
SOMENAME -> canon
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:36:15 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOSkj-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 16:31 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>doesn't it? I still must be dense as I don't see the benefit of creating
>the extra "contrib" layer. Sorry.
There is the slight advantage that people searching for stuff using cd
and ls will find the core stuff more easily... otherwise the core
directory will be swamped with all sorts of other rubbish.
>BTW, how do we handle "local" files -- specify a latex/contrib/local as
>allowable (or latex/local or latex/SOMENAME/contrib/local or....)? This
>probably needs some specification also.
I think we'd better allow sites to use their site name in the name of
the local directory somehow (eg here all the local files are in a
sussex directory).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:39:45 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Thu, 14 Jul 1994 16:38:32 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:175280:940714153855"@cl.cam.ac.uk>
if we have texmf/tex/latex/base/<package>, there is little advantage
to texmf/tex/latex/<package> as opposed to
texmf/tex/latex/contrib/<package>, since the extra layer is already
taken up.
thank god no one has yet asked for contrib/supported and contrib/other!
s
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:43:41 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Thu, 14 Jul 1994 16:40:48 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:176450:940714154055"@cl.cam.ac.uk>
good gracious. david thinks people a) read what TeX writes on the
screen (zut, it scrolled off) or b) know what a log file is. this is
as rare as cheques from the inaldn revenue
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:43:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 11:42:10 -0400
Message-ID: <199407141542.LAA29987@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407141347.JAA29690@jasper.ora.com> <m0qOSas-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 16:21, Alan Jeffrey wrote:
> >Why add texmf/tex/generic/hyphen? Just for clarity...are there
> >really going to be many *other* things in /generic?
>
> The fontinst macros run in plain and LaTeX (I've not checked them with
> other formats) so they may as well be in generic/fontinst I guess.
Maybe, but only if they run under TeXinfo ;-)
My feeling was that packages should go under the lowest-common-denominator
format. If a package (fontinst) runs under plain and all (reasonable?)
formats derived from plain, it should be installed under plain. After
all, I'm likely to have
/texmf/tex/latex//:/texmf/tex/latex209//:/texmf/tex/plain//
in my TEXINPUTS path for LaTeX documents. If we start putting things
in generic, we'll get hopelessly bogged down in the distinction between
plain and generic, I think.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:44:03 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Date: Thu, 14 Jul 1994 16:41:52 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:176940:940714154214"@cl.cam.ac.uk>
zillions of things are generic. pstricks, for instance. epsf.
s
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:46:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 1994 10:46:16 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098168E.09A5D804.5921@SHSU.edu>
Subject: Re: tex/ constituents
On Thu, 14 Jul 94 16:31 BST, alanje@cogs.susx.ac.uk (Alan Jeffrey) (who's
obviously seeing things much more clearly than I am today) replied:
> >doesn't it? I still must be dense as I don't see the benefit of creating
> >the extra "contrib" layer. Sorry.
>
> There is the slight advantage that people searching for stuff using cd and
> ls will find the core stuff more easily... otherwise the core directory
> will be swamped with all sorts of other rubbish.
Cool. Agreed and conceded. So the construct is along the lines of:
/texmf/tex/latex/
base/
distrib/<canonical-files>
<package>
contrib/
<package>/<files-for-package>
misc/<individual-files>
correct?
> >BTW, how do we handle "local" files -- specify a latex/contrib/local as
> >allowable (or latex/local or latex/SOMENAME/contrib/local or....)? This
> >probably needs some specification also.
>
> I think we'd better allow sites to use their site name in the name of the
> local directory somehow (eg here all the local files are in a sussex
> directory).
Might I suggest that, to cover ourselves, that we stipulate this formally
as at least a placement issue since local files are going to exist anyway?
Something along the lines of "local additions to the tree may be made using
any name for the directory or directories so long as they reside within the
/texmf/tex/latex/contrib/<local-specification>/<local-files> hierarchy."
Obviously (I think?), users will still have their current directory plus
any environment variables or paths or logicals or whatever to suit
themselves, but multi-user systems should have minimal guidance in what is
intended, IMO.
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:52:32 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOT0X-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 16:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>Maybe, but only if they run under TeXinfo ;-)
Well, I was thinking of making it run under iniTeX some day...
But yes, as it stands, plain is a resonable enough home for it.
If/when I get round to producing the iniTeXable version, I guess I can
move it to generic or give it its own format name or something.
So the test for being in `generic' is `runs with iniTeX'?
>If we start putting things
>in generic, we'll get hopelessly bogged down in the distinction between
>plain and generic, I think.
If we're not planning on putting anything in it, then why have it?
We'll have to make it clear (if this is what we intend) that LaTeX
needs to run with the plain directory as well as the latex directory.
Alan.
PS: Where does null.tex live then :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 10:54:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 94 16:54:44 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407141554.AA08946@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>>>>> "Sebastian" == Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk> writes:
Sebastian> good gracious. david thinks people a) read what TeX writes
Sebastian> on the screen (zut, it scrolled off) or b) know what a log
Sebastian> file is. this is as rare as cheques from the inaldn revenue
No secretly I accept that we are going to get reports about problems
with some local CERN hack, but if the structure is there so they could
have known this was a local hack, we can reject their report with a
reasonable sounding reason
.../contrib/... is a contributed package .
Otherwise how on earth is joe user supposed to figure out where
foobar.sty came from (of course reading the documentation is not a
realistic answer:-)
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 11:04:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 12:02:46 -0400
Message-ID: <199407141602.MAA00135@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407141542.LAA29987@jasper.ora.com> <m0qOT0X-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 16:47, Alan Jeffrey wrote:
>
> So the test for being in `generic' is `runs with iniTeX'?
>
Hmm, maybe. The LaTeX2e stuff uses iniTeX in ways I would never have
imagined possible.
> >If we start putting things
> >in generic, we'll get hopelessly bogged down in the distinction between
> >plain and generic, I think.
>
> If we're not planning on putting anything in it, then why have it?
For the hyphenation files, mostly. Putting them anywhere *else* seems
to be an error.
> We'll have to make it clear (if this is what we intend) that LaTeX
> needs to run with the plain directory as well as the latex directory.
Yes!
> PS: Where does null.tex live then :-)
In generic, it's always ok to include an empty file, right? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 11:05:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 12:04:07 -0400
Message-ID: <199407141604.MAA00139@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <"swan.cl.cam.:176450:940714154055"@cl.cam.ac.uk> <9407141554.AA08946@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 16:54:44, David Carlisle wrote:
> No secretly I accept that we are going to get reports about problems
> with some local CERN hack, but if the structure is there so they could
> have known this was a local hack, we can reject their report with a
> reasonable sounding reason
> .../contrib/... is a contributed package .
Thanks, David, I'm now 100% convinced that the extra level is worth having.
--norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 12:36:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 94 18:37:12 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407141737.AA09023@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
Cool. Agreed and conceded. So the construct is along the lines of:
/texmf/tex/latex/
base/
distrib/<canonical-files>
<package>
contrib/
<package>/<files-for-package>
misc/<individual-files>
correct?
I would switch round distrib and base (ie distrib for the latex
distribution) base for the `basic format+article.sty' setup as
described in LL's book (more or less)
texmf/tex/latex/
distrib/
base/<the real basic latex stuff>
babel/
graphics/
psnfss/
mfnfss/
tools/
amslatex/
contrib/
misc/<individual-files>
seminar/
.....
distrib/ tree is essentially fixed, but under contrib go any number of
directories corresponding to whatever packages you have at your site.
I am not sure about `local'
I think
texmf/tex/latex/local/ or texmf/tex/latex/manchstr/
ie siblings of distrib and contrib, but
texmf/tex/latex/contrib/local/ or texmf/tex/latex/contrib/manchstr/
are possibilities I suppose.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 13:28:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOVRA-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 19:23 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
> /texmf/tex/latex/
> base/
> distrib/<canonical-files>
> <package>
> contrib/
> <package>/<files-for-package>
> misc/<individual-files>
Something like that. I think I agree with David (eek, members of the
project team caught agreeing with each other in public...) that
distrib/base is better than base/distrib. But I quite liked
Sebastian's `canon'...
>Might I suggest that, to cover ourselves, that we stipulate this formally
>as at least a placement issue since local files are going to exist anyway?
Sounds cool. latex/contrib/<local>/<files> sounds good.
We have a similar thing for epsf files... Our site has
/local/images/<format>/<source>/<file>, e.g.
/local/images/epsf/sussex/ssxcrest.eps. Perhaps a similar directory
in TDS? (Unfortunately it means another directory on the TEXINPUTS
path, if you want TeX to read BoundingBoxes but hey ho...)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 13:29:19 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOVSD-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 14 Jul 94 19:24 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>zillions of things are generic. pstricks, for instance. epsf.
Norm's definition of generic was pretty stringent... it has to run
with virTeX or iniTeX, not just plain TeX. I don't know if we want to
adopt this definition or not...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 13:58:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 1994 13:58:29 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <009816A8.E42647C4.5892@SHSU.edu>
Subject: Re: tex/ constituents
I agree with everythihng David recently posted:
> I would switch round distrib and base (ie distrib for the latex
> distribution) base for the `basic format+article.sty' setup as described in
> LL's book (more or less)
but......
> texmf/tex/latex/
> distrib/
> base/<the real basic latex stuff>
> babel/
> graphics/
> psnfss/
> mfnfss/
> tools/
> amslatex/
^^^^^^^^^
This has always been presumed to be in "packages" (and admittedly is its
CTAN location), but are the latexbug reports for this to really go to
latexbug or the AMS?? I ask because that has been one monolithic
organization which has adamantly opposed any interference with it outside
of the AMS directly (and has been a linking nigtmare to keep composed as
they want it so we can blend it in as we want it on the CTAN). Unless we
have explicit prior arrangements worked out with the AMS, I think this is
something which responsibly belongs in "contrib".
Just picking a nit, but...... 8-)
--GDG
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 14:11:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Jul 94 20:11:52 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407141911.AA09082@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
> This has always been presumed to be in "packages" (and admittedly is its
> CTAN location), but are the latexbug reports for this to really go to
> latexbug or the AMS?? I ask because that has been one monolithic
> organization which has adamantly opposed any interference with it outside
...
Michael Downes of the AMS is on `the team' and amslatex reports
*can* go to him via latexbugs. They can also go direct to AMS of course.
In fact there are some discussions going on to try to separate out the
`generic math stuff' ie amstex.sty amssymb.sty etc with the `submission
to ams journal stuff' putting the former under the latex distribution
and the latter in a separate area, say under contrib. I hope this is
what happens. However there are (understandable) pressures within the
AMS to keep it all together (Barbara?).
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 14:17:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 14 Jul 1994 15:18:04 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
To: TWG-TDS@SHSU.edu
Message-ID: <774213484.940089.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re the ams (or the packages we distribute) as a "monolithic
organization", there is a draft of comments to the draft of
the "directory structure" proposal that is making the rounds
here, and i am trying my best to get it agreed to and sent
before it no longer makes sense.
we are proposing to make some considerable (to us) changes,
but we really only want to do it once. so it's important that
everyone here buy in before we take it public.
none of this is being helped by the fact that the office here
is being renovated, the department is about to move (only
temporary, until our permanent site has been rebuilt), lots of
important sources are in boxes, our internal network is only
working intermittently, there has just been a new division
director hired and ralph youngen, the department manager is
in meetings 10 out of 9 hours every day, blah, blah, blah.
i was hoping for a release of the draft today, but it's looking
bad; still can hope for tomorrow. i was trying to lie low until
i could send something real, but ...
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Jul 1994 19:11:21 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 14 Jul 1994 17:12:07 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407150012.RAA03269@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: package distribution
From: norm@ora.com (Norman Walsh)
Date: Thu, 14 Jul 1994 09:55:45 -0400
Subject: Re: package distribution
> texmf/ini/<system> where it is needed, but what system would
> you specify for a byte-order-independent format file?
/<implementation>, I guess. Is it really the case that two *different* TeX
implementations could share the same format file? Seems unlikely to me...
How different is *different*? I once traded format files
between a Sun-3 and a DECstation. but both were running some
version of Berkeley Unix.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 05:51:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Jul 1994 06:52:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151052.AA25947@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: subdir searching spec
bearing in mind that the web2c scheme doesnt let you limit [subdir
searching] to just one level down, i think? should it?
No, it doesn't.
When I originally implemented subdir searching, I didn't know any way to
make recursive searching fast enough to be feasible; thus, I only did
one level of searching. Then I learned about the st_nlink trick, and
switched to fully recursive searching.
Since the tds requires searching more than level, I can't see any point
in specifying a syntax for it (or in me implementing it :-). Hence, here
is a proposed paragraph, to be inserted before the `This feature is
already supported ...' paragraph in Technical Requirements. (I think
that subsection should be renamed to `Subdirectory searching', by the
way, or `Tech reqts: subdir searching', or somehow get the phrase in
there, so it'll show up in the toc.)
<norm text for context>
As a result, the TWG decided that a comprehensive \tds\ required
some form of subdirectory searching. In other words, it must be possible
to specify that \TeX\ (and other \TeX\ utilities) search in both a
specified directory and recursively through all subdirectories of that
directory when looking for an input file.
<proposed karl text>
To avoid different implementations having different syntaxes for
specifying recursive subdirectory searching, the TWG recommends
[mandates?] that subdirectory searching be specified by a doubled
directory separator. For example, the Unix-style pathname \dir{/a/b//}
would recursively search all directories under \dir{/a/b}; likewise for
\dir{c:\\a\\b\\\\} under DOS.
Implementations may also choose to implement single-level subdirectory
searching (i.e., all the subdirectories of a given directory, but not
subsubdirectories or any deeper level). Since this is not useful for the
\tds\, we leave the syntax for this unspecified.
The implementation must do a breadth-first search of the subdirectories:
given \dir{/d//}, first \dir{/d} must be searched, then \dir{/d}'s
subdirectories, then the subsubdirectories, and so on. The order of
directories searched at each level is left specified (in particular, it
need not be alphabetical, but can be ``directory order'').
<end proposed text>
Question: are there technical problems under DOS with \foo\\?
Question: do we want to specify breadth-first, or does it matter? I
implemented it that way because I thought it would be the least
surprise to users. (In fact, I vaguely remember doing depth-first
searches at one point and getting massive complaints, but I may be
confused.)
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 06:47:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407151024.AA17473@spice.iti.informatik.th-darmstadt.de>
Subject: Re: package distribution
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Jul 1994 12:24:39 +0100 (MESZ)
Content-Type: text
You wrote:
>
> > texmf/ini/<system> where it is needed, but what system would
> > you specify for a byte-order-independent format file?
>
> /<implementation>, I guess. Is it really the case that two *different* TeX
> implementations could share the same format file? Seems unlikely to me...
>
> How different is *different*? I once traded format files
> between a Sun-3 and a DECstation. but both were running some
> version of Berkeley Unix.
And the same version of web2c?
Just for the record, an example: Our setup has one large TeX tree
exported via NFS. Currently, we support 8 different Unix
architectures, some of them run different web2c versions. We don't
have different web2c versions on one architecture, i.e., we can use a
unique architecture identifier to select system-dependent files. Here
it's important to distinguish platform-independent (IMO that's the
correct term for web2c' format files) from system-independent. The
latter is also influenced by the current installation -- while it's
_in principle_ possible to share FMT files, it might not be so in
practice.
Actually, the `architecture directories' are symlinks to
directories that mark different web2c versions.
To illustrate my comments, a snapshot of our installation:
texmf/ini/ % actually, it's another name, to be changed
rs6000 -> web2c-6.1
sun4-4 -> web2c-6.0
sun3 -> web2c-5.851
hp9000s300 -> web2c-5.851
i386-aix -> web2c-5.8a
linux -> web2c-6.0
[..etc...]
web2c-<version>/ % here are FMTs and pool files.
If we had to support emTeX via NFS, we would just add more directories
under ini/.
(In case, it isn't clear by now; I'm all in favor of
ini/<implementation>, and I would even add a recommendation to record
the version number in <implementation> for a larger site.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 06:54:07 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 15 Jul 1994 07:51:58 -0400
Message-ID: <199407151151.HAA02653@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
References: <199407141355.JAA29731@jasper.ora.com> <199407150012.RAA03269@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 July 1994 at 17:12:07, Pierre MacKay wrote:
> > texmf/ini/<system> where it is needed, but what system would
> > you specify for a byte-order-independent format file?
>
> /<implementation>, I guess. Is it really the case that two *different* TeX
> implementations could share the same format file? Seems unlikely to me...
>
> How different is *different*? I once traded format files
> between a Sun-3 and a DECstation. but both were running some
> version of Berkeley Unix.
But both were using the same _implementation_, right? Probably Web2C...
--norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 08:39:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOnPC-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 15 Jul 94 14:34 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>> So the test for being in `generic' is `runs with iniTeX'?
>Hmm, maybe. The LaTeX2e stuff uses iniTeX in ways I would never have
>imagined possible.
If you thought that was bad, have a look at fontinst :-)
>For the hyphenation files, mostly. Putting them anywhere *else* seems
>to be an error.
Well, we could be honest and call the directory hyphen. Or we could
put them in plain, or ini. If we're restricting ourselves just to
things which run in initex, I think an initex directory is better than
a generic directory. It sounds like every tex format is going to have
to have plain on its input path anyway...
>In generic, it's always ok to include an empty file, right? ;-)
Try changing the catcode of % and inputting null.tex... (and yes, some
formats do change % to be catcode `other').
I think we need to either relax the conditions on what's allowed in
generic (so things like epsf and pstricks are allowed), or change it's
name to initex or hyphen or something.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 08:42:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407151342.AA19220@spice.iti.informatik.th-darmstadt.de>
Subject: Re: subdir searching spec
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Jul 1994 15:42:16 +0100 (MESZ)
Content-Type: text
Karl wrote:
>
> <proposed karl text>
> [...]
>
> Question: do we want to specify breadth-first,
IMO yes.
How about a hint to kpathsea(rch) as a freely distributable package
that implements the above strategy? Along the line of ``there you can
see how one can implement this strategy in a POSIX.1 environment.'' Of
course, commercial folks have to implement it anew since kpathsea is
under the GPL.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:18:43 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 15 Jul 1994 08:19:26 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151519.IAA16891@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: package distribution
texmf/ini/<whatever> works fine for me. all I have
to do is add another / to my TEXFORMATS environment.
So it looks as if we have committed consensus yet again!!!
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:20:24 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 15 Jul 1994 08:21:10 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151521.IAA17012@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: package distribution
texmf/ini/<whatever> it is.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:22:31 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: package distribution
Date: Fri, 15 Jul 1994 16:22:16 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:100450:940715152240"@cl.cam.ac.uk>
where did Joachim get webc-6.0...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:28:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407151528.AA24985@spice.iti.informatik.th-darmstadt.de>
Subject: Re: package distribution
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Jul 1994 17:28:55 +0100 (MESZ)
Content-Type: text
sebastian wrote:
>
> where did Joachim get webc-6.0...
>From ftp.cs.umb.edu -- ftp.th-darmstadt.de is a mirror site... :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
ftp.th-darmstadt.de, Administration
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:41:44 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 15 Jul 1994 08:42:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151542.IAA18556@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
>In generic, it's always ok to include an empty file, right? ;-)
Try changing the catcode of % and inputting null.tex... (and yes, some
formats do change % to be catcode `other').
Well, that wasn't quite the question. null.tex is not an empty file
it is a file with only comments. I suppose that is necessary under
some OS limitations. I never use the distributed null.tex.
touch null.tex
and
touch nul.tex
and
touch nil.tex
are so much cleaner.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:46:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 15 Jul 1994 08:47:16 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151547.IAA18903@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: subdir searching spec
see how one can implement this strategy in a POSIX.1 environment.'' Of
course, commercial folks have to implement it anew since kpathsea is
under the GPL.
Not entirely so. Since kpathsea is a separately compiled library,
it can also come under the GNU library license. Karl and I discussed
this early on in hopes that a couple of (we won't say who)
developers might consent to use the library even though
they had qualms about the larger GNU GPL.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
North American academic institutions have been taken over by MBA
bean-counters and genuine or wannabe industry CEOs. Just when
American industry is beginning to doubt the wisdom of autocratic
pyramidal dictatorship, most American Universities have adopted
that style of management, which is nice for refugees from defense
industry boardrooms, but rather sickening for the rest of us.
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 10:55:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407151556.AA25041@spice.iti.informatik.th-darmstadt.de>
Subject: Re: subdir searching spec
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Jul 1994 17:56:04 +0100 (MESZ)
Content-Type: text
Pierre wrote:
>
> see how one can implement this strategy in a POSIX.1 environment.'' Of
> course, commercial folks have to implement it anew since kpathsea is
> under the GPL.
>
> Not entirely so. Since kpathsea is a separately compiled library,
> it can also come under the GNU library license.
^^^
Currently, it's legal status is not clear. The README says ``look at
COPYING*''. I would interpret this as if one has to use the stronger
of both licences. (Actually, I would interpret all READMEs as if
COPYING.LIB is there just for fun and has no further purpose...)
> Karl and I discussed
> this early on in hopes that a couple of (we won't say who)
> developers might consent to use the library even though
> they had qualms about the larger GNU GPL.
Then you should make the status clearer. (Note, I don't have problems
with a GPL kpathsea; I just think an open implementation is a Good
Thing for a TDS, just as an open implementation is a Good Thing for a
standard.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 11:17:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Jul 1994 12:18:04 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407151618.AA27897@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: subdir searching spec
This has nothing to do with the TDS, but oh well.
All the files have their own copyright notice; that is what determines
the copyright status. Currently, all the files I wrote are covered
by the GPL. Some of the files that the FSF wrote are covered by
the LGPL; that's why COPYING.LIb is included. The statement in the README
is just there for general information, it has no legal purpose.
I would consider changing kpathsea to be covered by the LGPL if
someone says they would actually use it in that case, when they
wouldn't if it stays GPL. I prefer to keep the stronger conditions until
then.
It is not true that commercial developers have to avoid kpathsea.
(Even under the GPL.) It is only true *if* they do not want
to distribute source. The GPL allows profit-making (unlike the
latex2e conditions, but that's another story).
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Jul 1994 15:05:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qOt2f-000076C@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 15 Jul 94 20:35 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
> Try changing the catcode of % and inputting null.tex... (and yes, some
> formats do change % to be catcode `other').
>Well, that wasn't quite the question.
Sorry, I omitted the :-) from the above...
>touch null.tex
There are certainly TeX installations were you can scupper that with
appropriate catcodes for ^^M or ^^Z, but I think I may be stretching a
point here :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 16 Jul 1994 05:40:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 16 Jul 1994 06:40:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407161040.AA06296@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: texmf/ini/<implementation>
texmf/ini/<implementation> makes sense for .fmt and .base files.
Does the TDS want to specify a directory for *other*
implementation-dependent files?
Specifically, kpathsea's ls-R (now kept in the top-level, texmf,
directory).
And the next kpathsea will have config files and a provision for
logging.
These things have nothing to do with `ini' (or web2c, for that matter),
but I am loath to say there should be two implementation directories.
Hmm, maybe `kpathsea' is another ``discretionary'' top-level directory,
like dvips? Yes, that makes sense, I think. ini/web2c can stay for the
.fmt's and .base's.
What about emtex's config files (and any other extras it has), though?
Would they go in texmf/ini/emtex? Or texmf/emtex?
If the latter, does the former stay?
Hmm.
================================================================================
From owner-twg-tds@shsu.edu Sat, 16 Jul 1994 08:18:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 16 Jul 1994 09:19:11 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407161319.JAA13251@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: tex/ constituents
References: <199407151542.IAA18556@june.cs.washington.edu> <m0qOt2f-000076C@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 15 July 1994 at 20:35, Alan Jeffrey wrote:
>
> >touch null.tex
>
> There are certainly TeX installations were you can scupper that with
> appropriate catcodes for ^^M or ^^Z, but I think I may be stretching a
> point here :-)
Actually, since I can't resist a little more stretching, the file null.tex
on my system is 0 bytes long (no %, no ^^M, no ^^J, no ^^Z...). There's
nothing you can do --- nyah, nyah, na-nyah, nyah ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Jul 1994 08:58:01 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/ini/<implementation>
Date: Mon, 18 Jul 1994 14:58:19 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:159360:940718135830"@cl.cam.ac.uk>
i think we should stick with one word throughout for `independent'; i
favour `general', so texmf/ini/general could have anything that was
genuinely general (like what?)
i dont see why people cant use this as they like. if they want
texmf/ini/web2c/alpha
/sunos
then they can arrange it accordinly, with a config file in
texmf/ini/web2c
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Jul 1994 10:31:04 CDT
Sender: owner-twg-tds@SHSU.edu
To: twg-tds@shsu.edu
Subject: TDS -> more people
Date: Mon, 18 Jul 1994 16:30:18 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:202070:940718153057"@cl.cam.ac.uk>
can i suggest that Norm issue a 2nd draft of TDS and that we make
multiple paper copies to give away at Santa Barbara for comment? we
could also have a TDS BOF at which we could toast Karl _in absentia_
and try and agree on the final thing?
to go back a stage, I think we are saying that
texmf/tex/general should only be read by initex. i dont mind the idea,
but i mind the name. let it be more specific, if thats what it
means. i'd say lets have
texmf/tex/hyphen
speciifically for patterns, and keep
texmf/tex/general
for things of universal validity like null.tex. I *dont* like the idea
of having
texmf/tex/plain
on my LaTeX path, because I don't want eg my LaTeX to search all of
psszl, or edmac or something like that. there *are* three cases of a)
initex-only, b) compatible with all formats, and c) limited to one
format
sebastiuan
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Jul 1994 12:58:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407181759.AA17830@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS -> more people
To: TWG-TDS@SHSU.edu
Date: Mon, 18 Jul 1994 19:59:07 +0100 (MESZ)
Content-Type: text
You wrote:
>
> [Santa Barbara] we
> could also have a TDS BOF at which we could toast Karl _in absentia_
Yes. (For the BOF and for both meanings of `to toast'... ;-)
> I *dont* like the idea
> of having
> texmf/tex/plain
> on my LaTeX path, because I don't want eg my LaTeX to search all of
> psszl, or edmac or something like that.
Entusiastic [sp?] agreement.
> there *are* three cases of a)
> initex-only, b) compatible with all formats, and c) limited to one
> format
Though I would work b) as `compatible with virtually all formats that
use the plain catcodes as outlined in the TeXbook.' (As an example,
it may not be compatible to texinfo -- but then, that special case is
often stretched to much. Don't forget @tex -- eg, I incorporate
xfig/transfig output often in Texinfo documents without any
problems.) I think this category (b) is large enough to warrant an
own directory.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Jul 1994 15:19:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 18 Jul 1994 16:17:25 -0400
Message-ID: <199407182017.QAA08671@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS -> more people
References: <"swan.cl.cam.:202070:940718153057"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 18 July 1994 at 16:30:18, Sebastian Rahtz wrote:
> can i suggest that Norm issue a 2nd draft of TDS and that we make
> multiple paper copies to give away at Santa Barbara for comment? we
> could also have a TDS BOF at which we could toast Karl _in absentia_
> and try and agree on the final thing?
Sounds good. Another interrim draft is coming today...but it doesn't
reflect anthing discussed since last Friday...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 10:12:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Jul 1994 10:11:17 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@SHSU.edu
Message-ID: <00981A76.FAF39624.5876@SHSU.edu>
Subject: this is the kind of crap we HAVE to fix!!
Just received on INFO-TeX. This is exactly why the TDS has to be clear about
file names, etc.
--GDG
===========================================================================
X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
Date: Tue, 19 Jul 94 10:52:32 EDT
From: Harriet_Borton@MTS.RPI.EDU
Reply-To: Harriet_Borton@MTS.RPI.EDU
To: INFO-TeX@SHSU.edu
Message-ID: <4427991@MTS.RPI.EDU>
Subject: pk files for ps fonts
I have downloaded and am trying to use the pk files for the postscript
fonts (times, helvetica, etc) with xdvi. The files have names such
as ptmr.300pk. However, xdvi cannot use these files because it appears
to be looking for the "raw" names. Latex 2.09 wants rptmr.300pk, and
Latex2e wants ptmr0.300pk. I tried renaming one of the fonts to the
raw name, and this made xdvi happy. However, I'm reluctant to rename
them all-- if the names were supposed to be this way, then why weren't
they named as such in the distribution? Have I done something wrong
in the xdvi installation? I am using xdvik 1.8.
Thanks for any insight anyone might have.
-Harriet Borton
Computing Center
Rensselaer Polytechnic Institute
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 10:42:21 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 19 Jul 1994 08:42:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191542.IAA21156@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: Re: this is the kind of crap we HAVE to fix!!
Agreed absolutely. I answered as best I could. For now,
crude links between r*.nnnpk and *0.nnnpk will serve
as a stopgap in most cases.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 10:42:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 19 Jul 1994 08:42:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191542.IAA21156@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: Re: this is the kind of crap we HAVE to fix!!
Agreed absolutely. I answered as best I could. For now,
crude links between r*.nnnpk and *0.nnnpk will serve
as a stopgap in most cases.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 10:47:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407191548.AA18385@spice.iti.informatik.th-darmstadt.de>
Subject: Re: this is the kind of crap we HAVE to fix!!
To: TWG-TDS@SHSU.edu
Date: Tue, 19 Jul 1994 17:48:24 +0100 (MESZ)
Content-Type: text
You wrote:
>
> Just received on INFO-TeX. This is exactly why the TDS has to be clear about
> file names, etc.
The problem at hand is a wrong dvips configuration. I don't think that
any TDS recommendation about file names would change this. The person
did not understand what psfonts.map is about. (Note, I don't say that
it's easy to understand or even obvious.)
I'm all in favor of getting TDS done, but we should not bring up pro
arguments that are not connected to the issue per se.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:06:35 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: this is the kind of crap we HAVE to fix!!
Date: Tue, 19 Jul 1994 17:01:45 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:046920:940719160311"@cl.cam.ac.uk>
if i thought the TDS would fix that... but it wont. that requires
another little project to agree on font names (cf n millions mail
messages to/from self, Karl, Alan, Pierre)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:06:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 19 Jul 1994 09:06:05 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191606.JAA23384@june.cs.washington.edu>
To: TWG-TDS@shsu.edu
Subject: [mackay: Re: pk files for ps fonts]
Date: Tue, 19 Jul 1994 08:41:13 -0700
From: mackay (Pierre MacKay)
To: Harriet_Borton@MTS.RPI.EDU
Cc: kb@cs.umb.edu, unixtex@u.washington.edu, mackay@cs.washington.edu,
alanje@cogs.susx.ac.uk, Sebastian.Rahtz@cl.cam.ac.uk
In-reply-to: Harriet_Borton@MTS.RPI.EDU's message of Tue, 19 Jul 94 10:52:32 EDT <4427991@MTS.RPI.EDU>
Subject: Re: pk files for ps fonts
I have downloaded and am trying to use the pk files for the postscript
fonts (times, helvetica, etc) with xdvi. The files have names such
as ptmr.300pk. However, xdvi cannot use these files because it appears
to be looking for the "raw" names. Latex 2.09 wants rptmr.300pk, and
Latex2e wants ptmr0.300pk. I tried renaming one of the fonts to the
raw name, and this made xdvi happy. However, I'm reluctant to rename
them all-- if the names were supposed to be this way, then why weren't
they named as such in the distribution? Have I done something wrong
in the xdvi installation? I am using xdvik 1.8.
If it's any consolation, what you have tripped over is a pretty
hot item in Email consultation right now. The "base" font
choices, which is what you are running into are not directly
governed by latex209 or LaTeX2e. What is happening is that
the older latex is pulling in one set of font metrics and the
newer is pulling in another. Buried inside those metric files
is the choice between rptmr and ptmr0. It is becoming clear
that neither is entirely desirable, but I won't worry you with that.
Now for the (relatively) good news. The difference between rptmr and
ptmr0 is not great, and you will have reasonable, though not
necessarily perfect, results if you simply link the r*.nnnpk files to *0.nnnpk
files. It is not something you should have to do, and I regret having
to impose this extra task on you, but it is the only reasonable
approach for now. We are pushing ahead on a thorough rationalization
of the problem as fast as we can.
I am mildly surprised that rptmr.300pk mapping has worked so
well for you in the past, but that is probably because I play
around with font remapping more than most.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:10:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 19 Jul 1994 12:07:36 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
CC: rey@MATH.AMS.ORG
Message-ID: <774634056.946287.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
here at ams, we've joined forces to provide just one set of comments
on the draft proposal. our comments are of several kinds:
- questions of presumably general import
- comments on areas that affect just ams
- editorial comments
some of the general questions have already been addressed in the
discussions, and i've tried to provide reasonable background to
the people i asked to comment. however, there may be some old
ground covered once again; in such a case, i hope that responses
will deal with the specific points raised, so that i can convey
a clear position to the person who asked the question.
first of all, we agree in principle with the goals of the project.
we have a bit of concern about rather different structures being
adopted for the operational system vs. the ctan archive, as it
means we will have to be familiar with both in order to generate
good documentation for the packages we distribute and support.
but if the structure defined in this proposal is indeed widely
agreed on and adopted, it should be a plus in the long run.
it would be helpful to know what the projected schedule might be
for adoption of this structure. more specifically, when will files
be expected to be ready for norm's cd? essentially all of our user
documentation will be rendered obsolete by these changes, and it
will take us some time to revise it.
************************************************************************
general questions
it's not entirely clear to whom this document is addressed. i believe
the target is the systems administrator. whoever it is, it should be
stated explicitly somewhere near the beginning.
sec.1.1, technical requirements, para.2
Most implementations provide some ability to load files from different
directories by specifying a list of directories to search (in the
\env{TEXINPUTS} environment variable or a system configuration file,
for example), but this is insufficient in the general case.
it would make a stronger statement, as well as being clearer to the
average reader (i.e., one who hasn't had the benefit of the full
discussion here) to explain briefly *why* an environment variable
or search list is insufficient.
sec.1.1, technical requirements, para.3
As a result, the TWG decided that a comprehensive \tds\ required
some form of subdirectory searching. ...
has anyone checked with barry smith and andrew trevorrow to find out
if they will buy in to the general concept of subdirectory searching?
(bob harris has said that barry is not particularly interested at
this point in implementing the proposed font structure because of
the peculiarities of the mac.)
is the same technique of subdirectory searching to be used for fonts
as well as to input files? if so, say it, please.
for an operational system, it's sometimes necessary to have multiple
different versions of a file of the same name, for testing, or for
special purposes. presumably only a "final form" will get into an
archive, but to say that only one file with a particular name can
exist in the proposed directory structure is, frankly, blind to
reality. some method has to be available to give preference to a
particular version for a particular purpose. (in our production
setup, we define TEXINPUTS to be a string of logical locations:
mydsk1
usual input locations
mydsk2
the bracketing logicals are usually assigned to a directory /empty
(by name and in fact); they can easily be assigned at run time to
test areas, and the ordering determines precedence, essential for
testing.) it's probably not necessary to specify such an exceptional
search path, but for the random user, it would be helpful to explain
how to set one up.
sec.1.2, constraints, para.2,3
along with the reference to iso 9660 and comment about monocase file
names, it should be made clear that file names (on some systems) must
begin with a letter.
sec.4, fonts
texmf/fonts/<source>/<typeface>/<type>
although this makes the provenance of various fonts quite clear, the
need for tex (or a dvi driver) to traverse the entire tree to find
the asked-for .tfm (or .pk) file would result in a substantial
performance hit for installations like ours where we have literally
thousands of .pk files (more than 4000 by actual count), certainly
hundreds of .mf, .pf* and .vf/.vpl's, and always many files by other
names in test.
of course, we're free to use another production structure (and i'm
sure we will), but this could be detrimental on even a small system
on a slow machine. putting the <type> (tfm, pk, etc.) at a higher
level, above <source>/<typeface>, would streamline the searching
considerably. (it simply isn't practical to make an explicit search
path for so many font directories.)
it really would seem preferable to have an organization that did
not penalize anyone quite so heavily, even at the expense of being
slightly less scrutable or more fragmented.
sec.5, documentation
is the proposed structure meant to apply to ctan as well as to an
operational structure? we have a very great concern that when a
package is retrieved, it be retrieved completely, including
documentation. how can this be assured? granted that people
often don't *read* the documentation that is provided, but please
give them a fighting chance to make sure it's available without
significant extra effort. this also applies to fonts associated
with or required by a package; for example, xypic and amstex are
crippled without the required fonts. in fact, this in itself is
a documentation problem -- how to inform a user/sysadmin that some
additional files of another type are required?
sec.8, example
it's necessary, or at least advisable, to distinguish between an
official distribution (say for latex) vs. local config files. a
system adminstrator (or standalone user) needs to be able to
reinstall a package easily and reliably, without having to check
every file for local modifications.
************************************************************************
comments on specific areas affecting ams
sec.5, documentation, package
the simple name "ams" does not represent one package, but several.
at present we have the following "separate" documentation:
user guides: amstex, amslatex, amsfonts
guidelines for ams authors: amstex, amslatex
we also distribute a number of packages directed to authors of
various specific publications, which incorporate publication-specific
documentation; these author packages may be either amstex or amslatex
or both for any particular publication.
the question is, therefore, should the node below "doc" remain "ams",
with a further level to identify the particular package, or should
"ams" diversify into the multiple packages? the latter seems a bit
more supportable.
in the present structure at e-math.ams.org (and mirrored on ctan),
each level of the structure contains a READ.ME file, giving information
specific to that level and offering hints on installation, identifying
other files necessary to build a coherent system, etc. obviously,
this can be rewritten, but it's not entirely obvious how, other than
that this information should *not* be placed exclusively into files
that must be (la)texed and printed in order to be read. in order to
tackle this problem, we have to know exactly what structure we will
be expected to adhere to, and hope that it will be the same for the
operational tds and for ctan. (we simply can't afford to generate
and maintain multiple incompatible versions.)
it's not at all clear where to put the files that are now located on
ctan (following the e-math conventions rooted in /ams) under
tex-archive/fonts/ams/author-info/sty-files
these are the author packages referred to above. they are of interest
to ams authors, but this is probably less than 10% of the regular users
of ctan, and probably even less than that of users of a cd. maybe they
just get omitted from the tds?
************************************************************************
editorial comments
sec.1, l.1 -- "preperation" should be "preparation"
sec.1.1, p.2, l.1 -- "maintainance" should be "maintenance"
sec.1.2, constraints, para.2,3
along with the reference to iso 9660 and comment about monocase file
names, it should be made clear that file names (on some systems) must
begin with a letter.
sec.3, p.2, l.1 -- "maintainance" should be "maintenance"
sec.3, p.2, l.2 -- "seperate" should be "separate"
sec.4, l.2 -- "maintainance" should be "maintenance"
sec.4, l.3 -- "seperate" should be "separate"
sec.4, p.3, l.2 -- "sheme" should be "scheme"
sec.6, l.2 -- "insallers" should be "installers"
sec.5, p.2, l.3 -- "seperate" should be "separate"
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:21:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Jul 1994 12:20:06 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191620.AA00488@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: this is the kind of crap we HAVE to fix!!
Actually, this is not a TDS issue. It's a font issue,
specifically with PostScript fonts and LaTeX.
Pierre, Alan, Sebastian, and I are trying to work out a preliminary
answer for public comment.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:21:17 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 19 Jul 1994 09:19:05 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191619.JAA24293@june.cs.washington.edu>
To: schrod@iti.informatik.th-darmstadt.de, TWG-TDS@SHSU.edu
CC: mackay@cs.washington.edu
Subject: Re: this is the kind of crap we HAVE to fix!!
The problem at hand is a wrong dvips configuration. I don't think that
any TDS recommendation about file names would change this. The person
did not understand what psfonts.map is about. (Note, I don't say that
it's easy to understand or even obvious.)
Now wait a dogbone minute. This was about the bitmap fonts used
with xdvi. It had nothing to do with dvips. We are clearly
dealing with an intelligent and resourceful user, and we had
better treasure our relations with such people.
The bitmap font display question is a mess. Complicated by
the fact that, until recently, vf interpretation was accidentally
shut off altogether. Let's admit it and straighten it out,
and above all let's make sure that we understand the frustrations
of people like Borton.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 11:48:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Jul 94 17:45:28 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407191645.AA12146@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: rey@MATH.AMS.ORG
Subject: Re: Spec: First Draft
bb> has anyone checked with barry smith and andrew trevorrow to find out
bb> if they will buy in to the general concept of subdirectory searching?
The following is a quote from Barry Smith (in a private message to me
about other aspects of setting up latex2e for textures)
Anyway, Textures 1.7 will allow a prefix ':' to indicate that
_only_ the folder of the current job will be searched. (It'll
also allow recursive searching of sub-folders of the TeX inputs
folder, including aliases, so a general search path can be
defined therein. There's also a dumb syntax trick that allows
sub-folders that are specific to a given format, so separate
folders could be defined for LaTeX209 and LaTeX2e to keep
things straight even though they have the same name(s).)
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 12:55:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407191755.AA20557@spice.iti.informatik.th-darmstadt.de>
Subject: Re: this is the kind of crap we HAVE to fix!!
To: TWG-TDS@SHSU.edu
Date: Tue, 19 Jul 1994 19:55:06 +0100 (MESZ)
Content-Type: text
You wrote:
>
> The problem at hand is a wrong dvips configuration. I don't think that
> any TDS recommendation about file names would change this. The person
> did not understand what psfonts.map is about. (Note, I don't say that
> it's easy to understand or even obvious.)
>
> Now wait a dogbone minute. This was about the bitmap fonts used
> with xdvi. It had nothing to do with dvips. We are clearly
> dealing with an intelligent and resourceful user, and we had
> better treasure our relations with such people.
Oh, I didn't want to imply that he is not intelligent. (And I would
have used other wording in a direct reply.) And I was wrong in writing
`dvips configuration.' It was a short cut in my thinking, the whole
problem -- as far as I can understand it -- concerns the handling of
raw vs. recoded Postscript fonts.
Actually, I think that's one of the most difficult areas in using
Postscript fonts (be it built-in, downloadable, or PK format). That
was the point I meant when I was writing ``it's not easy to
understand,'' namely the half dozen points where TeX and the DVI
driver(s) may map encodings.
Nevertheless, I still think that this is a good example of the
*inherent limits* of TDS. IMO it will not solve this problem. Since
it's a problem which fonts in which encodings are used by which macro
packages and are available directly or via VF files. No naming
structure in the world will be able cover this. (At least, I cannot
see how it could cover this.)
Oh yes, _if_ somebody has a good summary (i.e., an extended abstract)
about this whole encoding business (starting from xchr/xord until
Postscript encoding vectors) I would be pleased to get it. In
particular, it should be placed on CTAN then. There is even a place in
TDS for it... :-) :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 13:04:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Jul 1994 14:04:09 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407191804.AA02627@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: Spec: First Draft
rather different structures being
adopted for the operational system vs. the ctan archive,
It should be feasible for CTAN to adopt most of the TDS changes? I think
they are not that far apart.
it would be helpful to know what the projected schedule might be
for adoption of this structure.
I imagine it will happen over time. I am trying to change my software to
conform to the TDS guidelines as they become reasonably stable.
it's not entirely clear to whom this document is addressed. i believe
the target is the systems administrator. whoever it is, it should be
stated explicitly somewhere near the beginning.
<begin proposed text>
This document is intended both for the \TeX\ system administrator at a
site, and for people preparing \TeX\ distributions---everything from a
complete runnable system to a self-contained macro package. It may also
help \TeX\ users find their way around their local system.
it would make a stronger statement, as well as being clearer to the
average reader (i.e., one who hasn't had the benefit of the full
discussion here) to explain briefly *why* an environment variable
or search list is insufficient. <begin proposed text> Given the
need to have each package and typeface in a separate directory,
explicitly listing all directories to be searched would be
unbearable---there are dozens of packages and typefaces a site may wish
to install, leading to paths many thousands of characters long. Also,
installing or removing a new package would also mean changing a path as
well as installing or removing the actual files, an error-prone
operation. On systems without runtime configuration files, it may even
require recompiling software, an intolerable burden.
is the same technique of subdirectory searching to be used for fonts
as well as to input files? if so, say it, please.
Yes, fonts too. It would be wrong to restrict subdir searching to only
certain kinds of files, though .tex, .tfm, and pk are the only ones that
really need it.
<norm text>
In other words, it must be possible
to specify that \TeX\ (and other \TeX\ utilities) search in both a
specified directory and recursively through all subdirectories of that
directory when looking for an input file.
<proposed text>
... an input file, that is, a \TeX\ macro file, TFM file, or a PK
bitmap font. We encourage implementors to provide subdirectory searching
(at the option of the installer and user) for all paths.
it's sometimes necessary to have multiple
different versions of a file of the same name,
Then I think you must specify the directories to be searched,
explicitly, as you do now. I can't imagine any useful way to specify an
order in which to search subdirectories.
BTW, kpathsea has been effectively enforcing the constraint of ``only
one filename'' for several years, and it doesn't seem much of a problem.
along with the reference to iso 9660 and comment about monocase file
names, it should be made clear that file names (on some systems) must
begin with a letter.
Which systems are these? 00readme is an invalid name?
we have a very great concern that when a
package is retrieved, it be retrieved completely, including
documentation.
As the tds says, distributors should continue to make distributions with
their own top-level name: amsfonts[-<version>]/, with subdirectories as
specified by the tds (tex/, fonts/, doc/, etc.). That way, people
retrieving it will be sure of getting everything.
Perhaps for packages with multiple file formats, like xypic and amstex,
CTAN should not even have a macros/xypic and fonts/xypic, but rather
just packages/xypic/{macros,fonts}? Or, if you prefer,
macros/xypic/{tex,fonts}. Then it would be truly difficult for people
to avoid retrieving the whole thing.
should the node below "doc" remain "ams",
with a further level to identify the particular package, or should
"ams" diversify into the multiple packages? the latter seems a bit
more supportable.
The latter seems good to me. The mere fact that the AMS distributes
several packages doesn't (to me) warrant putting all the documentation
in one documentation.
tex-archive/fonts/ams/author-info/sty-files
author-info? Is that logically like another package, perhaps, not part
of amsfonts? Are the files there useful for production tex documents? If
so, they should be in the tds somewhere. If not, they should be in a
documentation directory.
If they belong in the tds, texmf/tex/amsfonts/author-info seems like a
reasonable place? Well, I guess they are latex files, so make that
texmf/tex/latex/contrib/amsfonts/author-info?
(saving the biggie for last)
texmf/fonts/<source>/<typeface>/<type>
although this makes the provenance of various fonts quite clear,
One reason for this structure is to make it easy for people and programs
to (un)install new typefaces. If you put <type> earlier, this becomes
harder, since everything related to times roman is not in a single
directory.
a substantial
performance hit for installations like ours where we have literally
thousands of .pk files (more than 4000 by actual count), certainly
hundreds of .mf, .pf* and .vf/.vpl's, and always many files by other
names in test.
The number of files doesn't really matter. It's the number of
directories to go through. Unless you are advocating storing all the
PK's in one directory (in which case you get a severe performance hit on
VMS, as discussed before), you're going to have the same number of
directories to search in any case.
of course, we're free to use another production structure (and i'm
sure we will),
You shouldn't have to, given a decent implementation.
putting the <type> (tfm, pk, etc.) at a higher
level, above <source>/<typeface>, would streamline the searching
considerably.
How so?
(it simply isn't practical to make an explicit search
path for so many font directories.)
Exactly. That's why you need subdirectory searching!
The default kpathsea path for tfm's is $TEXMF/fonts//tfm, which is to
say, all and only the `tfm' directories under fonts.
Even this is too many directories to search (56 on my system, doubtless
many more on yours). So I implemented a simple text ``database'' of the
available files (produced with ls -R) that effectively reduces search
time to nil (the defining characteristic of a ``decent
implementation'').
If you're going to have any structure at all, you are going to have lots
of directories to look through. Our implementations simply have to
change to support this, else we will be stuck in the
all-tfms-in-one-directory setup forever, won't we?
How are your font files arranged now?
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Jul 1994 13:25:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Jul 94 19:25:23 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407191825.AA12246@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
I think weve been here before but...
>
> putting the <type> (tfm, pk, etc.) at a higher
> level, above <source>/<typeface>, would streamline the searching
> considerably.
>
> How so?
>
> (it simply isn't practical to make an explicit search
> path for so many font directories.)
>
> Exactly. That's why you need subdirectory searching!
>
> The default kpathsea path for tfm's is $TEXMF/fonts//tfm, which is to
> say, all and only the `tfm' directories under fonts.
>
>
In general I am in favour of the proposed scheme, and with Karl's stuff
it works just fine, but it does more or less force the extended notion
of subdirectory searching as Karl sketched above.
If you only have (in kpthsea syntax) the possibility of a final //
then having $TEXMF/fonts// rather than $TEXMF/fonts/tfm// must surely
be a big performance loss as you have to search over the pk dirs for a
tfm file. If you have the ls-R file or $TEXMF/fonts//tfm then you are
OK, but currently only webc TeX has this?
So the success or not of the proposed scheme seems to rest on whether
other TeX implementations and related programs are going to support
this type of searching, or just `simple' subdirectory searching.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 04:51:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Jul 1994 05:52:17 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407200952.AA18176@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: extended subdir searching
As I said, even fonts//tfm is not enough for fast searches.
(Much to my dismay at the time.)
So I don't think the tds needs to mandate this.
What implementations have to do is something like ls-R to
make searches fast. (That's easier to implement, too!)
But the tds should simply point out that searches should be fast,
and describe both these things, without mandating any particular
implementation, since there may well be other ways of doing it.
I'll try to write a paragraph or two, unless others say nay.
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 05:07:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Jul 94 11:08:23 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407201008.AA12670@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: extended subdir searching
> I'll try to write a paragraph or two, unless others say nay.
Sounds like a good idea to me, as you have the most experience of the
technical issues here.
If we are planning to distribute a draft at TUG94, it might be politic
to try to get it to the main TeX and driver implementors before then
(ie real soon). We need to get them on board, if the impression is
gained (even if it is a false impression) that standardising on TDS
means standardising on web2c/kpathsea some implementors may feel
rather aggrieved. So if Karl could supply a few soothing words to the
effect that supporting this structure is reasonably easy to add to any
implementation, and also if we can try to give such people a few days
(or minutes:-) head start over a public release of a TDS draft it may
help to gain acceptance of the proposal.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 10:02:39 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: extended subdir searching
Date: Wed, 20 Jul 1994 15:52:05 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:008110:940720145218"@cl.cam.ac.uk>
i think a few more pars from Karl would be great. and we should keep
stressing that the TDS is put forward as a fixed point, not an
absolute requirement. people can flatten their directories as much as
they like, if they just say what they have done in relation to the TDS
structure
i agree with David - sending the next draft to the implementors list
would be polite and politic and almost certainly useful in terms of
feedback.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 10:02:43 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Wed, 20 Jul 1994 16:01:30 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:010180:940720150149"@cl.cam.ac.uk>
> we have a bit of concern about rather different structures being
> adopted for the operational system vs. the ctan archive, as it
> means we will have to be familiar with both in order to generate
> good documentation for the packages we distribute and support.
> but if the structure defined in this proposal is indeed widely
> agreed on and adopted, it should be a plus in the long run.
i think this is a concern, but inevitable. at least two structures is
better than one ctan, and one for every implementation. unless we
adopted Karl's radical proposal, what can we do?
> it would be helpful to know what the projected schedule might be
> for adoption of this structure. more specifically, when will files
> be expected to be ready for norm's cd? essentially all of our user
> documentation will be rendered obsolete by these changes, and it
> will take us some time to revise it.
Norm and I were planning to try and get a beta disk out by EuroTeX
(having dropped the idea of a TUG94 one, since that already has the
launch of the PTF disk). i think getting the AMS stuff right is so
important i for one will volunteer to help :-}
> it's not entirely clear to whom this document is addressed. i believe
> the target is the systems administrator. whoever it is, it should be
> stated explicitly somewhere near the beginning.
and the package creator, eg Bob Harris or Eberhard Mattes
> average reader (i.e., one who hasn't had the benefit of the full
> discussion here) to explain briefly *why* an environment variable
> or search list is insufficient.
because it would have to be changed whenever one added a new package,
i guess is teh answer?
> is the same technique of subdirectory searching to be used for fonts
> as well as to input files? if so, say it, please.
god , yes. if this isnt clear, it should be!
> reality. some method has to be available to give preference to a
> particular version for a particular purpose. (in our production
you do still have environment variables to use. or config files. i
think this is slight;y beyond our remit
> the asked-for .tfm (or .pk) file would result in a substantial
> performance hit for installations like ours where we have literally
> thousands of .pk files (more than 4000 by actual count), certainly
> hundreds of .mf, .pf* and .vf/.vpl's, and always many files by other
it isnt that bad. searching texmf/fonts/foo/bar//pk will *not* hit the
tfms, mfs, what have you
> on a slow machine. putting the <type> (tfm, pk, etc.) at a higher
> level, above <source>/<typeface>, would streamline the searching
> considerably. (it simply isn't practical to make an explicit search
it would also destroy the whole point....
> it really would seem preferable to have an organization that did
> not penalize anyone quite so heavily, even at the expense of being
> slightly less scrutable or more fragmented.
no, please. if we are not consistent, orthogonal and extensible, we
are nothing. performance comes last until its proved to be a
disaster. if speed matters, make a local setup
> it's not at all clear where to put the files that are now located on
> ctan (following the e-math conventions rooted in /ams) under
> tex-archive/fonts/ams/author-info/sty-files
> these are the author packages referred to above. they are of interest
> to ams authors, but this is probably less than 10% of the regular users
> of ctan, and probably even less than that of users of a cd. maybe they
a new package called amsauthor, i would guess, distinct from amsuser
(as it were)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 10:31:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 20 Jul 1994 11:28:01 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
Message-ID: <774718081.160089.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
thanks, sebastian, both for comments and offer of assistance --
it shall be passed on to the management. <smile>
i think i don't really understand how the ...//... really works
in a path specification, and i will ask our local unix whiz to
explain it to me.
regarding the ams author-info material, no, this isn't one
"package". it's a growing collection of styles, with some
documentation, each file directed to authors of a particular
publication. each file could be considered a "mini-package",
but it would be excessive to put them all into separate
directories. what i'm saying is that these aren't just
documentation, but real styles (perhaps two for one pub --
amstex and amslatex -- or just one of those in some cases).
separating the documentation into another area would be
criminal in my opinion; at least, it would mean that we
would completely lose control over them, and that's just
not an attractive option. so i'd appreciate some good
suggestions.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 10:39:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 20 Jul 1994 08:33:30 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407201533.IAA06402@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: extended subdir searching
There are always dodges around extended searching available in
a kpathsea environment. I use them on slow machines but not
on fast ones. With the resources of Unix it is possible
either to use ls-R databases, or symbolic links to a flat
directory at the head of the environment path.
Undoubtedly equivalent dodges can be worked out for the
other operating systems.
So I think we are safe against the imputation of forcing people
to use what may for them be a slow algorithm. Even when you
are forced by sluggish performance to use one of the dodges,
it is nice to have kpathsea searching as a backup, so that
an unexpected call out to an oddball font will succeed despite
its absence from the ls-R database or the flat directory.
If that is made clear, extended subdir searching should
look pretty good to almost everybody.
On a fast machine, it is WONDERFUL.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 12:47:15 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Wed, 20 Jul 1994 16:55:17 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:027010:940720155525"@cl.cam.ac.uk>
>
> i think i don't really understand how the ...//... really works
> in a path specification, and i will ask our local unix whiz to
> explain it to me.
its not Unixy per se, its just web2c/ maybe i have it wrong. but to me
fonts//tfm means that only files in any level of subdirectory under
fonts called tfm will be considered. specifically, fonts/foo/pk and
fonts/foo/mf will *not* be looked at
> regarding the ams author-info material, no, this isn't one
> "package". it's a growing collection of styles, with some
> documentation, each file directed to authors of a particular
> publication. each file could be considered a "mini-package",
> but it would be excessive to put them all into separate
> directories. what i'm saying is that these aren't just
i dont think its excessive. i'd do just that.
> separating the documentation into another area would be
> criminal in my opinion; at least, it would mean that we
> would completely lose control over them, and that's just
> not an attractive option. so i'd appreciate some good
i dont think i really sympathize. one gets the ams stuff from an
archive, complete with documentation, and installs it into a TDS
structure, where the tfm files fly one way, the .sty files another,
and the doc a third. since everyone understands where to look for
what, i am not sure i see who loses or why the AMS loses
control. no-one is suggesting that we distribute the stuff in bits
separately.
put it another way, whoever kept the AMS structure in production? so
how do you tell people now to store the docs?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 14:55:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 20 Jul 1994 14:34:37 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
Message-ID: <774729277.840089.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i dont think i really sympathize. one gets the ams stuff from an
archive, complete with documentation, and installs it into a TDS
structure ...
we have structured our documentation (when it's relevant) to start
with where the files are to be found on the archive. where people
put them after they've retrieved them is, to some extent, up to
them. however, when we refer to a particular file, we have up to
now felt confident that we could say "it's the file named xxx that
you got from yyy in the archive." now that the files will be
distributed *as a tds* we can no longer use that approach -- a
person who got *only* the tds will have no idea at all what we
are talking about. and in fact, it won't necessarily be obvious
for some of these files that there *is* documentation. of course
we can put that information into the file header, but do you
really believe that people read that???
i think i'm inclined to believe that maybe these author-info
files just shouldn't even go onto a tds cd. you don't have to
sit on the other end of a telephone and answer stupid questions
from irate callers who didn't read the documentation and don't
believe anything you say because your title isn't at least
"vice president". (sorry -- i've been having a bad day. but
it's true that more than once i've had to say firmly to a
caller, "i can't help you; you won't let me. i'm transferring
you to my manager." and i'm truly grateful for the few people
who bother to say "thank you". i'm sure pierre knows what
i'm talking about.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 15:26:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Wed, 20 Jul 1994 21:12:47 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:077940:940720201254"@cl.cam.ac.uk>
who said the AMs had to *distribute* as a TDS? i was perhaps assuming
you'd supply as whatever you like, with instructions/scripts to make a
working TDS on the spot from what the punter receives.
this is important, i think. we do need to get clear in our heads what
*is* the best approach to a real-life situation like this
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 15:26:42 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 20 Jul 1994 16:21:57 -0400
Message-ID: <199407202021.QAA12860@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: new version of document
Reply-To: TWG-TDS@SHSU.edu
is up on jasper.ora.com:/private/twg-tds/*
it's rough, but I'm going to be mostly unavailable until monday,
so I doubt I'll get more time to work on it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Jul 1994 16:30:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 20 Jul 1994 17:15:53 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
Message-ID: <774738953.210089.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
who said the AMs had to *distribute* as a TDS? i was perhaps assuming
you'd supply as whatever you like, with instructions/scripts to make a
working TDS on the spot from what the punter receives.
this is important, i think. we do need to get clear in our heads what
*is* the best approach to a real-life situation like this
no, of course the ams doesn't *have* to distribute as a tds -- but
if ams stuff is on a tds-organized cd that is expected to get wide
distribution, then that is, in effect, a distribution. therefore,
we have to be prepared to answer questions from people who get it
and are trying to use our stuff that's on it.
versteh? i really don't think i'm out of line here ...
we're at a bit of a disadvantage, in that we don't actually use
the same system that most people who call us are using; in fact,
many times we don't even have that system available for testing.
so i don't really know how we can be sure that any scripts we may
write will necessarily work somewhere else. it would be wonderful,
of course, to be able to support all possible setups, but i don't
see how ...
and yes, i agree -- this is a real-life situation, and i'd love
to find an approach that doesn't cost us a lot of time, outside
of a necessary one-time conversion and revision of documentation.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 04:05:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 94 09:58:24 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407210858.AA13326@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Sebastian writes (to barabara)
> who said the AMs had to *distribute* as a TDS? i was perhaps
> assuming ....
I think it is the old CD problem again. And this does not only affect
the AMS of course.
LaTeX currently comes with conditions saying it should be distributed
with the documentation. We already have an `official' request (from
someone who shall remain nameless but who's initials contain the
letters K and B) that this clause be waived for his TDS-like
distribution.
We havent `officially' responded to this person yet because of the
difficulties of ensuring that
a) the end user gets the documentation if it is distributed separately
and
b) that the documentation still makes sense once all the files have
been moved around.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 04:05:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 1994 05:00:36 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407210900.AA06127@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
For the AMS packages on CTAN and e-math, how about a distribution that
looks like this:
amstex[-version]/README
amstex[-version]/install.sh*
amstex[-version]/tex/
amstex[-version]/tex/amstex/
amstex[-version]/tex/amstex/amstex.tex
amstex[-version]/tex/amstex/amsppt.sty
...
amstex[-version]/doc/
amstex[-version]/doc/amstex/
amstex[-version]/doc/amstex/amsinst.tex
amstex[-version]/doc/amstex/amsguide.tex
...
(The [-version] is just my own personal bias, never mind, its presence
or absence has nothing to do with the issue at hand.)
The README says to look in doc/amstex for the documentation, and
tex/amstex for the sources, so people getting the distribution are not
blind.
I'll include a sample install.sh (off the top of my head) below.
The point is, the documentation and the source are always together;
they're not subdirectories of the same directory, true, but they're together.
What's the alternative?
To have texmf/amstex/{doc,tex}/... is not a viable thing to standardize
on, since there is no existing implementation (so far as I know) that
uses it. We already went through that at great length, as Sebastian says.
If you're worried that people will go and copy texmf/tex/amstex
somewhere without taking texmf/doc/amstex, then I submit to you that
this is no different than the situation now. In fact, it's much better,
because there's a documented place in the tree for the documentation.
I can't speak for anyone else, but I personally always left package
documentation lying around in the source directory, since there was no
particular place to install it.
By the way, all of this is exactly the same as for any other package. In
fact, amstex is simpler, since it has no fonts :-)
Given the existence of a TDS, it should in fact be feasible to write
*one* install script that does (almost) all the job for *all* conforming
packages...
#!/bin/sh
# install.sh -- install a package from its distribution directory to the
# production texmf tree.
if test $# -ne 1; then
echo "Usage: $0 <texmf root>."
exit 1
fi
$texmf=$1 # root of the tree is arg to script
# possibly want to move a previous installation aside
echo "Copying TeX input files from `pwd`/tex to $texmf/tex..."
cp -r tex $texmf
echo "Copying documentation from `pwd`/tex to $texmf/tex..."
cp -r doc $texmf
<end of script>
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 05:34:30 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407211031.AA18514@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Wed, 20 Jul 94 10:37:59 -0400
From: bob@microprograms.com
Others have made very good comments on the first draft and have
corrected the errors I have marked on my copy, so I will not repeat them.
I would like some editorial work done on 1 Introduction
Yes, perhaps I am a little sensitive as a commericial implementor, but
I feel others may agree.
Paragraph one ends with "Another reason is that it's free." While free
pd versions are available, how would a person who just purchased a
commercial version feel after reading "...it's free"? Commercial
implementations are not acknowledged until paragraph 3, then as a
comment directed to those implementors.
The second paragraph begins "Because it is cheap..." Cheap has a
negative conotation. Better wordsmiths than I spend hours agnozing over
the correct choice of words in situations like this.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 07:39:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 1994 08:34:26 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407211234.IAA15414@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <199407061402.KAA27692@jasper.ora.com> <9407211031.AA18514@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 20 July 1994 at 10:37:59, bob@microprograms.com wrote:
> Paragraph one ends with "Another reason is that it's free." While free
> pd versions are available, how would a person who just purchased a
> commercial version feel after reading "...it's free"? Commercial
> implementations are not acknowledged until paragraph 3, then as a
> comment directed to those implementors.
>
> The second paragraph begins "Because it is cheap..." Cheap has a
> negative conotation. Better wordsmiths than I spend hours agnozing over
> the correct choice of words in situations like this.
Very good points. If you know a better wordsmith... ;-) In the meantime,
I'll bang on it again. I find introductions so blasted hard to write...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 07:57:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 21 Jul 1994 08:53:08 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
Message-ID: <774795188.143759.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
thanks, karl.
this looks reasonable.
but ...
The point is, the documentation and the source are always together;
they're not subdirectories of the same directory, true, but they're
together.
what i see here is that they *are* subdirectories of the same
directory, just another level down. am i missing something?
...
amstex[-version]/tex/amstex/amstex.tex
...
amstex[-version]/doc/amstex/amsguide.tex
...
(i too find the version useful, so although it may be a nuisance,
it's worth considering.)
To have texmf/amstex/{doc,tex}/... is not a viable thing to standardize
on, ...
but it looks to me like that's what you've got here. ???
or -- are you talking here about the archive arrangement, to be
installed in separate places on a tds? if that, *then* where
does the README go for later reference? doesn't necessarily
lose its utility just because the rest of the package has been
installed, although the information could probably be included
also in the doc material.
By the way, all of this is exactly the same as for any other package. In
fact, amstex is simpler, since it has no fonts :-)
amstex may *have* no fonts, but it requires quite a few.
however, that can be explained in the README; if people choose
not to read it, nothing we can do about that.
maybe something could be put into an install.sh to check for
the presence of one or two of the obvious ones, and scream
if they're not found ...
we'll take a closer look at all of this as soon as we've finished
office moving, or depending how long that takes, i'll make sure
ralph youngen has a copy to take to the tug meeting to discuss.
(i'll be leaving next thursday, for the board meeting. ralph
and mike downes will be going either saturday or sunday.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 08:10:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 21 Jul 1994 09:07:57 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
To: TWG-TDS@SHSU.edu
Message-ID: <774796077.453759.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
norm -- you'll be at the tug meeting, no?
i will try to find time to help you wordsmith.
i also have a lot of proofreading experience ...
i have another grumble about the intro. while it's true that
"hundreds, if not thousands" of people have been the sources
of suggestions, bug reports, etc., etc., to say that tex was
*developed* by them is unfair, if not literally untrue, since
lots of pieces go into a *system*. but donald knuth is not
mentioned even once in the document, and if you're going to
say anything at all about the concept or development, that's
an egregious omission.
for an alternative to "it's free", how about
another reason is that a person can decide how to obtain a
working implementation: spend some money to get a copy that
someone else has put together (and will support), or obtain
the sources (which are free) and spend some time implementing
it for the hardware and operating system at hand.
doesn't have quite the impact, but does set out the choices,
which are real. (i think most of us have been in the "spend
the time" category at one time or another.) and could still
use some wordsmithing; hack away.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 09:42:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 1994 10:42:11 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407211442.KAA19746@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <199407210900.AA06127@terminus.cs.umb.edu> <774795188.143759.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 21 July 1994 at 08:53:08, BNB@math.ams.org wrote:
> what i see here is that they *are* subdirectories of the same
> directory, just another level down. am i missing something?
> ...
> amstex[-version]/tex/amstex/amstex.tex
> ...
> amstex[-version]/doc/amstex/amsguide.tex
> ...
In the distribution, yes, but they would be installed under the TDS in
/texmf/tex/amstex/...
/texmf/doc/amstex/...
So they're only in the same directory in the sense that *everything* is
in the /texmf directory ;-)
I understand the concern about documentation getting lost, but I actually
think we'll be *increasing* the accesability of documentation. It's all
going to be under /texmf/doc, so that'll be the place that everyone learns
to look (in the sense that users every look for documentation ;-)
> (i too find the version useful, so although it may be a nuisance,
> it's worth considering.)
For a distribution hierarchy, I think it's great!
> To have texmf/amstex/{doc,tex}/... is not a viable thing to standardize
> on, ...
> but it looks to me like that's what you've got here. ???
Nope, look again, it's doc/amstex, and tex/amstex not
amstex/tex and amstex/doc!
> or -- are you talking here about the archive arrangement, to be
> installed in separate places on a tds? if that, *then* where
Ah, yes, that's it!
> does the README go for later reference? doesn't necessarily
> lose its utility just because the rest of the package has been
> installed, although the information could probably be included
> also in the doc material.
texmf/doc/amstex/README ...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 09:43:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 1994 10:43:45 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407211443.KAA19820@ruby.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
References: <199407211234.IAA15414@ruby.ora.com> <774796077.453759.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 21 July 1994 at 09:07:57, BNB@math.ams.org wrote:
> norm -- you'll be at the tug meeting, no?
Yep. I'll be arriving Saturday afternoon (July 30)
> i will try to find time to help you wordsmith.
> i also have a lot of proofreading experience ...
Thanks!
>
> i have another grumble about the intro. while it's true that
> "hundreds, if not thousands" of people have been the sources
> of suggestions, bug reports, etc., etc., to say that tex was
> *developed* by them is unfair, if not literally untrue, since
> lots of pieces go into a *system*. but donald knuth is not
> mentioned even once in the document, and if you're going to
> say anything at all about the concept or development, that's
> an egregious omission.
true. next draft ;-)
> for an alternative to "it's free", how about
> another reason is that a person can decide how to obtain a
> working implementation: spend some money to get a copy that
> someone else has put together (and will support), or obtain
> the sources (which are free) and spend some time implementing
> it for the hardware and operating system at hand.
> doesn't have quite the impact, but does set out the choices,
> which are real. (i think most of us have been in the "spend
> the time" category at one time or another.) and could still
> use some wordsmithing; hack away.
thanks. see what you think of what I've done so far.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Jul 1994 09:56:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Jul 1994 10:56:38 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199407211456.KAA20513@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: YAV: yet another version...
Reply-To: TWG-TDS@SHSU.edu
in /private/twg-tds on jasper.ora.com
I fixed up the intro a bit (it still needs more work wrt bb's comments)
and added a paragraph about efficient implementation of subdir searching.
Comments?
================================================================================
From owner-twg-tds@shsu.edu Fri, 22 Jul 1994 06:59:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407221151.AA05447@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Spec: First Draft
Date: Fri, 22 Jul 94 07:49:22 -0400
From: bob@microprograms.com
Barbara proposed:
for an alternative to "it's free", how about
another reason is that a person can decide how to obtain a
working implementation: spend some money to get a copy that
someone else has put together (and will support), or obtain
the sources (which are free) and spend some time implementing
it for the hardware and operating system at hand.
Good start on the rework and is an honest statement of the situation
BTW, I agree with her observation in paragraph preceding the one cited above.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Fri, 22 Jul 1994 06:59:49 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407221151.AA05465@uu3.psi.com>
To: twg-tds@shsu.edu
Subject: A radical proposal
Date: Fri, 22 Jul 94 07:49:08 -0400
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
Hmmm. From the sidelines reading the recent discussions, I sense a
serious problem. We are looking for a workable directory structure that
could (should?) be used on systems to efficiently run TeX and find
files. We are being confronted by the somewhat different requirements
of distributors (a broad term to encompass all who produce packages,
e.g. the AMS, the LaTeX 3 committee.
Consider this idea: Draft the *best* directory structure for operations
and system administration. Include an "as-distributed" (yes, I know,
not a legal name, it is a conceptual name at this point) directory. A
distributor will be encouraged to put all their files for a specific
package under a directory that would be copied as a sub-directory to
this distribution point. They would also be encouraged to provide
scripts/batch files to install the individual files of the package to
the correct final "home" within the TDS. Then, as distributed, the
documentation would be with the package (a good thing). It would then
be the administrator's decision whether or not to leave the master
package in "as-distributed" or delete it.
A producer of a CD-ROM could elect to use only the installed files
since the CD-ROM could be considered a working directory or include both.
Bob
PS I hope I have communicated clearly. It is early and last night was long.
================================================================================
From owner-twg-tds@shsu.edu Fri, 22 Jul 1994 07:16:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 22 Jul 1994 08:16:18 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: A radical proposal
To: TWG-TDS@SHSU.edu
Message-ID: <774879378.117259.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re various discussions about segmenting macro/font/"operational"
files from documentation, but in archives, etc., to have them
packaged together, i'm pretty sure we can live with that, but
bob says
A producer of a CD-ROM could elect to use only the installed files
since the CD-ROM could be considered a working directory or include both.
if the "installed files" *do* contain the documentation (i believe
i remember someone suggesting that it would be considered optional
to omit or remove it), that's okay, but if the documentation is
missing, bad news.
just want to be excruciatingly clear on this. (bob said he had a
long last night; i did too -- finally finished packing at 00:27,
three minutes before the second shift operator and the guard bailed
out.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 22 Jul 1994 08:31:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 22 Jul 94 14:31:06 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407221331.AA14661@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: A radical proposal
> if the "installed files" *do* contain the documentation (i believe
> i remember someone suggesting that it would be considered optional
> to omit or remove it), that's okay, but if the documentation is
> missing, bad news.
Yes this (as we are discovering with the LaTeX distribution) requires
some care in how copying restrictions are drafted.
We (and presumably any other `package' authors) want to ensure that
the documentation is distributed with the system, but `with' has to be
drafted in such a way that
a) CD distributions can `separate' the texinputs and documentation
into their `TDS positions',
b) harder, if the documentation and input files are put into separate
archive files
(say to pick a random example, lib.tar.gz and src.tar.gz:-)
this should be allowed as long as the two archives are distributed
`together'.
I think that drafting such conditions will be easier once the TDS is
official, as then we will be able to explictly say that either latex
(in our case) must be distributed `as is' or alternatively it may be
distributed `as part of a TDS based structure' with input and
documentation files separated into the relevant parts of the TDS.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 26 Jul 1994 10:59:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407261600.AA20594@spice.iti.informatik.th-darmstadt.de>
Subject: Re: YAV: yet another version...
To: TWG-TDS@SHSU.edu
Date: Tue, 26 Jul 1994 18:00:18 +0100 (MESZ)
Content-Type: text
You wrote:
>
> in /private/twg-tds on jasper.ora.com
>
> I fixed up the intro a bit (it still needs more work wrt bb's comments)
> and added a paragraph about efficient implementation of subdir searching.
> Comments?
Later. :-) May you add the DTD as well?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 27 Jul 1994 06:31:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407271132.AA11657@spice.iti.informatik.th-darmstadt.de>
Subject: Re: YAV: yet another version...
To: schrod@spice.iti.informatik.th-darmstadt.de (schrod)
Date: Wed, 27 Jul 1994 13:32:04 +0100 (MESZ)
Content-Type: text
I wrote:
>
> You wrote:
> >
> > in /private/twg-tds on jasper.ora.com
> >
> > I fixed up the intro a bit (it still needs more work wrt bb's comments)
> > and added a paragraph about efficient implementation of subdir searching.
> > Comments?
>
> Later. :-)
Well, I know I'm really late (but I was ill for 5 days and had to
catch up with the discussion first). So:
How many on this mailing list are still here anyhow? Does it make
sense to post comments now? Shall I bring them (on paper) to
St.Barbara?
--
Joachim
================================================================================
From owner-twg-tds@shsu.edu Wed, 27 Jul 1994 07:04:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 27 Jul 1994 08:02:36 -0400
Message-ID: <199407271202.IAA25455@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: YAV: yet another version...
References: <no.id> <9407271132.AA11657@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 27 July 1994 at 13:32:04, Joachim Schrod wrote:
>
> Well, I know I'm really late (but I was ill for 5 days and had to
> catch up with the discussion first). So:
Hope you're feeling better ;-)
> How many on this mailing list are still here anyhow? Does it make
> sense to post comments now? Shall I bring them (on paper) to
> St.Barbara?
Sure, post away. My plan is to hack one more version of the TDS document
and send it to several developers today (EM, TR, OzTeX, maybe fax it to
PCTeX and Kinch) then bring it to TUG for more general comments.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 28 Jul 1994 15:18:09 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 28 Jul 1994 16:16:02 -0400
Message-ID: <199407282016.QAA09025@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New version
Reply-To: TWG-TDS@SHSU.edu
Another new version on jasper.ora.com:/private/twg-tds
Unless there are big problems, I'll mail this to developers tomorrow.
TUG organizers: should I make the copies of the TDS or can we make
them in SB?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 28 Jul 1994 15:27:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407282028.AA18133@spice.iti.informatik.th-darmstadt.de>
Subject: Re: New version
To: TWG-TDS@SHSU.edu
Date: Thu, 28 Jul 1994 22:28:11 +0100 (MESZ)
Content-Type: text
You wrote:
>
> Another new version on jasper.ora.com:/private/twg-tds
>
> Unless there are big problems, I'll mail this to developers tomorrow.
<ARGHH!>
I just finished my comments. Well, I'll send them anyhow. Three mails
will follow:
(1) One with structural comments.
(2) One with content problems.
(3) One with typos etc.
See you Sunday in St.Barbara (I'm leaving now -- 22:30 and just half
an hour ago I finished the slides for my presentation. :-) :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 28 Jul 1994 15:28:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407282029.AA18398@spice.iti.informatik.th-darmstadt.de>
Subject: Re: YAV (structural comments)
To: TWG-TDS@SHSU.edu
Date: Thu, 28 Jul 1994 22:29:01 +0100 (MESZ)
Content-Type: text
Structural Comments
The whole document is written in an essay style, with a structure in
each section that underlines this _descriptive_ form. While this is
very good if one wants to have an article in TUGboat, I think we also
need a document which is more _prescriptive_, which is more standard-
or recommendation-like. Am I clear enough? A presentation that brings
the facts (i.e., our rules) first; explanations for the doubters may
come later.
This would also emphasize the points more that were written as a
rationale. You'll remember the comments by barbara et.al.? They did
mention things which were actually in the report. If these things
would have been introduced by a run-in header ``Rationale'' they might
have taken notice earlier.
I would suggest to achieve this requirement by using some additional
markup tags to structure the different topics further. Most of them
already consist of a description of the facts, some notes, and a
rationale. Arranging them in this sequence would make the structure
more evident. One can decide later how (or even if) one wants to
distinguish them by means of layout.
If I may assume that there exist some syntactic entity `text' that
encapsulates text in section-like structures, I would propose elements
as follows:
<!entity % note "(note|imp-note)"
-- general or implementation specific notes -->
<!element fact - - "%text;,%note;*,rationale?">
<!element rationale - - "%text;">
<!element %note; - - "%text;">
To emphasize why I suggest this sequence, consider the following
example. Arguing first and naming the resulting facts is what I called
essayistic above (no depreciation intented), naming facts and giving a
rationale afterwards seems more appropriate to a standard.
--------
<sect2><title>Subdirectory Searching</>
<fact>
<para>
[Explanation what subdirectory is and what it's for]
</para>
<para>
To avoid different implementations having different syntaxes for...
</para>
<para>
Implementations may also choose to implement single-level subdirectory...
</para>
<para>
The implementation must do a breadth-first search of the subdirectories:...
</para>
</fact>
<note>
<para>
This feature is already supported by the <emphasis>Web2C</> ...
</para>
</note>
<imp-note>
<para>
This TWG recognizes that subdirectory searching places an extra burden...
</para>
</imp-note>
<note>
<para>
It should be clear that subdirectory searching does not prevent...
</para>
</note>
<rationale>
<para>
Many &TeX; installations...
</para>
<para>
This monolithic arrangement makes maintenance of &TeX; software ...
</para>
<para>
Given the need to have each package and typeface in a separate...
</para>
</rationale>
----------------
Btw, barbara has a very nice paper on this topic, an ISO memo about
the editorial of standards... :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 28 Jul 1994 15:29:09 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407282029.AA21997@spice.iti.informatik.th-darmstadt.de>
Subject: Re: YAV (content problems)
To: TWG-TDS@SHSU.edu
Date: Thu, 28 Jul 1994 22:29:38 +0100 (MESZ)
Content-Type: text
Contents Comments
In the following, I will point out text pieces that I consider wrong
or harmful or improvable. I do not always have good suggestions for
improvement, but I would like to mention them nevertheless.
Each line with a comment starts with `>>> '.
<sect1><title>Introduction</>
...
The purpose of this document is to describe a standard directory
structure for macros, fonts,
and other implementation-independent &TeX; files.
^^^^
>>> But we do also recommend directories for FMTs etc!
>>> Actually, I like this recommendation much and would prefer to drop
>>> the ``implementation-independency'' completely.
...
This document is intended ... to a self-contained macro package.
^^^^^^^^^^^^^
>>> We should point out here that we do *not* mean a LaTeX2e package!
>>> I suggested to use the term `bundle' in another context.
>>>
>>> That's important -- even barbara mixed that up in one of her
>>> responses.
<sect2><title>Subdirectory Searching</>
...
This TWG recognizes that subdirectory searching places an extra burden
...
>>> This whole implementation-specific paragraph would win with a
>>> general, abstract description of the `kpathsea' functionality ---
>>> either as an add-on, or instead. I.e., some text that is not Unix
>>> centric, but speaks of directory hierarchies, uses POSIX
>>> terminology, etc. (Karl? As you see it matters that you're still
>>> here... :-) I'm willing to help drafting a text after August, 18;
>>> when we're back from our US trip.
<sect2><title>Constraints</>
...
One use of this proposed standard will be on mountable media
...
The most troubling limitation is monocase names because &LaTeX;
uses mixed case names for font descriptor files. However, this
problem is surmountable. In particular, note that MS-DOS, OS/2,
Windows-NT, and Macintosh file systems are not case-sensitive,
therefore a request for <filename>OT1cmr.fd</> can always be
satisfied by <filename>ot1cmr.fd</>.
>>> To be honest, I don't understand this paragraph. I do understand
>>> the limitation of ISO 9660 (at least, I think so). But I do not
>>> see what these sentences have to do with the problems at hand. (I
>>> will ask sebastian in St.Barbara -- currently I just want to
>>> mention that I have problems.)
<sect1><title>Rooting the Tree</>
...
The <filename role=dir>texmf</> root <emphasis>should not</> be placed
^^^
>>> shall (standard speech :-)
<sect2><title>Top Level Directories</>
...
<varlistentry><term>man</>
<listitem><para>for manual pages (UNIX-style documentation).</para>
>>> how about moving this directory below doc; i.e., doc/man/?
<varlistentry><term>dvips</>
<listitem><para>for <filename>dvips</> configuration files.</para>
>>> I suggest to provide a more general formulation and some
>>> examples. There are several other utilities that form the TeX
>>> author tool box, like makeindex, tgrind, etc, which may need own
>>> configuration files. It's not understandable why one of them
>>> (dvips -- actually two, with BibTeX) get special mentioning while
>>> the others are not mentioned at all.
>>>
>>> I suggest to use something along
>>>
>>> <varlistentry><term><emphasis>utility</></term>
>>> <listitem><para> configuration files for <emphasis>utility</>.
>>> Examples of <emphasis>utility</> are <filename>dvips</>,
>>> <filename>makeindex</>, and <filename>tgrind</>.
<sect1><title>Macros</>
...
<varlistentry><term>format</>
...
For some formats, it may be natural to search more than one format
directory. For example, both the <filename role=dir>latex</> and
<filename role=dir>plain</>
directories may be searched when using &LaTeX;. In cases like this,
packages should be installed at the end of the natural search order.
>>> This recommendation isn't the very best: consider that large
>>> bundles like eplain, edsmac, etc, must be scanned. spqr have given
>>> lots of good reasons in the email discussions already -- I fully
>>> agree with him.
For example, a package usable under &LaTeX;, &LaTeX;209, and Plain &TeX;
should be stored in the <filename role=dir>plain</> tree.
>>> Such a package is likely to be usable in all formats with plain
>>> catcodes. We need a special category for this -> cf.spqr
<varlistentry><term>package</>
>>> Here again, we have a problem with the LaTeX2e term `package'
>>> which means something else
Packages that consist of only a single file,
or a small number of independent files,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> This should be omitted!
<sect2><title>Is There a Better Way?</title>
...
It is closer in spirit to the arrangements that are actually in use
already. Several members of the committee already have arrangements that are
similar to the &tds; and the CTAN archives have a similar arrangement.
>>> We should give a *reason* here besides mere existance: For example,
>>>
>>> I.e., it has been shown that such an arrangement is usable under
>>> production circumstances.
<sect3><title>Valid Font Bitmaps</title>
...
name. There is always the possibility that DVI drivers may find this
information useful as well
>>> Honestly -- I doubt that...
provide the required information. If you have been using a local modes
file derived from Karl Berry's <filename>modes.mf</> distribution, the
required information is <emphasis>already</> in all of your <filename>PK</>
files.
>>> The usage of modes.mf should be recommended in stronger words.
<sect1><title>&BibTeX;</>
...
&BibTeX; databases should be stored in ...
^
>>> of common interest
>>> Bib files (data bases) that accompany a document belong there, not
>>> at a general place! Personal data bases shouldn't be publically
>>> stored, either!
<sect1><title>Documentation</>
...
<para>
There are four special cases within this scheme: ...
</para>
>>> There lacks a rationale for this section. A rough sketch like the
>>> following could be added:
>>>
>>> It was discussed to spread the documentation files, ie, place them
>>> together with the package. But it seemed to be important that
>>> users find documentation in one place --- for humans, searching
>>> directory trees is a nuisance. And since developers and
>>> distributors bemoan all the time that users don't read their
>>> documentation, it is important that no additional barriers are
>>> introduced.
<sect1 id=otherdirs><title>Other Directories</>
...
(this greatly simplifies administration if the &TeX; tree is maintained
by someone other than the system administrator).
>>> Moreover, it allows to mount a `TeX server' via NFS, even in a
>>> heterogenous network environment.
<para>
In order to ease the transition from existing arrangements to the &tds;,
these extensions are allowed. However, commercial vendors and
system distributors are encouraged to keep system dependent files separate
from the &tds;. This facilitates the installation of several &TeX;
implementations on the same system without either duplication of the
&tds; or collision between systems.
</para>
>>> I suggest to leave this paragraph out. The arguments given are not
>>> contradictionary, I think, they complement each other!
<sect1><title>Package Distribution</>
...
martian-1.0/tex/plain/martian/marthyph.tex
>>> hyphen? this should be `hyphen' (or `initex') then!
<sect1><title>Example</>
...
>>> several directory names in the following example were not introduced:
>>> base, local
>>>
>>> Or do I miss something?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 28 Jul 1994 15:29:31 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9407282030.AA18169@spice.iti.informatik.th-darmstadt.de>
Subject: Re: YAV (typos & misc)
To: TWG-TDS@SHSU.edu
Date: Thu, 28 Jul 1994 22:30:17 +0100 (MESZ)
Content-Type: text
Typos & Miscellaneous
In the following, I will comment on typos and make some formatting
suggestions.
<corpauthor>The &TeX; Working Group on a &TeX; Directory Structure</>
>>> this should read: `TUG Technical Working Group'
<sect2><title>Subdirectory Searching</>
...
This feature is already supported by the <emphasis>Web2C</>
^^^
>>> web2C
<sect2><title>Constraints</>
...
satisfied by <filename>ot1cmr.fd</>. In addition, UNIX file systems
^^^
>>> New Paragraph!
<sect2><title>Top Level Directories</>
...
<variablelist>
<varlistentry><term>tex</>
<listitem><para>for the input files used by &TeX;.</para>
</listitem></varlistentry>
<varlistentry><term>fonts</>
<listitem><para>for the font-related files.</para>
</listitem></varlistentry>
<Varlistentry><term>bibtex</>
<listitem><para>for files used by &BibTeX;.</para>
</listitem></varlistentry>
<varlistentry><term>doc</>
<listitem><para>for <emphasis>user</> documentation.</para>
</listitem></varlistentry>
</variablelist>
>>> The typography of this list is unsatisfying
<varlistentry><term>bin/system</>
>>> system is a variable term and should be formatted likewise
<varlistentry><term>ini/system</>
>>> likewise
<sect1><title>Macros</>
...
<varlistentry><term>format</>
<listitem><para>
is the name of the &TeX; format file that uses these
files. <filename role=dir>plain</>, <filename role=dir>latex209</>,
<filename role=dir>latex</>, and <filename role=dir>musictex</> are
examples of <emphasis>formats</>.
^^^
>>> format</>.
For example, a package usable under &LaTeX;, &LaTeX;209, and Plain &TeX;
>>> &LaTeX;2.09
Within this scheme, there are three special cases: the package name
<filename role=dir>hyphen</> is reserved for hyphenation files,
the package name <filename role=dir>misc</> is reserved for
“packages” that consist of a single file, and the
directory structure of the &LaTeX; contains one additional level.
^
>>> format
>>> For the following paragraphs, I suggest an item list or enumeration:
<para>
Hyphenation files are loaded by <command>initex</> and are used ...
</para>
<para>
For packages that consist of a single file, it seems pointless to nest ...
</para>
<para>
The &LaTeX; tree contains an extra level between <emphasis>format</> ...
</para>
<para>
<filename role=dir>...
</para>
<para>
while unsupported packages are stored in ...
</para>
<para>
<filename role=dir>...
</para>
>>> End of item/enumeration
<sect2><title>Is There a Better Way?</title>
...
<para>
The primary competition for this arrangement was a scheme which reversed
the order of these directories:
<emphasis>package</><filename role=dir>/</><emphasis>format</>.
This reversed arrangement has a strong appeal: it keeps all of the files
related to a particular format in a single place. The arrangement
^^^^^^
>>> package (as used everywhere else)
In the end, the ... <emphasis>package</>
^
>>> structure
won on several grounds:
>>> no paragraph following?
out in a wide, shallow tree. Fonts are no longer in a directory of
thier own (since they must be under the package). This spreading effect
^^^
>>> their
<sect1><title>Fonts</title>
...
is the name of the font vendor or ``<filename role=dir>public</>'' for
freely available fonts. <filename role=dir>adobe</>,
^^^
>>> distributable?
<listitem><para>Font sources (&MF; files, property lists, etc.)</para>
^^^
>>> Logo is wrong
<sect2><title>Font Bitmaps</>
...
example, the 300dpi bitmap of <filename>cmr10</> is named
>>> 300\,dpi
>>> (however you input that in your SGML system... :-)
resolution. For example, the same 300dpi bitmap would be named
>>> 300\,dpi
The &tds; recommends the use of <filename>dpi300/cmr10.pk</> for font
naming syntax as it is the
least-common-denominator-and-therefore-most-portable form. Extensions
>>> not so much hyphens!
>>>
>>> Btw, as a semi-mathematician: least-common-denominator is a
>>> horrible term. There does not exist such a thing.
supported and (b) no gain nor loss of functionality accrues from this
^^
>>> neither
<sect3><title>Valid Font Bitmaps</title>
...
Roman 10pt at 5-10 magnifications for 2-3 resolutions on many systems).
>>> 10\,pt 5--10 2--3
<para>
Within the &tds;, every <filename>PK</> file <emphasis>must</> contain
enough information to identify precisely how it was created; this
includes mode, base resolution, and magnification used to create the
font.
</para>
>>> Paragraph should be typeset narrowed or as <fact> (if my structure
>>> proposal is realized)
<sect1><title>&BibTeX;</>
>>> Logo is wrong!
<sect1><title>Documentation</>
...
<varlistentry><term>files</>
<listitem><para>
are determined by the package documenter. Below the level of the
^^^^^^^^^
>>> Btw, is this a real English word???
>>> I can use this in another circumstance...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 08:04:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 29 Jul 1994 09:02:45 -0400
Message-ID: <199407291302.JAA04670@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: YAV (structural comments)
References: <199407271202.IAA25455@jasper.ora.com> <9407282029.AA18398@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 28 July 1994 at 22:29:01, Joachim Schrod wrote:
> Structural Comments
In general, I agree with Joachim on this point. Unfortunately, I won't
have time to address it before TUG'94.
> Btw, barbara has a very nice paper on this topic, an ISO memo about
> the editorial of standards... :-)
Hmm...Barbara, any chance I could see that paper?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 08:51:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 29 Jul 1994 09:49:53 -0400
Message-ID: <199407291349.JAA06017@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: YAV (content problems)
References: <199407271202.IAA25455@jasper.ora.com> <9407282029.AA21997@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 28 July 1994 at 22:29:38, Joachim Schrod wrote:
> Contents Comments
No one else has commented on the draft (most of you may be out of touch
at the moment, actually, in SB). I'll incorporate the changes that I
think are ``obviously'' right and we can talk about the others over
the beverages of choice in SB.
> <sect1><title>Introduction</>
> ...
> The purpose of this document is to describe a standard directory
> structure for macros, fonts,
> and other implementation-independent &TeX; files.
> ^^^^
> >>> But we do also recommend directories for FMTs etc!
> >>> Actually, I like this recommendation much and would prefer to drop
> >>> the ``implementation-independency'' completely.
Maybe we should just drop the whole implementation-independent angle.
But I won't do that w/o some discussion first. Here's my compromise:
The purpose of this document is to describe a standard directory
structure for macros, fonts, and other implementation-independent &TeX;
files (as a matter of practicality, this document also suggests ways
to incorporate the rest of the &TeX; files into a single structure).
In the long run a consistent directory structure will make it
much easier for system administrators and users to install and maintain
&TeX;. ...
> This document is intended ... to a self-contained macro package.
> ^^^^^^^^^^^^^
> >>> We should point out here that we do *not* mean a LaTeX2e package!
> >>> I suggested to use the term `bundle' in another context.
> >>>
> >>> That's important -- even barbara mixed that up in one of her
> >>> responses.
This document is intended both for the &TeX; system administrator at a
site, and for people preparing &TeX; distributions—everything from a
complete runnable system to a simple macro or style file. It may also
help &TeX; users find their way around their local system.
> <sect2><title>Subdirectory Searching</>
> ...
> This TWG recognizes that subdirectory searching places an extra burden
> ...
>
> >>> This whole implementation-specific paragraph would win with a
> >>> general, abstract description of the `kpathsea' functionality ---
> >>> either as an add-on, or instead. I.e., some text that is not Unix
> >>> centric, but speaks of directory hierarchies, uses POSIX
> >>> terminology, etc. (Karl? As you see it matters that you're still
> >>> here... :-) I'm willing to help drafting a text after August, 18;
> >>> when we're back from our US trip.
Let's talk about how to improve this part.
> <sect2><title>Constraints</>
> ...
> One use of this proposed standard will be on mountable media
> ...
> The most troubling limitation is monocase names because &LaTeX;
> uses mixed case names for font descriptor files. However, this
> problem is surmountable. In particular, note that MS-DOS, OS/2,
> Windows-NT, and Macintosh file systems are not case-sensitive,
> therefore a request for <filename>OT1cmr.fd</> can always be
> satisfied by <filename>ot1cmr.fd</>.
>
> >>> To be honest, I don't understand this paragraph. I do understand
> >>> the limitation of ISO 9660 (at least, I think so). But I do not
> >>> see what these sentences have to do with the problems at hand. (I
> >>> will ask sebastian in St.Barbara -- currently I just want to
> >>> mention that I have problems.)
Another chat ;-)
> <sect1><title>Rooting the Tree</>
> ...
> The <filename role=dir>texmf</> root <emphasis>should not</> be placed
> ^^^
> >>> shall (standard speech :-)
Huh?
> <sect2><title>Top Level Directories</>
> ...
> <varlistentry><term>man</>
> <listitem><para>for manual pages (UNIX-style documentation).</para>
> >>> how about moving this directory below doc; i.e., doc/man/?
Ahhh, maybe. But man pages aren't really documentation in the normal sense
(you can't read them w/o formatting them) and most UNIX users are probably
used to having them at a top level.
> <varlistentry><term>dvips</>
> <listitem><para>for <filename>dvips</> configuration files.</para>
>
> >>> I suggest to provide a more general formulation and some
> >>> examples. There are several other utilities that form the TeX
> >>> author tool box, like makeindex, tgrind, etc, which may need own
> >>> configuration files. It's not understandable why one of them
> >>> (dvips -- actually two, with BibTeX) get special mentioning while
> >>> the others are not mentioned at all.
> >>>
> >>> I suggest to use something along
> >>>
> >>> <varlistentry><term><emphasis>utility</></term>
> >>> <listitem><para> configuration files for <emphasis>utility</>.
> >>> Examples of <emphasis>utility</> are <filename>dvips</>,
> >>> <filename>makeindex</>, and <filename>tgrind</>.
<varlistentry><term><replaceable>utility</></>
<listitem><para>for <replaceable>utility</> configuration files
(e.g. <filename>dvips</>, <filename>makeindx</>, etc.).</para>
</listitem></varlistentry>
> <sect1><title>Macros</>
> ...
> <varlistentry><term>format</>
> ...
> For some formats, it may be natural to search more than one format
> directory. For example, both the <filename role=dir>latex</> and
> <filename role=dir>plain</>
> directories may be searched when using &LaTeX;. In cases like this,
> packages should be installed at the end of the natural search order.
> >>> This recommendation isn't the very best: consider that large
> >>> bundles like eplain, edsmac, etc, must be scanned. spqr have given
> >>> lots of good reasons in the email discussions already -- I fully
> >>> agree with him.
>
> For example, a package usable under &LaTeX;, &LaTeX;209, and Plain &TeX;
> should be stored in the <filename role=dir>plain</> tree.
> >>> Such a package is likely to be usable in all formats with plain
> >>> catcodes. We need a special category for this -> cf.spqr
For example, a package usable under &LaTeX;, &LaTeX;209, and Plain &TeX;
should be stored in the <filename role=dir>plain</>
tree.<footnoteref linkend=foot3></footnoteref><footnote><para>
This recommendation is imperfect and may soon change (pending
more discussion within the TWG and comments from other readers).
Any format
that works with these packages probably works with any format that
uses the Plain &TeX; category codes. A format directory specifically
for these packages may be the best solution.</para>
</footnote>
> <varlistentry><term>package</>
> >>> Here again, we have a problem with the LaTeX2e term `package'
> >>> which means something else
>
> Packages that consist of only a single file,
> or a small number of independent files,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> This should be omitted!
You got it!
> <sect2><title>Is There a Better Way?</title>
> ...
> It is closer in spirit to the arrangements that are actually in use
> already. Several members of the committee already have arrangements that are
> similar to the &tds; and the CTAN archives have a similar arrangement.
> >>> We should give a *reason* here besides mere existance: For example,
> >>>
> >>> I.e., it has been shown that such an arrangement is usable under
> >>> production circumstances.
It is closer in spirit to the arrangements that are actually in use
already.
It has been demonstrated that this arrangement is usable in a production
environment whereas the alternative would be much more experimental.
In addition, several members of the TWG already have arrangements that are
similar to the &tds; and the CTAN archives have a similar arrangement.
> <sect3><title>Valid Font Bitmaps</title>
> ...
> name. There is always the possibility that DVI drivers may find this
> information useful as well
> >>> Honestly -- I doubt that...
% commented out!
> provide the required information. If you have been using a local modes
> file derived from Karl Berry's <filename>modes.mf</> distribution, the
> required information is <emphasis>already</> in all of your <filename>PK</>
> files.
> >>> The usage of modes.mf should be recommended in stronger words.
Hmm...
> <sect1><title>&BibTeX;</>
> ...
> &BibTeX; databases should be stored in ...
> ^
> >>> of common interest
> >>> Bib files (data bases) that accompany a document belong there, not
> >>> at a general place! Personal data bases shouldn't be publically
> >>> stored, either!
Yep.
> <sect1><title>Documentation</>
> ...
> <para>
> There are four special cases within this scheme: ...
> </para>
> >>> There lacks a rationale for this section. A rough sketch like the
> >>> following could be added:
> >>>
> >>> It was discussed to spread the documentation files, ie, place them
> >>> together with the package. But it seemed to be important that
> >>> users find documentation in one place --- for humans, searching
> >>> directory trees is a nuisance. And since developers and
> >>> distributors bemoan all the time that users don't read their
> >>> documentation, it is important that no additional barriers are
> >>> introduced.
</chapter>
<chapter><title>Documentation</>
<para>
Most packages come with some form of documentation. In order to make
it easier for users to find this documentation, the &tds; specifies that
documentation should be stored in a structure that parallels the fonts
and macros directories.
</para>
<para>
There was much discussion about where documentation files should
reside. One option was placing them in the same directory as the
packages themselves, but it seemed to be important that users find
documentation in one place—for humans, searching directory trees
is a nuisance. And since developers and distributors bemoan all the
time that users don't read their documentation, it is important that
no additional barriers are introduced. For these reasons, we decided
that a seperate but parallel structure for documentation would (1)
keep the documentation together and (2) make it easy for users to
find the particular documentation they were after.
</para>
<para>
<filename role=dir>texmf/doc/</><emphasis>package</><filename role=dir>/</><emphasis>files</>
</para>
> <sect1 id=otherdirs><title>Other Directories</>
> ...
> (this greatly simplifies administration if the &TeX; tree is maintained
> by someone other than the system administrator).
> >>> Moreover, it allows to mount a `TeX server' via NFS, even in a
> >>> heterogenous network environment.
Ok.
> <para>
> In order to ease the transition from existing arrangements to the &tds;,
> these extensions are allowed. However, commercial vendors and
> system distributors are encouraged to keep system dependent files separate
> from the &tds;. This facilitates the installation of several &TeX;
> implementations on the same system without either duplication of the
> &tds; or collision between systems.
> </para>
> >>> I suggest to leave this paragraph out. The arguments given are not
> >>> contradictionary, I think, they complement each other!
Commented out...
> <sect1><title>Package Distribution</>
> ...
> martian-1.0/tex/plain/martian/marthyph.tex
> >>> hyphen? this should be `hyphen' (or `initex') then!
Yeah, I already fixed that one ;-)
> <sect1><title>Example</>
> ...
> >>> several directory names in the following example were not introduced:
> >>> base, local
> >>>
> >>> Or do I miss something?
Yipes! That was out of date:
texmf/tex/plain
texmf/tex/plain/amstex
texmf/tex/latex/distrib/amslatex
texmf/tex/latex/distrib/babel
texmf/tex/latex/contrib/float
texmf/tex/latex/contrib/psnfss
texmf/fonts/public/cm
texmf/fonts/public/cm/src
texmf/fonts/public/cm/tfm
texmf/fonts/public/cm/pk
texmf/fonts/public/cm/pk/canoncx
texmf/fonts/public/cm/pk/canoncx/dpi300
texmf/fonts/ams/euler/...
texmf/fonts/ams/cyrillic/...
texmf/fonts/ams/cmextra/...
texmf/fonts/ams/symbol/...
texmf/doc/plain/...
texmf/doc/latex/...
texmf/doc/ams/...
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 09:04:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 29 Jul 1994 10:02:39 -0400
Message-ID: <199407291402.KAA06357@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: YAV (typos & misc)
References: <199407271202.IAA25455@jasper.ora.com> <9407282030.AA18169@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 28 July 1994 at 22:30:17, Joachim Schrod wrote:
> <corpauthor>The &TeX; Working Group on a &TeX; Directory Structure</>
> >>> this should read: `TUG Technical Working Group'
Oops!
> <sect2><title>Subdirectory Searching</>
> ...
> This feature is already supported by the <emphasis>Web2C</>
> ^^^
> >>> web2C
Karl, didn't you say you preferred 'Web2C'?
> <sect2><title>Constraints</>
> ...
> satisfied by <filename>ot1cmr.fd</>. In addition, UNIX file systems
> ^^^
> >>> New Paragraph!
Ok.
> <sect2><title>Top Level Directories</>
> ...
> <variablelist>
> <varlistentry><term>tex</>
> <listitem><para>for the input files used by &TeX;.</para>
> </listitem></varlistentry>
> <varlistentry><term>fonts</>
> <listitem><para>for the font-related files.</para>
> </listitem></varlistentry>
> <Varlistentry><term>bibtex</>
> <listitem><para>for files used by &BibTeX;.</para>
> </listitem></varlistentry>
> <varlistentry><term>doc</>
> <listitem><para>for <emphasis>user</> documentation.</para>
> </listitem></varlistentry>
> </variablelist>
> >>> The typography of this list is unsatisfying
Sigh. It is...but what should I do?
> <varlistentry><term>bin/system</>
> >>> system is a variable term and should be formatted likewise
Yep.
> <varlistentry><term>ini/system</>
> >>> likewise
Yep.
> <sect1><title>Macros</>
> ...
> <varlistentry><term>format</>
> <listitem><para>
> is the name of the &TeX; format file that uses these
> files. <filename role=dir>plain</>, <filename role=dir>latex209</>,
> <filename role=dir>latex</>, and <filename role=dir>musictex</> are
> examples of <emphasis>formats</>.
> ^^^
> >>> format</>.
Yep.
> For example, a package usable under &LaTeX;, &LaTeX;209, and Plain &TeX;
> >>> &LaTeX;2.09
Ok.
> Within this scheme, there are three special cases: the package name
> <filename role=dir>hyphen</> is reserved for hyphenation files,
> the package name <filename role=dir>misc</> is reserved for
> “packages” that consist of a single file, and the
> directory structure of the &LaTeX; contains one additional level.
> ^
> >>> format
Yep.
> >>> For the following paragraphs, I suggest an item list or enumeration:
> <para>
> Hyphenation files are loaded by <command>initex</> and are used ...
> </para>
I'll try it.
> <sect2><title>Is There a Better Way?</title>
> ...
> <para>
> The primary competition for this arrangement was a scheme which reversed
> the order of these directories:
> <emphasis>package</><filename role=dir>/</><emphasis>format</>.
> This reversed arrangement has a strong appeal: it keeps all of the files
> related to a particular format in a single place. The arrangement
> ^^^^^^
> >>> package (as used everywhere else)
Ok.
> In the end, the ... <emphasis>package</>
> ^
> >>> structure
> won on several grounds:
> >>> no paragraph following?
The DocBook DTD allows lists to appear in paragraphs...
> out in a wide, shallow tree. Fonts are no longer in a directory of
> thier own (since they must be under the package). This spreading effect
> ^^^
> >>> their
Yep.
> <sect1><title>Fonts</title>
> ...
> is the name of the font vendor or ``<filename role=dir>public</>'' for
> freely available fonts. <filename role=dir>adobe</>,
> ^^^
> >>> distributable?
Ok.
> <listitem><para>Font sources (&MF; files, property lists, etc.)</para>
> ^^^
> >>> Logo is wrong
Indeed it is. Hmm...
> <sect2><title>Font Bitmaps</>
> ...
> example, the 300dpi bitmap of <filename>cmr10</> is named
> >>> 300\,dpi
> >>> (however you input that in your SGML system... :-)
>
> resolution. For example, the same 300dpi bitmap would be named
> >>> 300\,dpi
Yeah, well, I'll have to think about that one ;-)
> The &tds; recommends the use of <filename>dpi300/cmr10.pk</> for font
> naming syntax as it is the
> least-common-denominator-and-therefore-most-portable form. Extensions
> >>> not so much hyphens!
Tell George! ;-) How's this:
least-common-denominator (and therefore most portable) form
> supported and (b) no gain nor loss of functionality accrues from this
> ^^
> >>> neither
Yep.
> <sect3><title>Valid Font Bitmaps</title>
> ...
> Roman 10pt at 5-10 magnifications for 2-3 resolutions on many systems).
> >>> 10\,pt 5--10 2--3
Yep.
> <para>
> Within the &tds;, every <filename>PK</> file <emphasis>must</> contain
> enough information to identify precisely how it was created; this
> includes mode, base resolution, and magnification used to create the
> font.
> </para>
> >>> Paragraph should be typeset narrowed or as <fact> (if my structure
> >>> proposal is realized)
Good point. I'm all for it, but not before TUG...
> <sect1><title>&BibTeX;</>
> >>> Logo is wrong!
True, true.
> <sect1><title>Documentation</>
> ...
> <varlistentry><term>files</>
> <listitem><para>
> are determined by the package documenter. Below the level of the
> ^^^^^^^^^
> >>> Btw, is this a real English word???
> >>> I can use this in another circumstance...
Nah, probably not. I like it, but I changed it to 'documentation author'
instead.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 09:07:55 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407291404.AA19419@uu3.psi.com>
To: TWG-TDS@SHSU.edu
CC: bob@microprograms.com
Subject: Re: New version
Date: Fri, 29 Jul 94 10:03:03 -0400
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
If DEK had been able to anticipate Microsoft's stupidity, he never
would have made it so difficult to incorporate backslashes in a document!
I noticed that you used math mode to get the backslash. When using tt
fonts, I use \char'134 which makes the backslash come out in the same
font (and looks better)
Bob
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 09:15:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 29 Jul 1994 10:13:37 -0400
Message-ID: <199407291413.KAA06642@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: New version
References: <199407282016.QAA09025@jasper.ora.com> <9407291404.AA19419@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 29 July 1994 at 10:03:03, bob@microprograms.com wrote:
> If DEK had been able to anticipate Microsoft's stupidity, he never
> would have made it so difficult to incorporate backslashes in a document!
>
> I noticed that you used math mode to get the backslash. When using tt
> fonts, I use \char'134 which makes the backslash come out in the same
> font (and looks better)
Thanks. I knew I needed to fix that, but I was being lazy. One of the
difficulties is that I'm developing the tools as I go...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | A successful tool is one that was used to do
Production Tools Specialist | something undreamed of by its author. -- S. C.
O'Reilly & Associates, Inc. | Johnson
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 29 Jul 1994 14:30:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9407291924.AA06308@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: YAV (content problems)
Date: Fri, 29 Jul 94 15:12:37 -0400
From: bob@microprograms.com
>> <sect1><title>Rooting the Tree</>
>> ...
>> The <filename role=dir>texmf</> root <emphasis>should not</> be placed
>> ^^^
>> >>> shall (standard speech :-)
>Huh?
If this document is a specification as Joachim stated, then "shall" is
the correct expression. "Should" implies that it is permissible, but
not desireable, to do so.
"Shall" (or its synomymns) should (shall?) be used in describing the
parts of the directory structure specification to which implementors
and installers are supposed to adhere. "Should" should be used when
discussing the parts of the directory to which conformance is not
mandated (a strong word, but I cannot quickly think of a better one)
but is desireable.
Bob
================================================================================
From owner-twg-tds@shsu.edu Sat, 30 Jul 1994 04:57:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 30 Jul 1994 05:58:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407300958.AA28909@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: YAV (content problems)
Norm: in modes 2.0, I changed CanonCX to cx; so the example should
use cx, not canoncx, for the directory name.
ABout `shall' -- jsch means that is ``standard speak''. Standards
shall never use the word ``should'', they shall only use the words
``shall'', ``may'', ``shall not'', etc.
================================================================================
From owner-twg-tds@shsu.edu Sat, 30 Jul 1994 05:11:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 30 Jul 1994 06:12:16 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199407301012.AA29148@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: jsch comments
I agree with virtually all Joachim's comments, and in particular with:
If these things
would have been introduced by a run-in header ``Rationale'' they might
have taken notice earlier.
Clearly separating `rationale' from `rules' would be a *big* help to
readers, I think.
This document is intended ... to a self-contained macro package.
^^^^^^^^^^^^^
>>> We should point out here that we do *not* mean a LaTeX2e package!
>>> I suggested to use the term `bundle' in another context.
I think it's unreasonable for LaTeX2e (or anything else) to usurp the
term ``package''. It's a generic term in all of computer software; it
can't have a special meaning in the TeX world.
If L2e wants or needs a special term for its packages, let them be the
ones to have the new word, like `bundles' (lbundles? lpackages?).
>>> This whole implementation-specific paragraph would win with a
>>> general, abstract description of the `kpathsea' functionality ---
True.
>>> either as an add-on, or instead. I.e., some text that is not Unix
>>> centric, but speaks of directory hierarchies, uses POSIX
>>> terminology, etc. (Karl? As you see it matters that you're still
I don't think it's particularly Unix-centric now, but whatever. I'll try
to come up with something while you-all are having fun in the sun.
<varlistentry><term>man</>
<listitem><para>for manual pages (UNIX-style documentation).</para>
>>> how about moving this directory below doc; i.e., doc/man/?
No. The man tree must have its own traditional organization: man/man1,
man/man3, etc., etc. This is so different from the ``real''
documentation intended to be under doc/ that I think it is cleaner to
keep them separate.
>>> The usage of modes.mf should be recommended in stronger words.
Or at least the specials and other macros from modes.mf, even if not all
the modes can be included because of Metafont memory limitations.
This feature is already supported by the <emphasis>Web2C</>
^^^
>>> web2C
I asked Norm to change this. Web2c is a proper name, so I prefer to
capitalize it (in documentation, anyway; in random email, I often don't
bother).
are determined by the package documenter. Below the level of the
^^^^^^^^^
>>> Btw, is this a real English word???
Yes. At least in computer-ese.
From owner-twg-tds@shsu.edu Tue, 09 Aug 1994 15:11:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Tue, 9 Aug 1994 16:09:29 -0400
Message-ID: <199408092009.QAA09188@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: TUG'94: changes to TDS...
Reply-To: TWG-TDS@SHSU.edu
As a result of discussions at TUG'94 (where most of us were able to
get together in person) there have been several proposed changes to
the TDS. I'll summarize them below so that we all have one more
opportunity to shriek in horr, er, ah, discuss these fine ideas.
- The document needs to be restructured to help the reader understand
the requirements and recommendations of the TDS. The proposal is
to mark portions of the document as 'fact', 'rational',
'requirement', 'recommendation', etc.
- Add an 'mf' directory to the root (/texmf/mf). This directory will
hold the sources for base files and non-font MF files (like
modes.mf).
- Move bibtex into the section of the document that describes other
possible directories. Otherwise, it looks like we're treating
bibtex and makeindex very differently for no good reason.
- Reorganize the fonts subtree to move /tfm, /pk, etc. higher up
in the tree:
/texmf/fonts/adobe/times/tfm/ptmr.tfm
becomes
/texmf/fonts/tfm/adobe/times/ptmr.tfm
I reluctantly accept that this is a reasonable change. It's not as
clean, but:
1) It will dramatically reduce the number of files that a
subdirectory searching algorithm has to examine (when looking
for TFM files, for example).
2) It makes it possible to use the TDS with an implementation
that only provides single level subdirectory searching. In
particular, A. User can set his TEXFONTS path to:
/texmf/fonts/tfm/adobe:/texmf/fonts/tfm/cm: ...
and load times/ptmr.tfm, helv/hvmr.tfm, etc. With the original
design, every face would have to be listed in the TEXFONTS path,
this design reduces that path to every foundry.
3) It's not dissimilar in spirit to the spreading that we've done
in the macros tree.
Anyone else remember anything we talked about? I've been trying to collect
my notes, but I feel like I should send this sooner rather than later,
so I may have missed something...
--norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 Aug 1994 23:23:03 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 9 Aug 1994 21:24:00 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408100424.VAA25694@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, unixtex@u.washington.edu, mackay@cs.washington.edu
Subject: Re: TUG'94: changes to TDS...
- Reorganize the fonts subtree to move /tfm, /pk, etc. higher up
in the tree:
/texmf/fonts/adobe/times/tfm/ptmr.tfm
becomes
/texmf/fonts/tfm/adobe/times/ptmr.tfm
I reluctantly accept that this is a reasonable change. It's not as
clean, but:
1) It will dramatically reduce the number of files that a
subdirectory searching algorithm has to examine (when looking
for TFM files, for example).
2) It makes it possible to use the TDS with an implementation
that only provides single level subdirectory searching. In
particular, A. User can set his TEXFONTS path to:
/texmf/fonts/tfm/adobe:/texmf/fonts/tfm/cm: ...
and load times/ptmr.tfm, helv/hvmr.tfm, etc. With the original
design, every face would have to be listed in the TEXFONTS path,
this design reduces that path to every foundry.
Oh, hell and damnation. This organization is not crippling, but for
font junkies like me, it makes the problem of managing font
directories about three times more difficult. It means that
instead of dodging in and out from ../tfm to ../afm to ../src
etc when I am working over a font, I have to keep a hairy lot
of long paths in mind. I can't even use pushd, because I can
only effectively manage the two directories at the head
of the list with pushd. To be brutally frank. this is a royal
damned pain in the neck, and a great deal more exasperating
and messy than any of the 8x3 and eight level ISO-9660
compromises.
I suppose it will be possible to do something consistent with
this idea, but when you take fonts and layout seriously, you
have to revisit almost every aspect of their metrics and mapping
for almost every book. (The University of X Press likes tight
setting, but the University of Y can't abide it. The University of
Z gave up ff ligatures for all the wrong reasons 15 years ago, and
their house stylist can't even consider setting with a font that
has them.) This directory structure will add many hours
to the necessary effort of accomodating those idiosyncracies.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 Aug 1994 23:23:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 9 Aug 1994 21:24:00 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408100424.VAA25694@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, unixtex@u.washington.edu, mackay@cs.washington.edu
Subject: Re: TUG'94: changes to TDS...
- Reorganize the fonts subtree to move /tfm, /pk, etc. higher up
in the tree:
/texmf/fonts/adobe/times/tfm/ptmr.tfm
becomes
/texmf/fonts/tfm/adobe/times/ptmr.tfm
I reluctantly accept that this is a reasonable change. It's not as
clean, but:
1) It will dramatically reduce the number of files that a
subdirectory searching algorithm has to examine (when looking
for TFM files, for example).
2) It makes it possible to use the TDS with an implementation
that only provides single level subdirectory searching. In
particular, A. User can set his TEXFONTS path to:
/texmf/fonts/tfm/adobe:/texmf/fonts/tfm/cm: ...
and load times/ptmr.tfm, helv/hvmr.tfm, etc. With the original
design, every face would have to be listed in the TEXFONTS path,
this design reduces that path to every foundry.
Oh, hell and damnation. This organization is not crippling, but for
font junkies like me, it makes the problem of managing font
directories about three times more difficult. It means that
instead of dodging in and out from ../tfm to ../afm to ../src
etc when I am working over a font, I have to keep a hairy lot
of long paths in mind. I can't even use pushd, because I can
only effectively manage the two directories at the head
of the list with pushd. To be brutally frank. this is a royal
damned pain in the neck, and a great deal more exasperating
and messy than any of the 8x3 and eight level ISO-9660
compromises.
I suppose it will be possible to do something consistent with
this idea, but when you take fonts and layout seriously, you
have to revisit almost every aspect of their metrics and mapping
for almost every book. (The University of X Press likes tight
setting, but the University of Y can't abide it. The University of
Z gave up ff ligatures for all the wrong reasons 15 years ago, and
their house stylist can't even consider setting with a font that
has them.) This directory structure will add many hours
to the necessary effort of accomodating those idiosyncracies.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 Aug 1994 04:39:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYA8o-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 10 Aug 94 10:40 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, twg-tds@shsu.edu, unixtex@u.washington.edu, mackay@cs.washington.edu
Subject: Re: TUG'94: changes to TDS...
>Oh, hell and damnation. This organization is not crippling, but for
>font junkies like me, it makes the problem of managing font
>directories about three times more difficult.
Agreed, but...
I don't like it much either, but it means we can implement TDS on
almost every TeX platform now. The fonts/tfm/*/*/*.tfm structure can
be used on any machine with one level of subdirectory searching, which
is what most TeX's supply. The fonts/*/*/tfm/*.tfm structure requires
much more sophisticated TeX implementations, and I fear it would just
end up with many TeX installations ignoring it.
Oh, and an old chestnut whilst we're here... Should the .fd files be
kept in:
texmf/tex/latex/fd/adobe/times/OT1ptm.fd
or:
texmf/fonts/fd/adobe/times/OT1ptm.fd
or what? The latter has the advantage of fitting in with the
fonts/<type>/<source>/<face>/<file> pattern, but does mean that the
LaTeX inputs path would have to include part of the fonts directory,
which may not be feasible under all TeX implementions (in particular,
I think Textures only allows one top-level TeX inputs folder).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 Aug 1994 13:45:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 10 AUG 94 19:45:10 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: TUG'94: changes to TDS...
Message-ID: <210004E1_000E3A00.00982C10CA516E32$34_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
As a complete newcomer to the TWG-TDS scene, and as one who only
learned of its existence when its impact on VAX/VMS implementations
was discussed, I wonder if it would be possible to get two things:
(1) a brief description of the current proposal, and
(2) an explanation of the rationale behind it?
Very many thanks in advance:
Philip Taylor, RHBNC (hereinafter referred to as `** Phil').
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 10:39:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 94 16:40:01 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408111540.AA02029@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
> It means that instead of dodging in and out from ../tfm to ../afm to
> ../src etc when I am working over a font, I have to keep a hairy lot
> of long paths in mind. I can't even use pushd, ....
Ah, now I see your objection to this fonts/tfm/.... layout.
However I dont see it as a TDS issue. Surely the TDS is a recipe for
where to put files pulled off archives etc. When someone is *working*
on a font I would expect them to be in a completely private area set
up as convenient to them, possibly under source control or
whatever. Certainly I would not consider the TDS we have been
discussing as a good structure for *developing* macro files, where I
would want documentation, current and previous versions, and test
files all to be together, but the number of people writing macro files
is small compared to the number using them, and the number of people
customising font files is probably orders of magnitude smaller still!
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 11:24:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 1994 12:24:57 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408111624.AA00419@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: TUG'94: changes to TDS...
First the minor things.
- Add an 'mf' directory to the root (/texmf/mf). This directory will
hold the sources for base files and non-font MF files (like
modes.mf).
I thought we already had this. Yes, we definitely need it. I don't know
about all base files, but besides modes.mf, this is where null.mf,
expr.mf, io.mf, etc. have to go. Also plain.mf, I guess. But not
cmbase.mf.
- Move bibtex into the section of the document that describes other
possible directories. Otherwise, it looks like we're treating
bibtex and makeindex very differently for no good reason.
You mean there are TeX systems without BibTeX? Seems about as likely as
a TeX system without Metafont.
The good reason is that bibtex is part of the stuff from Stanford and
MakeIndex isn't. The other good reason is that bib and bst files are a
heck of a lot more common, and a heck of a lot more useful to share,
than makeindex files.
I really think the TDS should specify the bibtex/bib and bibtex/bst
directories. If there are multiple types of makeindex (we should specify
a portable name for this one -- makeind?) files to worry about, then
maybe we should specify a structure for those, too.
Oh, and an old chestnut whilst we're here... Should the .fd files be
kept in:
My (strong, as usual :-) opinion is that the .fd files are LaTeX input
files, hence they should be somewhere in the tex/latex directory, not
anywhere under fonts. They will be written, installed, and maintained by
people who care about LaTeX, not any other form of TeX, so I think they
are part of LaTeX, not part of the fonts.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 11:24:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 1994 12:24:58 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408111624.AA00427@terminus.cs.umb.edu>
To: twg-tds@SHSU.edu
Subject: the font hierarchy, for the umpteenth time
one level of subdirectory searching, which
is what most TeX's supply.
I thought there were only two versions of TeX which do subdirectory
searching. web2c, which can obviously do whatever. And emtex, which does
only one level.
If all we're talking about is saving Mattes a few hours or days of
implementation time, then might I respectfully suggest that the TDS
should be more concerned with the time of ten zillion TeX users than one
(or two or twenty) TeX implementors?
Folks, implementing recursive subdirectory searching just *isn't that
hard*. I too implemented one-level subdirectory searching first (a
terrible mistake, obviously). Given that, it took me about a day to
get recursive searching working.
Anyway, all of this is totally beside the point (sorry). Given *any*
kind of subdirectory structure, whether it's format/source/family or
source/family/format, and given a more-than-minimal number of fonts,
looking up files in the filesystems is just plain *too slow*.
To get any kind of reasonable performance, you *have* to use ls-R (or
something analogous). Or (Pierre's method, before there was ls-R)
subvert the subdirectory searching by linking common stuff into a flat
directory and putting that first ... but I certainly hope we won't
standardize on *that*.
Thus, every implementation has to change anyway. And, once you have
ls-R, it's utterly irrelevant whether it's format/source/family or
source/family/format. So we might as well do the Right Thing, the thing
that will help people actually working with the fonts, like Pierre, and
stick with the existing source/family/format.
3) [putting format/ first is] not dissimilar in spirit to the
spreading that we've done in the macros tree.
There are few packages (is this true?) where there are different macro
files for each of several TeX formats, and anyway, there's only five or
so formats. There are hundreds of typefaces.
With the original
design, every face would have to be listed in the TEXFONTS path,
this design reduces that path to every foundry.
The whole reason I invented subdirectory searching for TeX in the first
place was to avoid specifying a list of arbitrary directory names,
whether they be typefaces or foundries. What happens when a site decides
to take the plunge and buy the Monotype cd? They have to recompile TeX,
or at least change all the config files and/or scripts and/or user
environment variables. Yuck and double yuck.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 11:34:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 AUG 94 17:34:14 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: the font hierarchy, for the umpteenth time
Message-ID: <21000EB7_000E37F8.00982CC7AA618A32$21_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> I thought there were only two versions of TeX which do subdirectory
>> searching. web2c, which can obviously do whatever. And emtex, which does
>> only one level.
emTeX allows the user to specify either "!" (meaning one level) or
"!!" (meaning a fully-recursive search).
>> If all we're talking about is saving Mattes a few hours or days of
>> implementation time, then might I respectfully suggest that the TDS
>> should be more concerned with the time of ten zillion TeX users than one
>> (or two or twenty) TeX implementors?
The vast majority of those ten zillion are probably completely dependent
on Eberhard's good will...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 11:38:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 AUG 94 17:37:50 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: TUG'94: changes to TDS...
Message-ID: <21000EB7_002FE1D0.00982CC82B917072$21_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> I really think the TDS should specify the bibtex/bib and bibtex/bst
>> directories. If there are multiple types of makeindex (we should specify
>> a portable name for this one -- makeind?) files to worry about, then
>> maybe we should specify a structure for those, too.
There are at least two, to my certain knowledge: MakeInd[e]x and IdxTeX.
>> Oh, and an old chestnut whilst we're here... Should the .fd files be
>> kept in:
>> My (strong, as usual :-) opinion is that the .fd files are LaTeX input
>> files, hence they should be somewhere in the tex/latex directory, not
>> anywhere under fonts. They will be written, installed, and maintained by
>> people who care about LaTeX, not any other form of TeX, so I think they
>> are part of LaTeX, not part of the fonts.
It's not impossible that the Plain TeX community will eventually migrate
to an NFSS-based font-selection system, in which case they too _may_ need
.FD files...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 11:52:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
Date: Thu, 11 Aug 1994 17:53:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:297070:940811165322"@cl.cam.ac.uk>
lets get our history straight. I asked Phil if he (or any other NTS
member) would participate in TDS, and he said he was over busy at the
time; not suprisingly this interchange has been deleted from his
brain, but honest he was consulted!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:10:44 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYder-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 11 Aug 94 18:11 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>I thought there were only two versions of TeX which do subdirectory
>searching. web2c, which can obviously do whatever. And emtex, which does
>only one level.
OzTeX does one level. Textures 1.7 does subdirectory searching,
although I don't know how many levels. In fact the only TeX I know of
that doesn't do at least one level of subdirectory searching is PCTeX.
But there may be others.
>Thus, every implementation has to change anyway.
I don't think it's reasonable for us to mandate this. Most users are
happily skipping along with their current setup, cheerfully ignoring
the file overhead. If we mandate a file structure which can be
implemented on only 50% of the TeX's out there, it's not going to go
very far.
>The whole reason I invented subdirectory searching for TeX in the first
>place was to avoid specifying a list of arbitrary directory names,
>whether they be typefaces or foundries. What happens when a site decides
>to take the plunge and buy the Monotype cd? They have to recompile TeX,
>or at least change all the config files and/or scripts and/or user
>environment variables. Yuck and double yuck.
Well, on systems which support subdirectory searching they do nothing.
On systems with one level of subdirectory searching, they add
fonts/tfm/monotype to the environment variable. On systems which
don't support subdirectory searching at all, they'll be installing
everything in a flat directory and ignoring TDS anyway...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:11:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 AUG 94 18:10:55 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: TUG'94: changes to TDS...
Message-ID: <21002E28_000E2A30.00982CCCCA6A9512$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> lets get our history straight. I asked Phil if he (or any other NTS
>> member) would participate in TDS, and he said he was over busy at the
>> time; not suprisingly this interchange has been deleted from his
>> brain, but honest he was consulted!
I cannot deny the majority of these statements, although their significance
is not entirely clear to me unless SPQR is referring back to my introductory
remarks when I wrote ``and as one who only learned of its existence when its
impact on VAX/VMS implementations was discussed''. If so, then I humbly and
freely admit that I was mistaken: I first learned of its existence from the
estimable SPQR, on 19th May 1994 to be exact. But since I was far too busy to
deal with it then, I purged from my memory all recollections thereof, and I am
therefore deeply indepted to the aforesaid SPQR for bringing this fact not only
to my attention but to that of the entire group.
Now could we get back to TDS and stop worrying about exactly when I first
learned of its existence?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:21:33 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Thu, 11 Aug 1994 18:22:03 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:009080:940811172219"@cl.cam.ac.uk>
there is a school of thought (I have still to transcrive my notes
from a printed TDS i worked on duribng a dull session at TUG94) which
says that tfm files should go under texmf/tex, as TeX needs them,
mainly.
i havent read all this correspondence, but i must agree with Kalr
against Alan. the TDS assumes we are working for the future, and that
people *will* do more work. its more important that it be useful in
five years than that most people can use it now. single level subdir
searching is a silly concept, IMHO. lets help stamp out this limiting feature
sebastian
PS phil, i wasn't being pernickety, honest. i just didnt want anyone
to think i had voted to exclude you cos you'd be awkward....
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:22:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 AUG 94 18:22:01 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <21002E68_002FDFE0.00982CCE57A0ADB2$19_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> OzTeX does one level. Textures 1.7 does subdirectory searching,
>> although I don't know how many levels. In fact the only TeX I know of
>> that doesn't do at least one level of subdirectory searching is PCTeX.
>> But there may be others.
VMS TeX does zero level searching, as of this instant.
>> I don't think it's reasonable for us to mandate this. Most users are
>> happily skipping along with their current setup, cheerfully ignoring
>> the file overhead. If we mandate a file structure which can be
>> implemented on only 50% of the TeX's out there, it's not going to go
>> very far.
No matter what we `mandate', it's got to be patently beneficial to
Joe User, otherwise he's just going to ignore the whole thing.
>> Well, on systems which support subdirectory searching they do nothing.
>> On systems with one level of subdirectory searching, they add
>> fonts/tfm/monotype to the environment variable. On systems which
>> don't support subdirectory searching at all, they'll be installing
>> everything in a flat directory and ignoring TDS anyway...
Not true: VMS TeX does not support subdirectory searching, yet neither
do I use a flat directory structure. I use a shallowly nested structure
to which I afford access through the use of logical names.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:32:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 94 18:33:30 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408111733.AA02171@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
[I assume Alan and Phil are quoting Karl, although I still havent seen
the original message..]
>The whole reason I invented subdirectory searching for TeX in the first
>place was to avoid specifying a list of arbitrary directory names,
Yes, for which everyone is very grateful (honestly), however this need
is satisfied by the simple form of `recursive directory searching'.
ie just putting a special marker at the *end* of a direcory string.
The benefits of mandating web2c style pattern patching at arbitrary
parts of the string, rather than just the end is far less clear.
ie do we really want to mandate that all TeX's should support the
equivalent of:
TEXFONTS=/texmf/fonts//tfm
which for Phil (who I assume is now on this list?) means
recursively search for all subdirectories called `tfm' and then
look at each file in those subdirectories.
Sebastian said:
... single level subdir searching is a silly concept, IMHO. lets help
stamp out this limiting feature.
I have no trouble mandating recursive directory searching. I have a
lot more trouble mandating that all TeX's should have this pattern
matching form of searching. It is a lot more complicated
conceptually, and I can honestly see no benefit.
If I want TeX to look for tfm files, I *want* to say
TEXFONTS=/texmf/fonts/tfm//
without worrying whether internal optimisations have or have not saved
Tex from the apparent need to search over all the pk directories,
which is what logically it ought to do with a specification of
TEXFONTS=/texmf/fonts//tfm
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:40:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 AUG 94 18:40:17 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <21002E68_002FE418.00982CD0E4B8C192$19_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> PS phil, i wasn't being pernickety, honest. i just didnt want anyone
>> to think i had voted to exclude you cos you'd be awkward....
Awkward? MOI ?? !!! :-)
Let's just say that I don't believe in agreeing with things simply because
they represent the current received wisdom. I haven't yet read the TDS
proposal (I've reported a LaTeX/2e problem in processing the document to
Norman Walsh) so I'm in no position to comment on the bulk of it at
all, but based on discussions at Santa Barbara there is one area at the
moment which causes me concern:
It was suggested at Santa Barbara that individual `packages' should be
placed in individual directories, the idea being that when a package
was updated one could better ensure that redundant files were not left
behind. But either this concept has to be generalised to include _all_
relevant files (including TEX, MF, TFM, PK, EPS, ...), or the argument adduced
in its favour is fatally flawed. Is this not true?
The other point which concerns me is name-conflict. When I came to process
the DRV-NORM document, I found it referenced Verbatim.Sty, which I didn't
have. So I trawled off to a remote fenland site and did a ``quote site
index verbatim\.sty''. And found six distinct matches. As luck would have
it, one was in a directory whose name bore some relationship to other files
in the DRV-NORM directory, so I chose that one. But there was no way of
knowing that I was right, and bearing in mind that the document then blew
up whilst processing verbatim text, it looks as if I was mistaken. Now
there is _no way_ that we can prevent authors from using the same name for
modules which, ITHO, offer the same functionality. Cf the 6 Verbatim.Stys,
$n$ CropMark(s).Sty, etc., etc., etc. It is therefore essential that
a `package' preferentially reference its own variant of any ambiguous file.
This means that when processing a file in an $n$-level deep directory,
any files which _that_ file references should be first be sought in
the same directory, and then in all sub-directories thereof, then in all
parent directories thereof, and finally in unrelated branches of the tree.
Is that currently implemented in any recursive implementation, and does it
feature in the proposal?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:53:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 11 Aug 1994 13:51:35 -0400
Message-ID: <199408111751.NAA20925@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
References: <199408111624.AA00419@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 11 August 1994 at 12:24:57, K. Berry wrote:
> First the minor things.
>
> - Add an 'mf' directory to the root (/texmf/mf). This directory will
> hold the sources for base files and non-font MF files (like
> modes.mf).
>
> I thought we already had this. Yes, we definitely need it. I don't know
> about all base files, but besides modes.mf, this is where null.mf,
> expr.mf, io.mf, etc. have to go. Also plain.mf, I guess. But not
> cmbase.mf.
Ok, maybe I just forgot to put it in the doc...
> - Move bibtex into the section of the document that describes other
> possible directories. Otherwise, it looks like we're treating
> bibtex and makeindex very differently for no good reason.
>
> You mean there are TeX systems without BibTeX? Seems about as likely as
> a TeX system without Metafont.
>
> The good reason is that bibtex is part of the stuff from Stanford and
> MakeIndex isn't. The other good reason is that bib and bst files are a
> heck of a lot more common, and a heck of a lot more useful to share,
> than makeindex files.
>
> I really think the TDS should specify the bibtex/bib and bibtex/bst
> directories. If there are multiple types of makeindex (we should specify
> a portable name for this one -- makeind?) files to worry about, then
makeindx ?
> maybe we should specify a structure for those, too.
Ok, how many utilities are there that might need thier own files? Can
we enumerate all of them? If not, then we need a good reason for enumerating
only a few of them. I'm sure that for any given subset of utilities, there
are users not using any of them.
> Oh, and an old chestnut whilst we're here... Should the .fd files be
> kept in:
>
> My (strong, as usual :-) opinion is that the .fd files are LaTeX input
> files, hence they should be somewhere in the tex/latex directory, not
> anywhere under fonts. They will be written, installed, and maintained by
> people who care about LaTeX, not any other form of TeX, so I think they
> are part of LaTeX, not part of the fonts.
Well, maybe other formats will support them someday. But they aren't
really fonts, so I vote that they go under /latex/ for the moment.
Now, Alan's suggestion that we replicate the fonts tree:
/texmf/tex/latex/fd/adobe/times/OT1ptmr.fd
seems a bit grandious. Can't we drop them all in /texmf/tex/latex/fd?
Without causing too much pain and suffering, I mean...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 12:59:30 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 11 Aug 1994 13:57:47 -0400
Message-ID: <199408111757.NAA20938@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <m0qYder-00003QC@csrj.crn.cogs.susx.ac.uk> <"swan.cl.cam.:009080:940811172219"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 11 August 1994 at 18:22:03, Sebastian Rahtz wrote:
> there is a school of thought (I have still to transcrive my notes
> from a printed TDS i worked on duribng a dull session at TUG94) which
> says that tfm files should go under texmf/tex, as TeX needs them,
> mainly.
My addled brain recoils in horror at the thought! Please, let's not do
anything that perverse (even if we recognize that there is a grain of
truth in there). TFM files come from fonts.
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 13:00:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 94 19:01:09 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408111801.AA02199@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
Norm,
> Now, Alan's suggestion that we replicate the fonts tree:
/texmf/tex/latex/fd/adobe/times/OT1ptmr.fd
> seems a bit grandious. Can't we drop them all in /texmf/tex/latex/fd?
> Without causing too much pain and suffering, I mean...
Huh? That is an awful lot of files in one directory. I thought the
whole idea of the TDS was so that files that came from unrelated
sources were in different directories.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 13:10:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 11 Aug 1994 14:09:14 -0400
Message-ID: <199408111809.OAA20944@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <21002E68_002FE418.00982CD0E4B8C192$19_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
On 11 August 1994 at 18:40:17, CHAA006@vax.rhbnc.ac.uk wrote:
> It was suggested at Santa Barbara that individual `packages' should be
> placed in individual directories, the idea being that when a package
> was updated one could better ensure that redundant files were not left
> behind. But either this concept has to be generalised to include _all_
> relevant files (including TEX, MF, TFM, PK, EPS, ...), or the argument
> adduced in its favour is fatally flawed. Is this not true?
>
> The other point which concerns me is name-conflict. When I came to process
> the DRV-NORM document, I found it referenced Verbatim.Sty, which I didn't
(aside: that wierd name comes from the fact that the original document
is in SGML and I derive the TeX source from it. The derived
source isn't really *supposed* to hang around, or it would have
a better name)
> have. So I trawled off to a remote fenland site and did a ``quote site
> index verbatim\.sty''. And found six distinct matches. As luck would have
The TDS cannot hope to make an *archive site* easier to maintain (well, it
might, but not without a lot of work by the archivists---I'll bug them after
we get this settled for ourselves ;-)
> it, one was in a directory whose name bore some relationship to other files
> in the DRV-NORM directory, so I chose that one. But there was no way of
> knowing that I was right, and bearing in mind that the document then blew
> up whilst processing verbatim text, it looks as if I was mistaken. Now
> there is _no way_ that we can prevent authors from using the same name for
> modules which, ITHO, offer the same functionality. Cf the 6 Verbatim.Stys,
> $n$ CropMark(s).Sty, etc., etc., etc. It is therefore essential that
> a `package' preferentially reference its own variant of any ambiguous file.
> This means that when processing a file in an $n$-level deep directory,
> any files which _that_ file references should be first be sought in
> the same directory, and then in all sub-directories thereof, then in all
> parent directories thereof, and finally in unrelated branches of the tree.
> Is that currently implemented in any recursive implementation, and does it
> feature in the proposal?
That's a marvelous idea, but it doesn't fit in with any existing scheme
that I know of (in fact, I think it would require a not-TeX since the
searching would have to be influenced by where the last \input{} file
was found...). However, I don't think you need anything that sophisticated
_in practice_. The subdirectory tree for a big site might be:
/texmf/tex/latex/.../verbatim.sty
/texmf/tex/plain/.../verbatim.sty
/texmf/tex/eplain/.../verbatim.sty
But there should never be two files called 'verbatim.sty' under
/texmf/tex/format. If there are, what hope can *any* arbitrary scheme have
for finding the right one? Recursive subdirectory searching when processing
LaTeX documents should use a path like this: ./:/texmf/tex/latex// so that
all those other verbatim.sty files will not be found.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The most likely way for the world to be
Production Tools Specialist | destroyed, most experts agree, is by accident.
O'Reilly & Associates, Inc. | That's where we come in; we're computer
90 Sherman Street | professionals. We cause accidents. -- Nathaniel
Cambridge, MA 02140 | Borenstein
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 13:12:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 11 Aug 1994 14:10:23 -0400
Message-ID: <199408111810.OAA20951@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
References: <199408111751.NAA20925@jasper.ora.com> <9408111801.AA02199@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 11 August 1994 at 19:01:09, David Carlisle wrote:
>
> > Now, Alan's suggestion that we replicate the fonts tree:
>
> /texmf/tex/latex/fd/adobe/times/OT1ptmr.fd
>
> > seems a bit grandious. Can't we drop them all in /texmf/tex/latex/fd?
> > Without causing too much pain and suffering, I mean...
>
> Huh? That is an awful lot of files in one directory. I thought the
> whole idea of the TDS was so that files that came from unrelated
> sources were in different directories.
You're right. I withdraw the statement. A piece of my brain must have
fallen out.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 Aug 1994 13:29:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 Aug 94 18:55:17 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408111755.AA02190@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Eeeek Phil has yet another meaning to `recursive searching'!
> This means that when processing a file in an $n$-level deep directory,
> any files which _that_ file references should be first be sought in
> the same directory, and then in all sub-directories thereof, then in all
> parent directories thereof, and finally in unrelated branches of the
> tree.
I see what motivated Phil's suggestion, but I am not sure that I agree
with it.
It means that, even within the same document, \input{foo} would find
different files, depending on the `current file'. I am not sure that
this is the correct semantics for \input, especially given that TeX
does not let the user know what the current file is.
Also I think that there are not really so many name clashes. As an
example, the 6 `verbatim.sty' Phil mentioned, all but one are just
copies of Rainer's file. (And I am sure the authors of the remaining
one would remove it if they were reminded of its existence)
Actually if Phil is using LaTeX2e *non* of these 6 is the correct
version, as the current verbatim.sty is only on ctan as documented
source (verbatim.dtx:-).
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 05:56:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 06:57:47 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121057.AA19372@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: whither fontname map files?
(This is apropos of the ``other top-level directories?'' thread.
I'll get to fonts later.)
The next release of my fontname stuff is going to have a bunch of
simple map files along the lines of psfonts.map and texfonts.map, these
that map the abbreviations to their directory names and meanings.
This is for the benefit of programs to use (to automatically put fonts
in the right place), as well as for humans to read. Thus, they should go
somewhere in texmf/. The paper itself will remain in
doc/fontname/fontname.texi, I suppose, but where should the map files
go? Another optional top-level directory, i.e.,
texmf/fontname/typeface.map?
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 08:37:04 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYwnh-00006qC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 14:37 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: whither fontname map files?
>go? Another optional top-level directory, i.e.,
>texmf/fontname/typeface.map?
Or texmf/fonts/<driver>/<file> (eg texmf/fonts/dvips/psfonts.map)? Or
texmf/<driver>/<file> (eg texmf/dvips/psfonts.map)? These files are
driver-specific, so should live with the driver. The human-readable
version can go in texmf/doc/fontname/<file>.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 08:48:01 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYwyL-000075C@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 14:48 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: TUG'94: changes to TDS...
>expr.mf, io.mf, etc. have to go. Also plain.mf, I guess. But not
>cmbase.mf.
Why not cmbase.mf? A *lot* of fonts use cmbase.mf, not just the CM
fonts.
> Oh, and an old chestnut whilst we're here... Should the .fd files be
> kept in:
>My (strong, as usual :-) opinion is that the .fd files are LaTeX input
>files, hence they should be somewhere in the tex/latex directory, not
>anywhere under fonts. They will be written, installed, and maintained by
>people who care about LaTeX, not any other form of TeX, so I think they
>are part of LaTeX, not part of the fonts.
Yes, but... a) at some point in the future, other formats may read .fd
files, e.g. a port of NFSS2 to eplain, and b) this means duplicating
the fonts subdirectory structure under latex, which breaks the nice
texmf/<format>/<package>/<file> symmetry.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 09:42:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 10:43:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121443.AA10454@claude.cs.umb.edu>
To: alanje@cogs.susx.ac.uk, twg-tds@shsu.edu
Subject: Re: whither fontname map files?
I wasn't clear.
The fontname .map files *are* machine-readable. That's the whole
point. Not driver-specific.
A top-level fontname/ directory is the right thing, I'm pretty sure now.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 10:29:58 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYyUb-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 16:26 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: whither fontname map files?
>The fontname .map files *are* machine-readable. That's the whole
>point. Not driver-specific.
Er, so what format are they in? dvips format? Textures format?
OzTeX format? These all look pretty driver-specific to me...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:07:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 12:08:34 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121608.AA21943@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: top-level directories
Norm> Ok, how many utilities are there that might need thier own
files? Can we enumerate all of them? If not, then we need a good
reason for enumerating only a few of them.
That *might* need? An infinite number, as yet undreamed-of.
The ``good reason'' is that we are not omniscient.
I think we should just list all the ones we know about (I don't know of
any that haven't already been mentioned), and say ``other utilities may
use their own analogous top-level directories if needed''.
Phil> There are at least two, to my certain knowledge: MakeInd[e]x and IdxTeX.
OK, so what goes in their respective directories? I use makeindex, but
I don't know of any system-wide style files or other such stuff. Just
(La)TeX macros, and they go in tex/whatever.
I've never used idxtex, so have no idea what should go in that
directory.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:07:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 12:08:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121608.AA21967@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: name conflicts
The other point which concerns me is name-conflict. When I came to process
I think the best place to address name conflicts is at the archive
end. When a file comes in, check if there is already a (different) file
by the same name elsewhere in the archive, and if so, request a name change.
Obviously this would have to be done automatically.
I suspect many of the apparently-different verbatim.sty's are the same
file, though possibly different versions. Maybe not.
when processing a file in an $n$-level deep directory,
any files which _that_ file references should be first be sought in
the same directory, and then in all sub-directories thereof, then in all
parent directories thereof, and finally in unrelated branches of the tree.
Is that currently implemented in any recursive implementation, and does it
feature in the proposal?
No, it's not implemented; no, it's not in the proposal.
Given that people are worried about the relatively modest implementation
changes from subdirectory searching, I think this would meet with even
more resistance. And aside from anything else, I would hesitate to
mandate anything with which there is no practical experience.
It's a neat idea, though.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:08:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 12:08:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121608.AA21951@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: whither .fd files?
It's not impossible that the Plain TeX community will eventually migrate
to an NFSS-based font-selection system, in which case they too _may_ need
.FD files...
I suppose.
It's ok with me if there is an fd/ directory paralleling tfm and the
rest in fonts/. I think the choice is the same as it has always been --
either put the fonts//fd in the latex inputs path, repeat the font
structure in tex/latex/fd, or flatten the .fd files into some other
structure in tex/.
None of these seem terribly palatable. Right now the .fd's are just
dumped into flat directories, so maybe that can stand. Norm's argument
that they are not really fonts makes sense to me, but then the argument
that repeating the font structure is pretty tedious also makes sense.
So who knows? In the absence of any other compelling argument, I'd say
let's simplify the search paths, and put the fd files into /latex/.
But hey, whatever. I don't have strong opinions about this any more :-)
By the way (I suppose this should be directed at latex-bugs), but I just
realized that the .fd files have a big naming problem -- using three
characters for the encoding (at the beginning of the name, yet), like
OT1ptmr.fd, is going to cause zillions of name clashes with the
PostScript fonts...
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:08:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 12:08:36 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121608.AA21959@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: package/filetype vs. filetype/package
It was suggested at Santa Barbara that individual `packages' should be
placed in individual directories, the idea being that when a package
was updated one could better ensure that redundant files were not left
behind. But either this concept has to be generalised to include _all_
relevant files (including TEX, MF, TFM, PK, EPS, ...), or the argument adduced
in its favour is fatally flawed. Is this not true?
Flawed, yes. I don't know about ``fatally''.
We discussed at infinite length the idea of inverting the whole tree, so
it would be texmf/package/filetype/... instead of the present (approximately)
texmf/filetype/package/...
I was more or less the strongest proponent of package/filetype, but even
I agreed eventually that it was too big a change from the current
setup. Since there is not even one (so far as any of us knew) TeX
installation that arranges things that way, it seemed untenable to
standardize on it.
The compromise, such as it was, was to encourage package maintainers to
make distributions following the TDS except for a top-level
<packagename>[-<version>] directory, and then people (like me and maybe
you :-) who wish to experiment with the package/filetype setup can do
easily. (There are other good reasons for making distributions like that
also.)
The mail archives have the reams of messages on this topic ...
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:08:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 12:08:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408121608.AA21975@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
David> The benefits of mandating web2c style pattern patching at arbitrary
parts of the string, rather than just the end is far less clear.
Is that what this whole thing about? I don't think the TDS should
mandate foo//bar. Does that answer the objection? (Oh well, you're
probably in the Alps by now :-)
TEXFONTS=/texmf/fonts/tfm//
without worrying whether internal optimisations have or have not saved
Tex from the apparent need to search over all the pk directories,
I must not have been clear.
*Even if* we put all the tfm directories together, under
texmf/fonts/tfm//, the resulting list of umpteen directories is
*too slow* to search linearly.
To put the same thing another way: the problem is not in *building* the
list of tfm directories (only happens once); it's in *searching* the
list (happens on every search).
This is why I claim ls-R or some equivalent is necessary.
... unless, of course, the TDS abandons the source/typeface/filetype
subdirectory specification altogether, and combines all or some of those.
But that, as we know, has its own efficiency problems, since disk caches
are typically not set up to deal well with huge directories. George
pointed out ages ago this was a particular problem on VMS, in fact.
Phil> No matter what we `mandate', it's got to be patently beneficial to
Joe User, otherwise he's just going to ignore the whole thing.
The TDS is primarily aimed at system implementors and developers, not
users. Users will hopefully simply notice that files are in the same
relative place in the TeX library structure on different systems, and be
happy. This is the primary benefit for everyone.
Alan> I don't think it's reasonable for us to mandate this. Most
users are happily skipping along with their current setup,
cheerfully ignoring the file overhead. If we mandate a file
structure which can be implemented on only 50% of the TeX's out
there, it's not going to go very far.
Fine, agreed, so what change are you proposing?
Without subdirectories, the TDS can't do a good job of putting files in
reasonable (maintainable, findable, readable) places.
Without subdirectory searching, search paths would be too long for
environment space on DOS and system V (aside from everything else).
Well, on systems which support subdirectory searching they do
nothing. On systems with one level of subdirectory searching, they
[...] On systems which don't support subdirectory searching at all,
they [...]
Of course there are ways to kludge around lack of recursive (or any)
subdirectory searching. But I do not think the TDS should accomodate
those kludges into a spec that is supposed to be useful for years to
come. Everyone, even users, even implementors, will benefit from better
implementations. Sure, the situation will be chaotic for a while -- but
at least the chaos will have a target to try to resolve to. Right now
there is chaos and no target.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:26:38 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYzRq-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 17:27 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>This is why I claim ls-R or some equivalent is necessary.
Or to put it another way... ls-R or some equivalent is necessary on
sites which have large numbers of files. Most TeX installations have
very few, which is why I'm pessimistic about most implementors
changing their file searching technology just to fit TDS. `Why
bother,' they'll say, `most of our users have < 100 tfm files anyhow'.
The only difference between fonts/<filetype>/<source>/<typeface> and
fonts/<source>/<typeface>/<filetype> as far as most sysadmins are
concerned is that at the moment one of them is feasible and the other
one isn't.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:30:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYzV9-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 17:30 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: whither .fd files?
>By the way (I suppose this should be directed at latex-bugs), but I just
>realized that the .fd files have a big naming problem -- using three
>characters for the encoding (at the beginning of the name, yet), like
>OT1ptmr.fd, is going to cause zillions of name clashes with the
>PostScript fonts...
Er, for example? Encodings have to be at most 3 letters, LaTeX
families have to be at most five. As long as Y&Y don't release a
Lucida Bright Sans Expert set (ylcbsx) we're OK.
The real problem with these filenames is that they're case sensitive,
but that's a whole other can of worms...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 11:31:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qYzWS-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 12 Aug 94 17:32 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: top-level directories
>OK, so what goes in their respective directories? I use makeindex, but
>I don't know of any system-wide style files or other such stuff. Just
>(La)TeX macros, and they go in tex/whatever.
There are makeindex style files (.ist). Any idea where to put these?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 12:14:07 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 12 Aug 1994 13:12:16 -0400
Message-ID: <199408121712.NAA28191@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
References: <199408111624.AA00419@terminus.cs.umb.edu> <m0qYwyL-000075C@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 12 August 1994 at 14:48, Alan Jeffrey wrote:
> >My (strong, as usual :-) opinion is that the .fd files are LaTeX input
> >files, hence they should be somewhere in the tex/latex directory, not
> >anywhere under fonts. They will be written, installed, and maintained by
> >people who care about LaTeX, not any other form of TeX, so I think they
> >are part of LaTeX, not part of the fonts.
>
> Yes, but... a) at some point in the future, other formats may read .fd
> files, e.g. a port of NFSS2 to eplain, and b) this means duplicating
> the fonts subdirectory structure under latex, which breaks the nice
> texmf/<format>/<package>/<file> symmetry.
We've got a 'generic' level in there somewhere don't we? Or did that
go away? Anyway, we probably need one.
We can either plan for the future and assume they'll be used by multiple
formats and put them under generic now, or we can move them when someone
else really uses them.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 12:19:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 12 Aug 1994 13:17:54 -0400
Message-ID: <199408121717.NAA28197@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <199408121608.AA21975@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 12 August 1994 at 12:08:37, K. Berry wrote:
> *Even if* we put all the tfm directories together, under
> texmf/fonts/tfm//, the resulting list of umpteen directories is
> *too slow* to search linearly.
>
> To put the same thing another way: the problem is not in *building* the
> list of tfm directories (only happens once); it's in *searching* the
> list (happens on every search).
>
> This is why I claim ls-R or some equivalent is necessary.
You're right. *But* the reasoning was something like this: some people
are using subdir searching implementations that don't support ls-R (and
they always will because the implementor won't add it or they won't build
the ls-R file, or both) and those people shouldn't be penalized
unnecessarily. If they only have to look for TFMs, there should be far
fewer directories to search so it should be relatively faster than if it
also looked, in vain, through all the PK directories ('cause there are
bazillions of those).
> ... unless, of course, the TDS abandons the source/typeface/filetype
> subdirectory specification altogether, and combines all or some of those.
Ack, hack, choke. No!
> Of course there are ways to kludge around lack of recursive (or any)
> subdirectory searching. But I do not think the TDS should accomodate
> those kludges into a spec that is supposed to be useful for years to
> come. Everyone, even users, even implementors, will benefit from better
> implementations. Sure, the situation will be chaotic for a while -- but
> at least the chaos will have a target to try to resolve to. Right now
> there is chaos and no target.
Agreed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 12:20:31 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Fri, 12 Aug 1994 13:18:46 -0400
Message-ID: <199408121718.NAA28201@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: top-level directories
References: <199408121608.AA21943@terminus.cs.umb.edu> <m0qYzWS-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 12 August 1994 at 17:32, Alan Jeffrey wrote:
> >OK, so what goes in their respective directories? I use makeindex, but
> >I don't know of any system-wide style files or other such stuff. Just
> >(La)TeX macros, and they go in tex/whatever.
>
> There are makeindex style files (.ist). Any idea where to put these?
/texmf/makeindx, I guess.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 13:04:38 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Fri, 12 Aug 1994 19:05:09 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:238320:940812180516"@cl.cam.ac.uk>
>
> No matter what we `mandate', it's got to be patently beneficial to
> Joe User, otherwise he's just going to ignore the whole thing.
not so. Joe User has little choice! its Joe Package Maintainer or Joe
Implementor we have to reach. J.U. wont even know about it :-}
>
> Not true: VMS TeX does not support subdirectory searching, yet neither
> do I use a flat directory structure. I use a shallowly nested structure
> to which I afford access through the use of logical names.
>
i thought you could do recursive searching with VMS logical names
anyway?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 13:07:20 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Fri, 12 Aug 1994 19:07:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:239130:940812180759"@cl.cam.ac.uk>
david is so *reasonable*, one has to agree with him. but i am
confused. i thought Alan argued in favour of `one-level-only' on
principle? David's argument against embedded wild cards is a different
matter with which i have a lot of agreement
sebastian
PS but i say it should be texmf/tex/tfm :-}
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 13:12:01 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Fri, 12 Aug 1994 19:12:48 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:240570:940812181254"@cl.cam.ac.uk>
Phil says
> > behind. But either this concept has to be generalised to include _all_
> > relevant files (including TEX, MF, TFM, PK, EPS, ...), or the argument
> > adduced in its favour is fatally flawed. Is this not true?
agreed. but we *do* generalize the concept in the way you note.
Norm says
> But there should never be two files called 'verbatim.sty' under
> /texmf/tex/format. If there are, what hope can *any* arbitrary scheme have
> for finding the right one? Recursive subdirectory searching when processing
> LaTeX documents should use a path like this: ./:/texmf/tex/latex// so that
> all those other verbatim.sty files will not be found.
i agree with Norm. we shouldnt solve the problems of archives. and we
shouldnt worry about these duplicate names. they'll go away in due
course cos they are so plainly obviously a Bad Thing. Sophisticated
users like Phil will always have logical names/environment variables
to sort it out for them
Sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 13:31:44 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
Date: Fri, 12 Aug 1994 19:32:25 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:249200:940812183235"@cl.cam.ac.uk>
> > Yes, but... a) at some point in the future, other formats may read .fd
> > files, e.g. a port of NFSS2 to eplain, and b) this means duplicating
> > the fonts subdirectory structure under latex, which breaks the nice
> > texmf/<format>/<package>/<file> symmetry.
>
> We've got a 'generic' level in there somewhere don't we? Or did that
> go away? Anyway, we probably need one.
>
> We can either plan for the future and assume they'll be used by multiple
> formats and put them under generic now, or we can move them when someone
> else really uses them.
the alternative is have
texmf/tex/fonts
which contains generic TeX font-related macro files, like .fd files,
which has to be on every path (like generic).
i say leave in latex until there is a problem, then move to generic if
needed
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 14:21:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 AUG 94 20:21:57 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <21004A28_000E31C0.00982DA8432C4FD2$17_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> not so. Joe User has little choice! its Joe Package Maintainer or Joe
>> Implementor we have to reach. J.U. wont even know about it :-}
Unless implementors/maintainers become far more aggressive than
at present, they will continue to allow users to set up the
directory structure which suits them. Eberhard has a preferred
hierarchy, which I choose not to follow: but through the use
of DOS variables I map my preferred structure into his. Any user
can do likewise. And an implementor/maintainer who becomes overly
restrictive is likely to rapidly lose favour: remember a certain
well-known system that tried to decree that `8-bit characters are
a Bad Thing'?
>> i thought you could do recursive searching with VMS logical names
>> anyway?
No. VMS allows (for example) $ Define TeX_Inputs TeX_Root:[TeX.Inputs...]
but the implementations do not necessarily honour it; to do so, they
would need to use Lib$Find_File, which I think none yet do.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 15:14:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 15:14:48 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00982D7D.5B40BB24.2315@SHSU.edu>
Subject: Re: the font hierarchy, for the umpteenth time
On Fri, 12 AUG 94 20:21:57 BST, Phil Taylor <CHAA006@VAX.RHBNC.AC.UK> posted:
> >> i thought you could do recursive searching with VMS logical names
> >> anyway?
>
> No. VMS allows (for example) $ Define TeX_Inputs TeX_Root:[TeX.Inputs...]
> but the implementations do not necessarily honour it; to do so, they would
> need to use Lib$Find_File, which I think none yet do.
Ummmm, Phil. Since we moved to OpenVMS 5.5-2 (VAX; not tried on AXP) and
now under 6.1 (as well as under 6.0), I have used the defintions
$ define/system/executive/translation=concealed/name=no_alias tex_root -
sys6:[tex.]
$ define/system tex_inputs tex_root:[inputs...]
without a problem (as far as I can tell, anyway). I'll openly admit that
it's a dangerous thing to let someone like me setup things as I'm about as
computer operator-smart as my cat, but it works fine here unless I've
missed something quite obvious to you but not me (a distinct possibility).
The only problem (which I hold as a non-problem personally) is namespace
collisions since the subdirectories are searched as you (well, I, anyway)
would expect --
sys6:[tex.inputs]
sys6:[tex.inputs.a*]
...
sys6:[tex.inputs.z*]
so that files in the current user directory have precedence over files in
the logical root directory which have an alphabetized preference over
subdirectories. The VMS subdirectory searching algorithm appears to be
consistent with expectations as far as I have seen.
As far as namespace collisions, in maintaining the CTAN, I have come across
only one anal orifice who refused to rename their file once they were made
aware of its non-uniqueness once it was pointed out -- authors generally
are willing to work with you (or have been for me anyway) once they are
aware that their work fits into a larger literature of related works. One
significant benefit of the CTAN is that you can check for such collisions
up front (I handle about 20 requests/week about availability of names,
etc.).
--George (in fear quite possibly of a horribly hosed installation)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 15:24:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 Aug 1994 16:24:54 -0400
From: len@ora.com (Lenny Muellner)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408122024.QAA14254@ruby.ora.com>
To: twg-tds@shsu.edu
Subject: Norm's on vacation...
Folks,
your chairman is away until 8/22. you won't hear a word
from him unless they've wired the bay of fundy for email!
See ya,
norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 Aug 1994 18:35:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 13 Aug 1994 01:35:13 CET +0100
From: SPIELER@linac.ikp.physik.th-darmstadt.de
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00982DD4.07225D7A.31103@linac.ikp.physik.th-darmstadt.de>
Subject: Re: the font hierarchy, for the umpteenth time
George Greenwade wrote:
> Ummmm, Phil. Since we moved to OpenVMS 5.5-2 (VAX; not tried on AXP) and
> now under 6.1 (as well as under 6.0), I have used the defintions
> $ define/system/executive/translation=concealed/name=no_alias tex_root -
> sys6:[tex.]
> $ define/system tex_inputs tex_root:[inputs...]
> without a problem (as far as I can tell, anyway). I'll openly admit that
> it's a dangerous thing to let someone like me setup things as I'm about as
> computer operator-smart as my cat, but it works fine here unless I've
> missed something quite obvious to you but not me (a distinct possibility).
>
I would like to know, which TeX program does George use on VMS (and where
did he get it from).
The VMS TeX, as found on CTAN does NOT like
$ define tex_inputs tex_root:[inputs...]
as I have just tested.
As far as I know, this kind of recursive autosearch directory specification
works with DIR and BACKUP commands, only.
(But I would like if someone corrects me...)
> [... rest deleted ...]
> --George (in fear quite possibly of a horribly hosed installation)
>
Chistian Spieler <spieler@linac.ikp.physik.th-darmstadt.de>
================================================================================
From owner-twg-tds@shsu.edu Sat, 13 Aug 1994 09:36:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 13 Aug 1994 10:37:38 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408131437.AA05587@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
The only difference between fonts/<filetype>/<source>/<typeface> and
fonts/<source>/<typeface>/<filetype> as far as most sysadmins are
concerned is that at the moment one of them is feasible and the other
one isn't.
The key phrase there is ``at the moment''.
The people filetype/source/type will help are those with
(1) few fonts (e.g., just CM + other Metafonts)
(2) deficient implementations
Do we really want to base our future standard for all TeX's on this
group? I have no idea how many people are in it, and I don't think
anyone else has any recent facts on that, either, just speculations,
despite Alan's claim of ``most sysadmins'' above.
As time goes by, people will tend to install more fonts, not fewer. It
is much easier to install (and de-install) fonts when all the related
files are in one directory. It also easier to make copies of everything
about a font for sharing with other, etc. And it's a lot easier (and
faster) to type `ls' than to type `ls */*/<typeface directory name>',
especially since the typeface directory names are far from obvious,
canonical, or easy to remember.
These are all common things to do. At least they are for me, and for the
people who send mail to me. My experience is that users poke around in
the fonts directory often, also.
As Phil or someone said, this is essentially the same argument as for
using texmf/package/{tex,fonts,...} instead of
texmf/{tex,fonts,...}/package. I gave in on texmf/package because
there's no experience with it. But there is lots of (positive)
experience with fonts/source/typeface, so I'm not willing to give it up.
Finally, people with small personal installations will be the least
inclined to change anything anyway, hence they are the people the TDS is
least likely to make inroads on. So making them the number one
beneficiary seems pointless to me.
ls-R or some equivalent is necessary on
sites which have large numbers of files.
Anyone with a LaserJet 4 who wants to use both the PostScript and HP
builtin fonts will have too many directories to get good
performance. I think there are lots of such people, and lots of them are
in your category of ``having few files'' now -- they just don't know
what's possible.
This is the point at which disk searches on my recent-vintage 486 and/or
DECsystem 5000/240. With just the standard 35 PostScript fonts, things
were speedy enough without ls-R. With anything more, not.
================================================================================
From owner-twg-tds@shsu.edu Sat, 13 Aug 1994 14:47:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 13 Aug 1994 14:47:07 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00982E42.A7D14C04.71@SHSU.edu>
Subject: Re: the font hierarchy, for the umpteenth time
My apologies to Phil and the list -- serious egg on the face. The
recursive, generated from native VMS directory, searching has been on my
wish list for some time. Instead, the ugly -- but workable -- hack I have
been using is a DCL command procedure to get in lotsa charachers. It did
require 5.5-2 to allow (at least) one of the lexicals to work as one would
expect. It is attached below for your amusement. Guess I need to look
more closely at the system startup files before I go off like I did.
Again, my most heartfelt apologies.
--George
===========================================================================
$!! Program Name : TEXINPUTS.COM
$!! Original Author : BED_GDG
$!! Date : 31-OCT-1993
$!! Program Description : Create TEX_INPUTS as a recursive tree from
$!! : TEX_ROOT:[INPUTS]
$!!
$ COUNT = 0
$ LOGICALCOUNT = ""
$ PATHNAME := TEX_ROOT:[INPUTS]
$LOOP:
$ COMMA = ""
$ IF PATHNAME .NES. "" THEN COMMA = ","
$ DIRNAME = ""
$ DIRNAME = F$SEARCH("TEX_ROOT:[INPUTS...]*.DIR")
$ IF DIRNAME .EQS. "" THEN GOTO COMMON_EXIT
$ ADDNAME = "TEX_ROOT:''F$PARSE(DIRNAME,,,"DIRECTORY")'"
$ ADDNAME = F$EXTRACT(0,F$LENGTH(ADDNAME)-1,ADDNAME)
$ ADDNAME = ADDNAME + ".''F$PARSE(DIRNAME,,,"NAME")']"
$ PATHNAME = PATHNAME + COMMA + ADDNAME
$ IF F$LENGTH(PATHNAME) .GE. 100
$ THEN COUNT = COUNT + 1
$ PATH'COUNT = PATHNAME
$ DEFINE/SYSTEM/NAME=NO_ALIAS TEX_PATH'COUNT 'PATHNAME
$ LOGICALSTRING := 'LOGICALSTRING "TEX_PATH"'COUNT'","
$ PATHNAME := ""
$ ENDIF
$ GOTO LOOP
$COMMON_EXIT:
$ DEFINE/SYSTEM/NAME=NO_ALIAS TEX_INPUTS 'LOGICALSTRING 'PATHNAME
$ EXIT
================================================================================
From owner-twg-tds@shsu.edu Sat, 13 Aug 1994 15:53:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 13 Aug 1994 15:53:21 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00982E4B.E87B7884.42@SHSU.edu>
Subject: Re: the font hierarchy, for the umpteenth time
More or less a philisophical reply to Karl's post of Sat, 13 Aug 1994
10:37:38 -0400:
>....
> Do we really want to base our future standard for all TeX's on this
> group? I have no idea how many people are in it, and I don't think
>....
> Finally, people with small personal installations will be the least
> inclined to change anything anyway, hence they are the people the TDS is
> least likely to make inroads on. So making them the number one beneficiary
> seems pointless to me.
I thought that one of the underlying goals was extensibility -- to design
something useful today as a target, recognizing that there may be a few
implementation-specific changes recommended. As far as Jodie User, if it
works as it is, (s)he won't give a rat's tail about any of this at the
moment -- the concept of a TDS to these users is about as close to mental
masturbation as we can get. I agree wholeheartedly with Karl here, with
one very important caveat -- the TDS won't make significant inroads with
the small installation group, in the short run. In a longer view, if most
of the matters now before us can be worked out with a
minimally-objectionable answer and provide a non-moving and recognizable
target for developers, the TDS will most benefit every site, regardless of
size, experience, expertise, operating system, etc., etc., ad nauseum.
Recognition that there will be objections has to be made up front if for no
other reason than TeX and friends is a remarkably complex topic -- more so
than anything else I am aware of (and I openly admit ignorance). There is
a need to minimize the objections and not run off or pout because our
favorite pet is not included precisely as we, in our individual
omnipotence, think it should be. Rather, thrash out the differences and
find a least objectionable, but workable and extensible, answer. This may
very well be the whole point of this exercise -- and it is one which TeX,
as a whole, could reap major long-term benefits from.
--George
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 Aug 1994 05:34:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 14 Aug 1994 06:35:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408141035.AA13383@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: fonts ** N
Sorry, but I just thought of another argument to bolster my
sagging position: if the worry is over small installations
(the only ones which can do disk-based subdirectory searching),
then I claim that such small installations *can* search all
the pk/ (etc.) directories when searching for a tfm file,
because (by hypothesis) there are only a few directories anyway.
Searching 5 directories vs. 15 or 20 is meaningless.
Does this convince any of the skeptics?
I don't really expect you all to believe me.
*I* didn't believe ls-R was necessary, until
I started needing enough directories. But now I'm convinced.
Probably every implementor/installer will have to go through
the same sequence :-)
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 Aug 1994 09:37:35 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Mon, 15 Aug 1994 15:35:20 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:255420:940815143534"@cl.cam.ac.uk>
> hierarchy, which I choose not to follow: but through the use
> of DOS variables I map my preferred structure into his. Any user
> can do likewise. And an implementor/maintainer who becomes overly
get real, Phil. most DOS users do *not* understand environment
variables...
>
> No. VMS allows (for example) $ Define TeX_Inputs TeX_Root:[TeX.Inputs...]
> but the implementations do not necessarily honour it; to do so, they
> would need to use Lib$Find_File, which I think none yet do.
sounds like it would be a useful addition to VMS TeX?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 Aug 1994 10:54:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 AUG 94 16:28:52 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <21007AEB_002FDEE8.00982FE332862292$17_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> get real, Phil. most DOS users do *not* understand environment
>> variables...
I know that that is the assumption on which 4TeX and the NTG CD-ROM are
predicated, but it is not a view to which I subscribe; a Dos user
_needs_ to understand environment variables. A Windows user may be able
to get through life without ever getting his fingers dirty, but the same
does not and cannot obtain for Dos users per se.
>> sounds like it would be a useful addition to VMS TeX?
only once we agree that (a) recursion is a Good Thing, and (b) that
we are prepared to go with whatever semantics each operating system
ascribes to the concept of recursion.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 Aug 1994 15:21:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 Aug 1994 22:22:14 CET +0100
From: spieler@linac.ikp.physik.th-darmstadt.de
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: spieler@linac.ikp.physik.th-darmstadt.de
Message-ID: <00983014.90CA6E95.31506@linac.ikp.physik.th-darmstadt.de>
Subject: Re: the font hierarchy, for the umpteenth time
> Date: Mon, 15 Aug 1994 15:35:20 +0100
> From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
> Reply-To: TWG-TDS@SHSU.edu
> Message-ID: <"swan.cl.cam.:255420:940815143534"@cl.cam.ac.uk>
>
> > hierarchy, which I choose not to follow: but through the use
> > of DOS variables I map my preferred structure into his. Any user
> > can do likewise. And an implementor/maintainer who becomes overly
> get real, Phil. most DOS users do *not* understand environment
> variables...
> >
> > No. VMS allows (for example) $ Define TeX_Inputs TeX_Root:[TeX.Inputs...]
> > but the implementations do not necessarily honour it; to do so, they
> > would need to use Lib$Find_File, which I think none yet do.
> sounds like it would be a useful addition to VMS TeX?
>
No, in my eyes this should not be implemented into TeX (and friends).
When recursive directory searching is really wanted, one should
better develop something in the direction of George Greenwade's
command procedure. Such a command procedure should set up the
different file search lists needed for TeX once at initialization time
of the TeX system.
The VMS logical names should remain to be valid VMS path specifications,
as they are now.
This has the BIG advantage that the users can use them as shortcut
path specifications to access font or macro files with any program
(to edit, view, type, print, copy, rename, delete, etc. them), not
just with those TeX related tools that have special built in support
to handle some kind of "recursion pattern strings".
(This nice feature is unique to the VMS implementation of TeX, but
is very useful.)
Additionally, it is much easier to adopt a DCL command procedure to
future changes in the directory tree layout, than having to
modify the sources of the TeX system programs.
In DCL, or as a separate "TeX paths setup program", it should not be
too difficult to implement a selectable "priority scheme", similar
to the WEB2C "ls-R" feature.
> sebastian
Christian Spieler <spieler@linac.ikp.physik.th-darmstadt.de>
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 05:32:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 16 Aug 1994 11:32:20 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:062900:940816103227"@cl.cam.ac.uk>
> predicated, but it is not a view to which I subscribe; a Dos user
> _needs_ to understand environment variables. A Windows user may be able
> to get through life without ever getting his fingers dirty, but the same
> does not and cannot obtain for Dos users per se.
>
but it does. you cannot pretend that people change their autoexec.bat
or know how to write .bat files. having just started work in a company
which is all PCs, i now see it at first hand. from where i sit i can
see 20 PC users, none of whom knows what an environemnt variable is,
all of whom may have to use TeX next week.
but this is not a TDS subject, perhaps
> only once we agree that (a) recursion is a Good Thing, and (b) that
> we are prepared to go with whatever semantics each operating system
> ascribes to the concept of recursion.
the TDS list has thrashed (a) to death. i say its agreed. wrt b), can
you elucidate what devious idea you have in mind? we are *not* talking
recursion, we are talking subdirectory searching.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 06:02:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 AUG 94 12:02:01 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <21007C8C_000E3E20.00983087157B7ED2$21_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> but this is not a TDS subject, perhaps
Agreed: moved to private correspondence.
>> the TDS list has thrashed (a) to death. i say its agreed. wrt b), can
>> you elucidate what devious idea you have in mind? we are *not* talking
>> recursion, we are talking subdirectory searching.
Unless you want to argue that all recursion has an iterative representation
(with which I would agree), then subdirectory searching and recursion are
one and the same thing in this context. If I use Lib$Find_File on
TeX_Root:[TeX.Inputs...]CropMark.TeX, then I am _forced_ to use the semantics
of Lib$Find_File, which regardless of whether it performs a breadth-first or
depth-first search will ultimately use recursion (or an iterative straightening
thereof) to enable it traverse all branches of the tree. The problem is,
Lib$Find_File _may_ use breadth first, while ls-R (which term I finally
understand: thanks, Karl) _may_ use depth first. If the semantics differ,
then the search algorithm differs, and if the search algorithm differs, then
two different installations may produce different results if two or more copies
of CropMark.TeX exists in the search tree. Since the whole concept of TeX is
predicated on total consistency across sites, we would be grossly violating
the underlying precepts if we allowed different search algorithms on different
operating systems.
Therefore, whilst I still have considerable reservations about recursion
subdirectory searching at all (because, having read much of the correspondence,
I fear we are seeking an acceptable solution rather than the correct
solution), if we _are_ going to recommend (`mandate' is too strong)
use of this technique, then we must also ensure that the recursion/search
algorithm is built into TeX (or at least is operating-system independent).
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 07:47:27 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 16 Aug 1994 13:48:04 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:120390:940816124820"@cl.cam.ac.uk>
> thereof) to enable it traverse all branches of the tree. The problem is,
> Lib$Find_File _may_ use breadth first, while ls-R (which term I finally
> understand: thanks, Karl) _may_ use depth first. If the semantics differ,
ok, i understand your issue
> subdirectory searching at all (because, having read much of the correspondence,
> I fear we are seeking an acceptable solution rather than the correct
elucidate please?
> solution), if we _are_ going to recommend (`mandate' is too strong)
> use of this technique, then we must also ensure that the recursion/search
> algorithm is built into TeX (or at least is operating-system independent).
i thought the TDS mandated the search algorithm? if not, it can, so
whats the problem?
re: building it into TeX a) you can put it on the NTS TODO list, b)
its more than TeX at issue, it includes non-TeX software
(perhaps). someone tell me how to instruct ATM to do subdirectory
searching, pliz.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 08:01:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 AUG 94 14:01:14 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <2100A4D9_002FE7D0.00983097BCF5FEF2$19_4@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> > subdirectory searching at all (because, having read much of the correspondence,
>> > I fear we are seeking an acceptable solution rather than the correct
>> elucidate please?
Two themes: 1) Should <package> be big- or little-endian? The group seem
to feel that big-endian is correct, but that since extant implementations
tend to make it little-endian, there is little or no chance of persuading
them to change. 2) Should the search strategy by influenced by the
location of the current file? There seems to be _some_ (by no means universal)
support for this, but again we seem to be ruling it out as ``too difficult /
too different''.
** P.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 08:08:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 Aug 1994 08:08:18 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00983066.7056BFA4.147@SHSU.edu>
Subject: Re: the font hierarchy, for the umpteenth time
On Tue, 16 AUG 94 12:02:01 BST, Phil Taylor <CHAA006@VAX.RHBNC.AC.UK> posted:
> Therefore, whilst I still have considerable reservations about recursion
> subdirectory searching at all (because, having read much of the
> correspondence, I fear we are seeking an acceptable solution rather than
> the correct solution), if we _are_ going to recommend (`mandate' is too
> strong) use of this technique, then we must also ensure that the
> recursion/search algorithm is built into TeX (or at least is
> operating-system independent).
Not to be offhand here, but isn't it impossible to build this (or anything
else, for that matter) "into TeX" at this point in time?? I thought the
idea was a consistent, platform-independent subdirectory searching
recommendations -- although how this comes about is operating-system
specific. How VMS does it may very well differ from how DOS or various
flavors of Unix or how OS/2 does it or anything else -- the "how" is not at
issue; what is at issue, or at least so I thought, was and is (a) such a
mechanism should be possible (to which I believe we are agreed at least in
principle) and (b) what pathing should be supported in such a search.
The (b) item is indeed something which has yet to be aired very much -- my
assumption was something which I thought was of the structure:
1. base
2. first subdirectory of base
3. second subdirectory of base
5. first subdirectory of second subdirectory
6. second subdirectory of second subdirectory
4. third subdiretory
in the sequence indicated by the numbers on the LHS. I don't know if this
is breadth or depth (I assume this is breadth but am unsure), but that was
what I thought we were talking about. Or am I mistaken? Whichever, I
think we all agree that this process should be the same across everything
as the recommendation or we are indeed hawking two (or more) possibly
distinct behaviors.
--George
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 08:16:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 AUG 94 14:16:15 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <2100949B_002367C8.00983099D648ED72$17_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Not to be offhand here, but isn't it impossible to build this (or anything
>> else, for that matter) "into TeX" at this point in time??
No! It has to go into the SYSDEP bit, of course, and the actual
implementation will, of course, be OS-dependent (whence SYSDEP),
but I see no reason why we cannot propose a reference model.
>> Whichever, I
>> think we all agree that this process should be the same across everything
>> as the recommendation or we are indeed hawking two (or more) possibly
>> distinct behaviors.
Here we are in complete agreement. * P.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 08:59:09 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qaP3E-000075C@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 16 Aug 94 14:59 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>The people filetype/source/type will help are those with
>(1) few fonts (e.g., just CM + other Metafonts)
>(2) deficient implementations
Yes. I think that covers about 95% of the installed TeX base...
>I have no idea how many people are in it, and I don't think
>anyone else has any recent facts on that, either, just speculations,
>despite Alan's claim of ``most sysadmins'' above.
This is one of the big problems about working in the TeX world... we
have no means of getting feedback. All we can do is work on
anecodatal evidence. My experience is that at the last three sites I
worked at, the TeX installation was uniformly ~4 years out of date,
and had nothing but the bog-standard LaTeX+TeX+CM+dvi*ps.
>These are all common things to do. At least they are for me, and for the
>people who send mail to me. My experience is that users poke around in
>the fonts directory often, also.
Yes. Nobody is doubting that
texmf/fonts/<source>/<family>/<type>/<file> is a nicer directory
structure to work with. The question is---is it so much nicer that
it's worth waiting the (??? insert your guess here ???) years before
all the major platforms support full subdirectory searching with
wild-cards that's needed.
>But there is lots of (positive)
>experience with fonts/source/typeface, so I'm not willing to give it up.
I've been running with fonts/<type>/<source>/<family> for over two
years now, and it works perfectly well. I think there's a grand total
of two users (including me) who ever look in our fonts directory...
>Finally, people with small personal installations will be the least
>inclined to change anything anyway, hence they are the people the TDS is
>least likely to make inroads on. So making them the number one
>beneficiary seems pointless to me.
On the contrary, my experience has been that the users who get their
TeX pre-installed from a company like Y&Y or Blue Sky, or who
regularly look for update disks from people like Andrew Treverrow, are
among the fastest to update.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 10:26:40 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 16 Aug 1994 16:27:16 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:191640:940816152725"@cl.cam.ac.uk>
>
> Two themes: 1) Should <package> be big- or little-endian? The group seem
> to feel that big-endian is correct, but that since extant implementations
> tend to make it little-endian, there is little or no chance of persuading
i dont want to speak for anyone else, but i am happy in my mind as to
what we propose
> them to change. 2) Should the search strategy by influenced by the
> location of the current file? There seems to be _some_ (by no means
> universal) support for this, but again we seem to be ruling it out
> as ``too difficult / too different''
its only just come up. to me, its over-complicated and not
needed. whats the application? the main need is that the current
working directory is saerched first, and thats true anyway.
sebastiab
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 10:47:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 AUG 94 16:46:22 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <2100990B_002FDED0.009830AECEAAA712$35_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> its only just come up. to me, its over-complicated and not
>> needed. whats the application? the main need is that the current
>> working directory is saerched first, and thats true anyway.
An author develops a whole suite of software: there are generic and
specific components; the generic appear higher in the tree, the
specific lower; a particular package is sufficiently complex that
it warrants a sub-tree of its own; modules in that sub-tree are
specific to the package, but the package also need to make reference
to more generic material which occurs higher up in the tree; ...
I don't think this is an artifical scenario, but a very real possibility: we
live in the age of module re-useability, and increasingly package writers will
exploit that concept. What I am trying to ensure is that our proposal is
capable of dealing with such suites of modular software, rather than being
predicated on the ``either it's here, or I don't care where it is'' philosophy.
** P.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 11:07:15 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 16 Aug 1994 17:07:49 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:211490:940816160806"@cl.cam.ac.uk>
if Phil's model is so necessary, how come my C compiler doesnt support
it? but i see there might be an issue. so what do you propose, phil?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 11:15:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 Aug 94 09:15:21 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408161615.AA01647@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Here I go again...
The ugly head of pragmatism seems to be surfacing more and more in these
discussions, so I think it may be appropriate for me to inject my own
view of the underlying realities. As I see it, there are several reasons
for the TDS effort, and they may include some conflicting goals:
1) Folks with large TeX installations want to be able to administer
the masses of files in some sane way, to avoid conflicts between
naming, and to have TeX and related programs search for their
files in a reasonable amount of time.
2) Folks with small TeX installations just want something that isn't
excessively hard to set up and maintain.
3) Folks that distribute TeX software want to be able to document
installation and upgrade operations as succinctly as possible,
and to receive a minimum of plaintive email and phone calls.
4) Folks that want to publish add-on CD-ROMs of TeX fonts want to
be sure that they will be usable, with minimal effort, on a
wide range of TeX sites. (Ditto on the plaintive inquiries :-)
Now, the peculiar thing here is that absolute simplicity is not a strong
criterion. If I pick up a distribution from the CTAN and can drop it
into my system without pain or problems, I don't CARE how much thrashing
the installation routine is forced to do. Look at the other big freeware
systems; they may install automagically, but they aren't all that simple.
And, judging from the "Trouble with CTAN" thread on comp.text.tex, there
are a fair number of dissatisfied TeX administrators out there. Much of
the problem could be alleviated by better documentation and/or fancy
installation scripts, but the *underlying* problem is a lack of naming
consistency. And, presumably, this is what the TDS aims to fix.
Presuming that the TDS succeeds in reaching concensus, however, we still
have the little problem of getting administrators to adopt the results. I
suggest that this could be greatly eased by the provision of some generic
administration scripts. If the distribution AND installed directory
structures are well understood (a bit of Fascism on internal structure is
FINE in this sort of thing), it would be no big problem to hack together
scripts for DOS, Mac, UNIX, VMS, and any other popular operating systems.
Although I may regret saying this, I think I could volunteer to do the
UNIX scripts, as well as a set of "script writers notes". I'm too rusty
on DCL and BAT files to make any offers there, and I beg off on Hypercard,
as well. But *somebody* out there is surely able to tranliterate a few
dozen lines of shell scripts into these other languages, and that might
well handle the installation problems for 90% of the TeX administrators.
Please understand that I'm not proposing to completely automate all of TeX
administration. My focus here is the installation, update, and removal of
sets of files, with minimal effort to the administrator, and no damage
to the host machine.
Finally, I'd like to make a vote in favor of cleanliness, efficiency, and
generally "doing things right", even if it requires that some packages be
hacked a bit. Solving the problem of TeX file management is important to
the future of TeX, and it is ultimately going to pay back any development
effort many times over. I think most developers, both commercial and
freeware, will be so happy to have a standard that they will jump at the
chance to upgrade their packages. The remainder can be bullied into it,
worked around, or simply ignored.
-r
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 11:28:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 Aug 1994 18:29:51 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
To: TWG-TDS@SHSU.edu
Message-ID: <01HFZJ6Z164Y99DMO5@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
>> Shall the search path depend on the location of the current file?
I just say no. I made some bad experiences with a computer algebra system
which claims to able to change default in an os-independant manner. One
package I have to use works only under DOS and not even under Windows, the
other works only if I call it from one directory above and not otherwise.
I don't want to see this with a TeX macro package.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 11:43:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 AUG 94 17:43:10 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <2100A688_000E29E8.009830B6BE878352$17_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> if Phil's model is so necessary, how come my C compiler doesnt support
>> it?
I shall refrain from biting on this one, just so that we can concentrate
on the issue at hand...
>> but i see there might be an issue. so what do you propose, phil?
What I have already proposed: that the search algorithm support the concept of
a `current file', and that recursion (`searching') be defined to start at the
location of the current file (the `current location'). If it's not found in the
current location, a breadth-first recursion is commenced, using the current
location as root; if it's still not found, then the recursion (directory) stack
is unwound, layer by layer, and the breadth-first recursion again carried out
with each unwound layer as a temporary `current location'. The current file
is defined as the file which is actually \inputting the file being sought.
This allows any package to preferentially load from (1) its own directory,
followed by (2) any directly-owned sub-directories. If the required file
is not found in either (1) or (2), the directory stack is unwound, level
by level, and the search strategy repeated. This in turn means that any
package which forms one of a suite of related packages will preferentially
satisfy any unresolved references (after fully traversing its own sub-tree)
from increasingly more generic directories, eventually (if it's not found
in the parent or `suite' branch of the tree) leading to a full breadth-first
search of the entire `TeXinputs' tree.
[I have just seen J"org's message and I understand his reservations, but
would respectfully point out that the whole proposal is to implement
this _properly_, not in a manner which is OS-dependent or kludged in
any way]
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 Aug 1994 11:49:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 Aug 1994 18:50:41 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
To: TWG-TDS@SHSU.edu
Message-ID: <01HFZJAY1RAQ9KMCFS@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
>> Recursive searching
There is a point I don't understand exactly, which is the difference
between ,,recursive searching on the disk'' and ,,ls-R''. Can someone
explain this to me (maybe privately)?
With recursive searching, there are several obvious questions, maily what
is the _exact_ searching order?
Under VMS and UNIX, alphabetic searching is used, and some kind of
backtracking algorithm (I think, this is what Phil calls depth searching).
A slight difference is, that if a directory contains both files and
subdirectories, VMS $dir [...] first finds the files in the directory
and than goes into the subdirectories, whereas UNIX $ls -R is stricktly
alphabetically. This slight difference can be cured by the prescription
(which makes sense anyhow):
Any directory shall contain either files or subdirectories, but not both.
Other OSes may use other algorithms (search order by date, for example, or
user-defined search order) -- what to do with them?
And if we do recursive searching in alphabetical order, how to order the
files in a way, that the most often needed files are hit first? The only
OS-indedendent way I can imagine, is to prefix to digits ranging from 00
to 99 which depend on the demands of the site, to optimise searching. Not a
very promising perspective, I admit. And it throws us back to 6+3.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Aug 1994 03:34:11 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 17 Aug 1994 09:32:44 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:245090:940817083302"@cl.cam.ac.uk>
Phil's scheme has a certain baroque charm, I suppose. But I dont buy
it. I say Keep It Simple. It seems to me that it flies in the face of
accepted usage of search paths in all the applications I can think of,
and I dont want TeX (yet again) being isolated.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Aug 1994 06:00:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 AUG 94 11:59:39 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <2100A462_00323E88.0098314FEB541352$19_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Phil's scheme has a certain baroque charm, I suppose. But I dont buy
>> it. I say Keep It Simple. It seems to me that it flies in the face of
>> accepted usage of search paths in all the applications I can think of,
>> and I dont want TeX (yet again) being isolated.
My aim was not, I willingly agree, to `keep it simple'; I see no need
whatsoever for simplicity in implementation, provided that there is simplicity
in usage. What I _was_ aiming for was a totally logical approach to the
problem of file location, one based on the needs of package writers and the
expectations of a `reasonable user', rather than on the collating sequence of
a millenia-old alphabet or the peculiar proclivities of the author of some
arcane operating system.
I argue that `specific first, then increasingly more generic' is
the most logical approach, and I have so far seen no counter-argument to this.
But whether or not we adopt my proposal is neither here not there: what matters
to me is that we _debate_ it, and debate other similar proposals, and other
radically different proposals, until we agree that the search-algorithm which
we ultimately propose is the best possible algorithm, and the one that will
meet the needs of our users for many years hence. What I want to avoid at
all costs is adoption of some pre-existing search algorithm that only
partially meets those needs. Let's get it _right_.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Aug 1994 07:04:43 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 17 Aug 1994 13:00:06 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:044220:940817120023"@cl.cam.ac.uk>
i am perfectly happy with Phil's principle of `lets get it right'. i
just dont go down the `local search followed by general search'
concept. i'd much rather separate the general case (subdirectory
searching) from the specific software enginerring model you might
adopt, for which i'd use the TEXINPUTS. If i want the subdirs of the
working directory searched first, i'd (in unix) set it to
.//:
and hey presto. or maybe i could adopt a principle that i put things
in ./lib, eg
./lib:
but i do agree there is a case to answer - should searching for 2nd
and subsequent files depends on where you found the first? My answer
to that is that i'd like a choice. if (for instance) @ in a path spec
meant "replace @ by the directory of the current input file', then i
could say
.:@/lib:/usr/local/lib/texmf/tex/latex//
if that was how i wanted to work. the search algorith is the same
(simple) but the flexibility is there for power users. maybe Karl
could comment as an implementor which such a scheme is trivial to
implment? would it meet your needs, Phil? i think it has greater
generality than the fancy search algorithm
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Aug 1994 08:37:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 AUG 94 14:37:35 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <210098C3_0024FA68.00983165FB96F872$21_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
[SPQR's comments]
NOW we're getting somewhere! A unique specifier for (a) the working
directory (the directory which was the user's current directory when
TeX was launched), another for the current directory (the directory
from which TeX is currently \inputting a file), and perhaps others
of which we have not yet thought: these, together with a general
mechanism for specifying (a) `and all sub-directories thereof',
(b) `and all parent directories thereof' (and _their_ sub-directories?
perhaps not) provide a very elegant mechanism for tree-traversal when used
to define TeX_Inputs or w-y-h. But we still need to either agree a recursion
algorithm (breadth-first, depth-first, ???) or to have different specifiers
for each algorithm. The last seems like overkill to me. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Aug 1994 13:21:35 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 19 Aug 1994 11:22:30 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408191822.LAA25787@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TUG'94: changes to TDS...
You are quite right about the numbers of people actually
doing customization, but I try to keep my own
directory structure as close as possible to what
I still occasionally send out on UnixTeX tapes, and
I want that to be the TDS directury structure if it
can possibly be managed. For one thing, it means
that I am constantly exercising software against that
structure, and can really respond when claims are made
that "It doesn't work." Since I do a lot of work on
a Sun 3-50, I can really judge whether the claims that
it is impossibly slow to do full directory searching are
true. (With a really wide range of fonts, speed is
a real problem, so that accelerator strategies are
quite important.)
Anyway, I wait to see what stabilizes, and I will once again
try to arrange my working directory tree to match, and
see how it affects my real or perceived performance here.
I can live with the earlier specification of tfm/ etc.
I will hate it, but I can live with it.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Aug 1994 13:46:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 19 Aug 1994 11:47:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408191847.LAA29046@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: the font hierarchy, for the umpteenth time
A couple of messages have picked up Karl's mention of the
Monotype CD, but the use of that is far less likely
than the Bitstream 500 Font CD which is offered through
Egghead in this region. Fonts are not locked, they
are in ISO-9660 directories. They are named with an
appallingly uninformative convention, but the 1107a___.inf
file gives you access to the true name even on a
system that can't convert to the full FontName as a filename.
I mention this because Karl's example of a user suddenly
expanding from a CMR + LW35 + Charter + Utopia + Nimbus
font library to 500 fonts (Really good ones too---Caslon540
*ALL* of GoudyOldStyle, 20 weights of Humanist) is right
around the corner. The Bitstream CD-ROM is about $32.00
So the font directory problem is likely to explode in our faces
very soon if we don't get it right. I naturally prefer
Karl's arguments, and I think we had better assume minimum
font libraries of 200 or so named typeface families as
the coming thing. The habits of users who stick with
public metafonts and LW35 should not govern our final
decision. Font junkies of the world, unite!
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Aug 1994 15:15:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 19 Aug 1994 13:16:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408192016.NAA06794@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
One of the special virtues about the way Karl went about
subdirectory searching is that it is NOT built into
TeX, TeXware, MF, MFware or anything else in the
suite of programs associated with TeX. It is a separately
compiled library which, once built, can be linked to
many programs. Are we dealing with any operating system
that does not provided for library link and load?
I hope not. If you haven't had the privilege of working
in a kpathsea environment, you probably don't realize
how liberating it is to know that gftodvi, tftopl
etc. etc. will all behave the same way.
Some of the recent discussion, when it gets to a consideration
of what Karl's approach does, seems to lose sight of the fact
that it is incorporated in a library, not into the
main modules of TeX etc.
The question whether a good directory search can be managed
in DOS, Macintosh, VMS or whatever is interesting, and I
don't know the answer, though Karl seems to think
it can be managed in DOS at least. But the only "modification"
to TeX involved is some stubs in the system-dependent
area of the program that will be linked to a library at
load time.
This had better be clear before we get dragged down
a side-road about what can legitimately be "built into TeX."
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Aug 1994 15:19:03 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 19 Aug 1994 13:20:03 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408192020.NAA07058@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>The people filetype/source/type will help are those with
>(1) few fonts (e.g., just CM + other Metafonts)
>(2) deficient implementations
Yes. I think that covers about 95% of the installed TeX base...
>I have no idea how many people are in it, and I don't think
>anyone else has any recent facts on that, either, just speculations,
>despite Alan's claim of ``most sysadmins'' above.
I have already sent a message about the effect I think things
like the $32.00 Bitstream 500 font CD-ROM is going to have.
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Aug 1994 15:44:49 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 19 Aug 1994 13:45:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408192045.NAA09641@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: the font hierarchy, for the umpteenth time
NOW we're getting somewhere! A unique specifier for (a) the working
directory (the directory which was the user's current directory when
TeX was launched), another for the current directory (the directory
from which TeX is currently \inputting a file), and perhaps others
of which we have not yet thought: these, together with a general
mechanism for specifying (a) `and all sub-directories thereof',
(b) `and all parent directories thereof' (and _their_ sub-directories?
I would do that with a temporary reset of my environment variables.
It is not that I can't imagine having an input file side-by-side
with another input file and yet having a file with the same name elsewhere,
but if I did that, I would be satisfied to associate it with
a special TEXINPUTS path. Why on earth make it a general problem
for file searching? It's hard enough comtemplating the proliferation
of files all named indiscriminately cmr10.pk
Pierre
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 05:29:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 20 Aug 1994 06:30:47 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408201030.AA04895@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: path searching necessities
NOW we're getting somewhere! A unique specifier for ...
Oh, my.
I'm as much of a fan of ``get it right'' as the next person, but given
the absolute lack of any practical experience with these schemes, I
don't see how we can propose them as a standard for everyone to
implement. Especially when the search schemes are utterly unlike any
existing way -- not just in TeX, but anywhere -- of doing path
searching. Subdirectory searching was a triviality by comparison.
I can see the utility of searching in ``near'' directories first. But
let's not try to specify it absent any experience, ok? The place to
experiment with path searching schemes is not in a document purporting
to define the TeX hierarchy directories, but in new versions of
software. There is no reason why the TDS can't be revised if some of
these features (or others) become widespread and worth mandating in the
future. But we can't mandate them in advance.
I suggest a simple, rather than complex, set of requirements for the
subdirectory searching algorithm: (1) a doubled directory specifier
(e.g., //) at the end of a path means recursively search all
subdirectories; (2) searches through many (dozens to hundreds) of
subdirectories must be acceptably fast [this is the general way of
saying you have to have something like ls-R].
That's all. Nothing about foo//bar or other wildcards (I *never*
suggested that for the standard, so whoever thinks I'm arguing for it,
banish the thought from your mind!).
Nothing about the subdirectory order. Despite various claims here that
the order is this or that, I can tell you that, with kpathsea, the order
is *unpredictable*. It's not alphabetical. It's not even strictly
directory order (which is unpredictable enough). It's not necessarily
breadth-first or depth-first, either.
The reason why it's so ill-defined is that *it just doesn't matter*.
The only feasible way to solve the many-files-with-the-same-name problem
is either to (a) change the names (duplicate checking should happen when
something is put into CTAN), or (b) put the directory you want searched
first first (e.g., $TEXMF/tex/latex2e//:$TEXMF/tex//).
Of all the recent comments, I find Rich's the most apropos:
I think most developers, both commercial and
freeware, will be so happy to have a standard that they will jump at the
chance to upgrade their packages.
I couldn't agree more. Let's stick to getting a directory standard, not
experimental path searching.
(By the way, Rich, I wrote an installation script off the top of my head
for Barbara for a proof-of-concept a while back -- should be in the archives.)
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 05:29:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 20 Aug 1994 06:30:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408201030.AA04903@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Back to the font hierarchy question -- filetype/source/family
vs. source/family/filetype. Responding to Alan, here. I still can't seem
to make myself understood.
Nobody is doubting that
texmf/fonts/<source>/<family>/<type>/<file> is a nicer directory
structure to work with
I never heard this before. If so, then all I have to do is convince you
there are no practical ramifications, and the discussion will be done?
Coming right up...
1) at sites with ``many'' directories (PostScript + LJ fonts, say),
you have to use ls-R to get decent performance. So it doesn't matter
to them what the structure is.
2) at sites with ``few'' directories (just CM&co), there are, ipso
facto, few directories, and few directories are fast enough to
search. So it doesn't matter to them what the structure is.
3) there are no other sites (except those not running TeX, and very
happily too, no doubt :-).
Conclusion: it doesn't matter what the structure is. So let's go with
the nice one, ok?
More specifics on #2:
If a site has only the CM + latex fonts, there will be something like
two extra directories to search:
fonts/public/cm/tfm
fonts/public/latex/tfm
Trust me, searching two directories is not noticeable.
Even adding in the PostScript fonts:
fonts/adobe
.../{avantgar,bookman,courier,helvetic,ncntrsbk,
palatino,symbol,times,zapfding,zapfchan}/{pk,pk/cx,tfm,vf}
only brings us to 20 extra directories -- and both schemes would be
searching the other 31 directories. The difference between 31 and 51 is
not enough for noticeable effects on the search time on any kind of
reasonable hardware. (And if someone has a c.1980 disk, well, they can
just have an ls-R. No big deal.)
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 05:29:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 20 Aug 1994 06:30:49 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408201030.AA04911@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.EDU
Subject: package/filetype vs. filetype/package
Two themes: 1) Should <package> be big- or little-endian? The group seem
to feel that big-endian is correct, but that since extant implementations
tend to make it little-endian, there is little or no chance of persuading
them to change.
I'm assuming ``endian'' means whether we have $TEXMF/package/filetype or
$TEXMF/filetype/package.
The issue for me in finally agreeing with the current norm (no pun
intended :-), filetype/package, was not one of persuading people to
change. People will change, if there is a real benefit to be had.
The issue was the same as it is for the path searching. We have no
facts. No implementations actually use package/filetype. Thus, who knows
what the problems are? We can debate endlessly, but it's meaningless
without experience.
As we all know, the TDS has to be practical to be accepted. It has to be
*justified* in all its recommendations. Part of being justified is
having experience to back up the mandates. We don't have such
experience in this case. Thus, I feel the TDS cannot reasonably propose
that as the standard.
I should say that I am *totally* in favor of people *trying*
package/filetype, because I think it is technically better, more
extensible, and will serve us better for a longer time. But for me, the
no-practical-experience argument overrides everything else. A
standard is not a place to experiment, it's a place to codify.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 05:30:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 20 Aug 1994 06:31:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408201031.AA04999@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: rokicki@cs.stanford.edu
Subject: landscape mode fonts
Tom Rokicki has posed an interesting question -- what to do with PK
files built in landscape mode? The best I can think of so far is to have
a subdirectory landscape/ of the pk/mode directory, e.g.,
texmf/fonts/public/cm/pk/lqmedres/landscap/cmr10.180pk
The problem with this is that it means pk/lqmedres will potentially have
both PK files and a directory, but since I don't think landscape fonts
are terribly common, the burden should be on the landscape users, not
everyone else; and anyway, it's irrelevant with ls-R.
The alternatives I didn't like:
1) always have both portrait/ and landscap/ under mode/. This gives
everybody an extra directory level. Yuck.
2) Make up a mode name for the landscape version, and make it a sibling
directory. E.g., append an `l' to the regular name, truncating the
original name to seven chars if necessary, or I could make all the
canonical names be seven characters. The problem then is potential
name conflicts, and lack of consistent semantics -- lqmedresl isn't a
valid mode name. (And I can't make it be so without quadrupling the
amount of memory modes.mf takes, and people already complain about that.)
Thoughts? Comments? Suggestions?
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 05:47:36 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qbnyO-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sat, 20 Aug 94 11:48 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.EDU
Subject: Re: the font hierarchy, for the umpteenth time
>So the font directory problem is likely to explode in our faces
>very soon if we don't get it right.
Even for punters who've bought the Bitstream CD-ROM can still specify
their TEXFONTS as
.:$texmf/fonts/tfm/knuth//:$texmf/fonts/tfm/latex//:\
$texmf/fonts/tfm/adobe//:$texmf/fonts/tfm/bitstream//
and even on a system with only one level of subdirectory searching
they'll get the right results. Whether they get the results in
reasonable time is another matter :-)
The time when one-level subdirectory searching doesn't help much is
when you've got a large number of <source> directories.
All this discussion of searching strategies is fine and good, but is a
bit of a distraction from getting a recommendation shipped that is a)
not too horrible, b) is reasonably futureproof, and c) can be
implemented on the major platforms either now or in the near future.
Dons asbestos suit...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 06:06:34 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qboGf-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sat, 20 Aug 94 12:07 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, rokicki@cs.stanford.edu
Subject: Re: landscape mode fonts
>texmf/fonts/public/cm/pk/lqmedres/landscap/cmr10.180pk
I'm afraid on DOS systems that's:
texmf/fonts/public/cm/pk/lqmedres/landscap/180/cmr10.pk
and oh dear there went our ISO 9660 compliance... I think the only
solution is:
>2) Make up a mode name for the landscape version, and make it a sibling
> directory.
This should work with all the existing software such as MakeTeXPK etc.
if there's some way for dvips to change the mode based on the paper
format. This only makes a difference for printers with odd aspect
ratios... how many entries in modes.mf are we talking about?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 06:12:52 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qboMp-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sat, 20 Aug 94 12:13 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: path searching necessities
Shock horror exclusive agreement with Karl :-)
>I couldn't agree more. Let's stick to getting a directory standard, not
>experimental path searching.
Yes! Agreement with everything in this mail message!
Oh, apart from a small niggle...
>(1) a doubled directory specifier
>(e.g., //) at the end of a path means recursively search all
>subdirectories;
If we recommend this, we should couch it in terms like `for example,
on systems with environemnt variables, you could... blah...' On
the Mac the way that users specify folders in preferences files is by
selecting them with the standard file dialogue. (Well, apart from
strange applications like Alpha and OzTeX which do their best to look
like Unix programs...)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 12:22:43 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qbu6z-0006P5C@rsuna.crn.cogs.susx.ac.uk>
Date: Sat, 20 Aug 94 18:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>I never heard this before. If so, then all I have to do is convince you
>there are no practical ramifications, and the discussion will be done?
Yes. Good luck :-)
>Conclusion: it doesn't matter what the structure is. So let's go with
>the nice one, ok?
It only `doesn't matter' if we're prepared to mandate a directory
structure that can't be implemented at the moment. This is the core
of the discussion---whether the niceness of fonts/<source>/... is
worth insisting that all conformant implementations must have full
directory searching. Given that fonts/<source>/... is not that much
better than fonts/<type>/... I still maintain that we should mandate
something that's implementable with current technology.
... slight digression now follows...
>fonts/public/cm/tfm
>fonts/public/latex/tfm
Er... that's not how I'd arrange them! I'd have:
fonts/knuth/cmr/tfm
fonts/knuth/cmss/tfm
fonts/knuth/cmtt/tfm
etc. So we're talking about 10--20 directories just for the standard
fonts.
Argh... I've now realised that Karl and I have different ideas about
what a font family is... I've been thinking of them in LaTeX terms, so
CMR, CMSS and CMTT are different, and Karl's been thinking in
`filenames for fonts' terms, where CM is a font family.
Oh dear. Any opinions from anyone else? Similar question about
Lucida and Stone: should these be one large directory or lots of
little directories?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 Aug 1994 23:27:53 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 20 Aug 1994 21:28:54 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408210428.VAA11672@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
CC: n@cs.washington.edu, unixtex@u.washington.edu
Alan raises the question of what the range of a "font family"
is. I understand the background of his assumption that
CMR, CMSS, and CMTT are distinct font families, and the
peculiar nature of a "METAFONT" which is really something
quite different from GoudyOldstyle makes this a serious
problem.
BUT---the problems we are trying to manage would not seriously
occur if we kept strictly to "METAFONTS". They didn't become serious
until the enrichment of the font library through type1 fonts
began to be appreciated. The universe of type 1 font families
is vastly larger, and will always be vastly larger than
the universe of true METAFONTS.
Oddly enough, that may thoroughly justify Alan's point of view.
I am increasingly convinced that the attempt to declare a
seriffed font and a sans-serif font as members of the same
"family" was mistake. The parameters are so absolutely
altered in the METAFONTS that the kinship is very difficult
to observe. So Alan may be right in suggesting that
Computer Modern Sans Serif is a distinct family. To use my
recent discovery of the Bitstream fonts for an example.
American Garamond is a separate family from Classical Garamond
is a separate family from Elegant Garamond is a separate family from
their criminally defective black sheep cousin ITC Garamond---and none
of these includes anything like the range of transformations
that Computer Modern does.
But what do se do about a Knuth-style "family"? I would suggest
that we leave it alone as an anomaly. I do not think there will
be many attempts to associate seriffed and sans-serif fonts in the
same font family in the future. Mind you, I am not writing off
METAFONT; far from it. I just think that if a serious designer
undertakes another METAFONT, the effort to make it work in both
seriffed and sans-serif forms is probably not worth it.
I am suggesting therefore that we keep to the notion of "font family"
that the major foundries (Adobe, Bitstream, Linotype-Hell. Monotype, URW)
understand, but acknowledge that Computer Modern and Concrete, and
to some extent Pandora don't quite fit that model. Messy, but
not messy enough to cause serious trouble, I think.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 07:43:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 21 Aug 1994 08:44:06 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408211244.AA22887@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Now I think I see the problem, that I hadn't realized in my earlier message.
Is the crux of the matter whether the TDS specifies one-level or
fully-recursive subdirectory searching?
If so, now I finally understand your argument. I simply don't
agree. Yes, fonts/tfm/source/typeface would be searchable on systems
with only one-level searching, if the user puts all the sources into all
their font paths (TFMFONTS, VFFONTS, PKFONTS).
But that is a terrible thing to promulgate. Rather than have the TDS
encourage a poor specification that can be implemented without change, I
would rather have it specify something good, even if implementations do
have to change.
If I am the only one who feels this way, though, then fine, of course I
won't stand in the committee's way.
It's clear I should never have implemented one-level subdirectory
searching. And now that mistake might be cast into stone and affect
every TeX site (that cares to be TDS-compliant) forever? Sigh.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 07:43:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 21 Aug 1994 08:44:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408211244.AA22895@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
fonts/knuth/cmr/tfm
fonts/knuth/cmss/tfm
fonts/knuth/cmtt/tfm
Sigh. Haven't we agreed on anything? I thought we had settled on the
fontname-style names long ago.
I don't see the point of your scheme. Who benefits if the names are a la
LaTeX? Personally, I would hate it, since there would be, as you say,
zillions of directories, each with only a few files.
As for `knuth' vs. `public', are you going to have `billawal', `cugley',
etc., etc.? Why?
`typeface' for me has always been shorthand for `typeface family', and
my idea for typeface family directories has always been that whatever
the vendor collects under the same name, that's what goes in the
directory. Thus, all the Stone fonts are part of one typeface
family. Ditto all the CM fonts. Lucida is, sigh, an exception, because
of the !@#$%^ 8-character limitation, and thus Lucida Bright Expert
Italic etc. etc. etc. is too long, hence Lucida Bright has to be its own
family. But I still regard that as an exception to appease the DOS gods,
nothing more.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 07:43:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 21 Aug 1994 08:44:09 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408211244.AA22919@terminus.cs.umb.edu>
To: twg-tds@shsu.edu, rokicki@cs.stanford.edu
Subject: Re: landscape mode fonts
texmf/fonts/public/cm/pk/lqmedres/landscap/180/cmr10.pk
and oh dear there went our ISO 9660 compliance... I think the only
solution is:
The first level (texmf/) is not necessary on a CD-ROM.
>2) Make up a mode name for the landscape version, and make it a sibling
> directory.
That solution sucks, because the whole point is the `landscape' or not
is independent of the rest of the mode.
how many entries in modes.mf are we talking about?
17. At the moment.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 07:47:45 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcCIN-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 21 Aug 94 13:46 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, n@cs.washington.edu, unixtex@u.washington.edu
Subject: Re: the font hierarchy, for the umpteenth time
>But what do se do about a Knuth-style "family"? I would suggest
>that we leave it alone as an anomaly.
There are other examples though... Lucida and Stone are the obvious
ones. And for all I know there may be MM fonts with a
`roman/sans/typewriter' axis :-P But I guess all we can do is
recommend that fonts be grouped together as the foundry suggest---this
would probably mean one directory for CM, Lucida and Stone. It won't
fit with the LaTeX notion of font family, but since LaTeX uses
the family axis to record digit style and whether the fonts were built
with an expert set, I guess we're never going to have the LaTeX
families line up with the directory structure...
So what's the directory structure for CM then? Something like:
fonts/tfm/???/cm/cm*
fonts/tfm/???/logo/logo*
fonts/tfm/???/concrete/cc*
etc.?
What to use for `???' here? I don't like `public' since this rather
discriminates against pd font developers---even a company like
Texplorators which markets 3 fonts gets a directory, whereas someone
like Damain Cugley who's put an entire font family together gets
stuck in `public'. `knuth' is good, but there are problems
about putting fonts like the dc fonts into a `knuth' directory, and I
think it would be nice to have the dc and the cm directories at the
same level.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 08:04:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcCYu-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 21 Aug 94 14:03 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>I don't see the point of your scheme. Who benefits if the names are a la
>LaTeX? Personally, I would hate it, since there would be, as you say,
>zillions of directories, each with only a few files.
Seems reasonable. The LaTeX scheme is too fine-grained.
>As for `knuth' vs. `public', are you going to have `billawal', `cugley',
>etc., etc.? Why?
I don't think the amount of money paid for a font is a good way to
name a directory structure. If `public' then why not `commercial',
`shareware', `freeware', `gnulicense' etc.?
If we're going to have an area for small companies/individuals who've
not produced many fonts, then let's call it `misc' so it can include
the Texplorators MathTime, and any other fonts from small commercial
outfits. But I think sticking CM under `misc' would be a touch
insulting to DEK.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 08:11:07 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcCex-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 21 Aug 94 14:10 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, rokicki@cs.stanford.edu
Subject: Re: landscape mode fonts
>That solution sucks, because the whole point is the `landscape' or not
>is independent of the rest of the mode.
True, but it is at least consistent with the rest of the directory
structure. I'd be very wary of sticking in another directory level to
patch this problem.
> how many entries in modes.mf are we talking about?
>17. At the moment.
I think the world can live with another 17 mode_def entries, if dvips
can be persuaded to pass this info on to MakeTeXPK.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sun, 21 Aug 1994 08:16:20 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcCk3-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 21 Aug 94 14:15 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>Is the crux of the matter whether the TDS specifies one-level or
>fully-recursive subdirectory searching?
Yup.
>But that is a terrible thing to promulgate.
But it's what exists at the moment. I don't think we're going to make
friends with sysadmins if we say `here's this new neato directory
structure, but you're going to have to install a new TeX in order to
use it.' With my sysadmin hat on I know that I for one am not going
to rush out and install a new TeX (we're running with a 2-year old TeX
here) just in order to get TDS up and running.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 03:10:13 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Mon, 22 Aug 1994 09:11:07 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:190240:940822081113"@cl.cam.ac.uk>
its just not on to specify one-level directory searching only; i am
entirely with Karl here. embedded subdirectory searching is another
matter, but we must have full subdir searching or we can just abandon
the exercise, in my view. whats the practical result?
a) all the Unix people are OK
b) many many DOS people are OK (all the emTeX and Y&Y people); PCTeX
etc probably have to change anyway
c) the VMS people have to change anyway
d) the Textures people have to change anyway
e) the OzTeX people are stuck
f) does cmactex inherit web2c subdir searching
does that sound convincing? no. lets not be driven by the Mac
people. Andrew Trevorrow is a great man, and he'll go along with
anything reasonable.
or have i missed some element of the story?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 03:16:57 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: path searching necessities
Date: Mon, 22 Aug 1994 09:17:44 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:193280:940822081759"@cl.cam.ac.uk>
i (as ever) agree with Karl about Phil's worries. lets get a
TDS out there soon, and get people convinced of the idea. then people
can experiment with different schemese,a nd the interesting extra
characters to mean `start at current file', over the next year or so,
and we can issue TDS mark 2. if we issue something simple, it'll be
accepted if its consistent. given that many people now know this group
is delibertaing, if we dont get an agreed TDS soon, we'll get the same
reputation as the driver standards committee!! a fate worse than
death, or Wordperfect.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 03:18:04 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: landscape mode fonts
Date: Mon, 22 Aug 1994 09:18:55 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:193630:940822081905"@cl.cam.ac.uk>
oh b@gger printers which need special landscape fonts! we can just do
without that. i say make it a different mode...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 07:33:32 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcYZg-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 13:34 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
> a) all the Unix people are OK
Try `all the Unix people running recent versions of TeX are OK'.
Ditto for the other platforms, except that in some cases we're basing
the TDS on vapourware. If we go for fonts/<source>/<family>/<type>
then the only platform TDS can be implemented on is Web2C TeX. If we
go for fonts/<type>/<source>/<family> then it can be implemented today
on most of the major TeXs.
I get the feeling we're going round in circles on this one...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 07:55:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Mon, 22 Aug 1994 13:56:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:031770:940822125628"@cl.cam.ac.uk>
> Try `all the Unix people running recent versions of TeX are OK'.
if they dont have web2c, they dont have *any* level of subdir
searching, so wheres the problem?
> Ditto for the other platforms, except that in some cases we're basing
> the TDS on vapourware. If we go for fonts/<source>/<family>/<type>
> then the only platform TDS can be implemented on is Web2C TeX. If we
> go for fonts/<type>/<source>/<family> then it can be implemented today
> on most of the major TeXs.
why are we still arguing this? what are these systems that work with one
level only? i am genuinely confused.
for the record, i have a more-or-less TDS with web2c under Linux and
two separate PC implementations (emtex and Y&Y). which systems could i
use *now* that would obey fonts/type/source/family? a trivial example
- dviwin cant hack it (it cant hack anything, its a heap of cr@p).
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:02:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:00:13 -0400
Message-ID: <199408221400.KAA11247@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <21007C8C_000E3E20.00983087157B7ED2$21_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
On 16 August 1994 at 12:02:01, CHAA006@vax.rhbnc.ac.uk wrote:
> >> the TDS list has thrashed (a) to death. i say its agreed. wrt b), can
> >> you elucidate what devious idea you have in mind? we are *not* talking
> >> recursion, we are talking subdirectory searching.
>
> [...]
> If I use Lib$Find_File on TeX_Root:[TeX.Inputs...]CropMark.TeX, then
> I am _forced_ to use the semantics of Lib$Find_File, which
> regardless of whether it performs a breadth-first or depth-first
> search will ultimately use recursion (or an iterative straightening
> thereof) to enable it traverse all branches of the tree. The
> problem is, Lib$Find_File _may_ use breadth first, while ls-R (which
> term I finally understand: thanks, Karl) _may_ use depth first. If
> the semantics differ, then the search algorithm differs, and if the
> search algorithm differs, then two different installations may
> produce different results if two or more copies of CropMark.TeX
> exists in the search tree.
If you have two files with the same name on your system, and both are
on your search path (no matter how it's specified, recursively or not)
you are running the risk of error. Recursive searching doesn't make
it any worse.
In fact, it makes it better. It simplifies the path specification and
garauntees that for any given running system, everyone gets the same
files. I've had more than one query about why "such and such" doesn't work
only to discover that the user was searching in some (IMHO) totally bizarre
order because they had to list 19 different directories in TEXINPUTS.
> Since the whole concept of TeX is
> predicated on total consistency across sites, we would be grossly
> violating the underlying precepts if we allowed different search
> algorithms on different operating systems.
I don't agree. There are lots of platform dependent things. Do you think
that emTeX and web2c are "grossly violating" TeX principles by allowing
searching in an implementation-dependent fashion?
> Therefore, whilst I still have considerable reservations about
> recursion subdirectory searching at all (because, having read much
> of the correspondence, I fear we are seeking an acceptable solution
> rather than the correct solution),
What is the correct solution?
> if we _are_ going to recommend
> (`mandate' is too strong) use of this technique, then we must also
> ensure that the recursion/search algorithm is built into TeX (or at
> least is operating-system independent).
That would be great, but it isn't practical. I refuse to believe that
we should abandon our efforts just because we can't do at the ideal
level what we can so obviously do it at the practical level.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:12:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 15:10:59 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <20201CAB_000E36E0.009835587A013D26$34_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> If you have two files with the same name on your system, and both are
>> on your search path (no matter how it's specified, recursively or not)
>> you are running the risk of error. Recursive searching doesn't make
>> it any worse.
>> In fact, it makes it better. It simplifies the path specification and
>> garauntees that for any given running system, everyone gets the same
>> files.
Only if the recursion algorithm is deterministic.
>> I don't agree. There are lots of platform dependent things. Do you think
>> that emTeX and web2c are "grossly violating" TeX principles by allowing
>> searching in an implementation-dependent fashion?
No, because they don't purport to be a standard. What we are doing will
purport to be a standard, and therefore must be far more rigorously defined.
>> What is the correct solution?
The whole purpose of our exchanges.
>> That would be great, but it isn't practical. I refuse to believe that
>> we should abandon our efforts just because we can't do at the ideal
>> level what we can so obviously do it at the practical level.
No, we shouldn't abandon our efforts; but we should concentrate on achieving
the best possible solution, not the least unacceptable compromise.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:12:46 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:10:52 -0400
Message-ID: <199408221410.KAA11264@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <2100A4D9_002FE7D0.00983097BCF5FEF2$19_4@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
On 16 August 1994 at 14:01:14, CHAA006@vax.rhbnc.ac.uk wrote:
> Two themes: 1) Should <package> be big- or little-endian? The group
> seem to feel that big-endian is correct, but that since extant
> implementations tend to make it little-endian, there is little or no
> chance of persuading them to change.
Well, we did talk about it at some length(see the logs). There are other
reasons why little-endian is better.
> 2) Should the search strategy
> by influenced by the location of the current file? There seems to
> be _some_ (by no means universal) support for this, but again we
> seem to be ruling it out as ``too difficult / too different''.
IMHO, that's just wrong. It means that
\input{foo.tex}
\input{blah.tex}
\input{foo.tex}
might make foo.tex refer to two different files. That's just horrific.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:31:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 15:30:15 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <202022AA_000E25E8.0098355B2B107846$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> IMHO, that's just wrong. It means that
>> \input{foo.tex}
>> \input{blah.tex}
>> \input{foo.tex}
>> might make foo.tex refer to two different files. That's just horrific.
Karl seemed to reach the same conclusion, and therefore I think it's
a linguistic problem, with `current' having different meanings on each
side of the pond. For me, in the example above, the `current' file is
the file containing the three \input records; each of those becomes
the current file only while it is being read. Therefore the context
of the three \input records which you have shewn is invariant, and
both instances of `foo' will locate the same file. But if `blah'
also chose to \input foo, the `current file' would become `blah', and
_then_ a different foo might be found.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:34:09 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:31:56 -0400
Message-ID: <199408221431.KAA11320@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: landscape mode fonts
References: <199408201031.AA04999@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 20 August 1994 at 06:31:03, K. Berry wrote:
> Tom Rokicki has posed an interesting question -- what to do with PK
> files built in landscape mode? The best I can think of so far is to have
> a subdirectory landscape/ of the pk/mode directory, e.g.,
>
> texmf/fonts/public/cm/pk/lqmedres/landscap/cmr10.180pk
Uh, it's really
texmf/fonts/public/cm/pk/lqmedres/landscap/dpi180/cmr10.180pk
1 2 3 4 5 6 7 8 9
and we can't do this...
> 1) always have both portrait/ and landscap/ under mode/. This gives
> everybody an extra directory level. Yuck.
Same problem.
> 2) Make up a mode name for the landscape version, and make it a sibling
> directory. E.g., append an `l' to the regular name, truncating the
> original name to seven chars if necessary, or I could make all the
> canonical names be seven characters. The problem then is potential
> name conflicts, and lack of consistent semantics -- lqmedresl isn't a
> valid mode name. (And I can't make it be so without quadrupling the
> amount of memory modes.mf takes, and people already complain about that.)
>
> Thoughts? Comments? Suggestions?
How many devices really need landscape mode fonts?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:39:46 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:37:58 -0400
Message-ID: <199408221437.KAA11358@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <199408211244.AA22887@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 21 August 1994 at 08:44:06, K. Berry wrote:
> It's clear I should never have implemented one-level subdirectory
> searching. And now that mistake might be cast into stone and affect
> every TeX site (that cares to be TDS-compliant) forever? Sigh.
It's not your fault, Karl. Eberhard did it too; and apparently there's
some Mac implementation that thinks that it's not just necessary but
*sufficient*. Sigh.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:42:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:40:20 -0400
Message-ID: <199408221440.KAA11375@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: landscape mode fonts
References: <199408211244.AA22919@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 21 August 1994 at 08:44:09, K. Berry wrote:
> texmf/fonts/public/cm/pk/lqmedres/landscap/180/cmr10.pk
>
> and oh dear there went our ISO 9660 compliance... I think the only
> solution is:
>
> The first level (texmf/) is not necessary on a CD-ROM.
Yes it is. Otherwise, you can't put anything on the CD that isn't in
the texmf tree. The README file and INSTALL scripts for the CD aren't
part of texmf by any stretch of the imagination.
> >2) Make up a mode name for the landscape version, and make it a sibling
> > directory.
>
> That solution sucks, because the whole point is the `landscape' or not
> is independent of the rest of the mode.
>
> how many entries in modes.mf are we talking about?
>
> 17. At the moment.
I think that the landscape version name is the way to go, even if an
orientation level would be cleaner.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:46:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:45:04 -0400
Message-ID: <199408221445.KAA11386@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <"swan.cl.cam.:190240:940822081113"@cl.cam.ac.uk> <m0qcYZg-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 August 1994 at 13:34, Alan Jeffrey wrote:
> > a) all the Unix people are OK
>
> Try `all the Unix people running recent versions of TeX are OK'.
> Ditto for the other platforms, except that in some cases we're basing
> the TDS on vapourware. If we go for fonts/<source>/<family>/<type>
> then the only platform TDS can be implemented on is Web2C TeX. If we
That's not true, and unfair. It'll work for emTeX today too. Slowly,
maybe, but Eberhard might be convinced to add ls-R too.
> go for fonts/<type>/<source>/<family> then it can be implemented today
> on most of the major TeXs.
Huh? What implementations support single level subdirectory searching
but not multiple level subdirectory searching?
> I get the feeling we're going round in circles on this one...
Yes. Can we please stop? I'll try to summarize things for the next
TDS document, but if someone else could summarize the last week for us,
I'd appreciate it. Coming back from vacation makes me realize just how
much I'm supposed to do in a week ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:49:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 10:47:03 -0400
Message-ID: <199408221447.KAA11390@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <m0qcYZg-00003QC@csrj.crn.cogs.susx.ac.uk> <"swan.cl.cam.:031770:940822125628"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 August 1994 at 13:56:14, Sebastian Rahtz wrote:
> for the record, i have a more-or-less TDS with web2c under Linux and
> two separate PC implementations (emtex and Y&Y). which systems could i
How does Y&Y do it? Multiple levels, I assume, but what specification?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:55:20 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Mon, 22 Aug 1994 15:56:12 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:088810:940822145619"@cl.cam.ac.uk>
Y&Y do just whats desired - a double trailing / or \. Berthold says
they do startup opimization, but wasnt specific. it works so far for
me with speed ok
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 09:56:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 Aug 94 07:55:27 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408221455.AA12031@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: ISO-9660 limits
If the ONLY file system that has a problem with limits on the number of
directory levels is ISO-9660 (what about MS-DOG and VMS?), I would hate
to throw away a whole level just for CD-ROMs. I mean, these levels are
one of the few degrees of freedom we have, and the difference between
seven and eight is QUITE significant.
It's a tad ugly, but I could easily live with:
/texmf/cdrom/...
as an inviolate place to put CD-ROM meta-data, administrivia, etc. I'm
normally pretty strong about keeping directory levels clean, but I
can't see being absolutist on this one...
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 10:03:52 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcav0-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 16:04 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>That's not true, and unfair. It'll work for emTeX today too. Slowly,
>maybe, but Eberhard might be convinced to add ls-R too.
OK, I stand corrected. I thought web2c was the only TeX supporting
wild cards in path names.
>> go for fonts/<type>/<source>/<family> then it can be implemented today
>> on most of the major TeXs.
>Huh? What implementations support single level subdirectory searching
>but not multiple level subdirectory searching?
OzTeX.
And there's the fact that to implement fonts/<source>/<family>/<type>
at all efficiently you need either wild cards or an ls-R file. I'm
prepared to believe we can convince implementors to provide full
recursive subdirectory searching, but I'm not convinced we can
persuade them to provide wild cards or ls-R. I'm not even sure what
an ls-R file could possibly look like on a Mac.
>Yes. Can we please stop?
>if someone else could summarize the last week for us,
>I'd appreciate it.
OK, as I see it... We have to decide between two possible structures
for the fonts directory:
fonts/<source>/<family>/<type>
fonts/<type>/<source>/<family>
Advantages of fonts/<source>/...
* Files releated to each font are gathered together, so easier for
humans to find files, or distribute a group of files to their
colleagues.
* Easier for people doing serious fonts work (eg Pierre)
Advantages of fonts/<type>/...
* Can be implemented on most TeX systems today.
* Doesn't require wild cards or ls-R.
I'm sure other people's summaries will be rather different. Your
milage may vary.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 10:52:22 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Mon, 22 Aug 1994 16:46:37 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:115170:940822154729"@cl.cam.ac.uk>
strikes me that Alan's whole edifice is erected on the meverick
premise of OzTeX's peculiarities. if he cant adduce another example of
a TeX where it will work today, then lets forget the
problem. efficiiency is not our problem now
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 11:55:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 Aug 1994 11:55:50 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098353D.37BD4FC4.119@SHSU.edu>
Subject: RE: ISO-9660 limits
On Mon, 22 Aug 94 07:55:27 PDT, rdm@cfcl.com (Rich Morin) posted:
> If the ONLY file system that has a problem with limits on the number of
> directory levels is ISO-9660 (what about MS-DOG and VMS?), I would hate to
> throw away a whole level just for CD-ROMs. I mean, these levels are one of
> the few degrees of freedom we have, and the difference between seven and
> eight is QUITE significant.
Now that Phil and other VMS'ers are on-line here, they can easily correct
me in the event that I am in error, but,..... VMS is limited to 8
directories -- we can get around it with a few rooted logicals here and
there, but as the structure is something assumed to begin at texmf/, I
would hesitate to design anything which even has the remotest chance of
being used under VMS which exceeded the 8 directories stipulation of 9660.
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 12:07:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 18:07:24 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: ISO-9660 limits
Message-ID: <20202861_000E1328.009835711F3EF306$17_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Now that Phil and other VMS'ers are on-line here, they can easily correct
>> me in the event that I am in error, but,..... VMS is limited to 8
>> directories -- we can get around it with a few rooted logicals here and
>> there, but as the structure is something assumed to begin at texmf/, I
>> would hesitate to design anything which even has the remotest chance of
>> being used under VMS which exceeded the 8 directories stipulation of 9660.
George, how ever could you imagine that I could think you in error? :-)
As always, I agree with everything that George says...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 12:52:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcdYi-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 18:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>if he cant adduce another example of
>a TeX where it will work today, then lets forget the
>problem.
Argh, one more time... In order to implement the fonts/<source>/...
structure you need either a) wild cards, or b) an ls-R file.
Currently web2c and (I am told) emTeX support these.
OzTeX, Textures, Y&YTeX and VMS TeX (as far as I am aware) do not.
However all of the above support at least one level of subdirectory
searching (or will do with the next release) and so can support
fonts/<type>/... now.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:01:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 19:01:03 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <20202861_002A16E8.009835789D9A7F66$18_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> OzTeX, Textures, Y&YTeX and VMS TeX (as far as I am aware) do not.
>> However all of the above support at least one level of subdirectory
>> searching (or will do with the next release) and so can support
>> fonts/<type>/... now.
Wait a minute, wait a minute: what is your evidence for VMS TeX either
supporting one-level subdirectory searching either now or in a forthcoming
release? So far as I know it does not support it at the moment, and I
cannot think that Christian Spieler will add something that seems pretty
d@mned useless...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:08:46 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcdo3-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 19:09 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.EDU
Subject: Re: the font hierarchy, for the umpteenth time
>Wait a minute, wait a minute: what is your evidence for VMS TeX either
>supporting one-level subdirectory searching either now or in a forthcoming
>release?
No, I said `at least one-level...' I assumed from your previous
discussion that VMS TeX either did support full subdir searching, or
was going to soon. Sorry if this isn't the case.
In which case the list is currently:
can support fonts/<source>/... web2c, emTeX
can support fonts/<type>/... ditto plus OzTeX, Textures and Y&YTeX
can support neither VMS TeX
? Any other additions/corrections?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:19:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 19:19:19 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <20202A66_00399A70.0098357B2ACE0A86$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> No, I said `at least one-level...' I assumed from your previous
>> discussion that VMS TeX either did support full subdir searching, or
>> was going to soon. Sorry if this isn't the case.
Mea culpa (a phrase which should be burned into my keyboard...);
>> In which case the list is currently:
>> can support neither VMS TeX
Well, I clearly can't speak for Christian, so we must wait to see what he
plans to implement.
** Phil.H
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:33:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 14:31:23 -0400
Message-ID: <199408221831.OAA12540@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <"swan.cl.cam.:115170:940822154729"@cl.cam.ac.uk> <m0qcdYi-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 August 1994 at 18:53, Alan Jeffrey wrote:
> >if he cant adduce another example of
> >a TeX where it will work today, then lets forget the
> >problem.
>
> Argh, one more time... In order to implement the fonts/<source>/...
> structure you need either a) wild cards, or b) an ls-R file.
Actually, I object to the notion of "needing" wild cards or ls-R files.
You don't need them, they just make things work faster. emTeX supports
recursive subdirectory searching, but neither a) nor b). But I remain
unconvinced that it's necessary.
I *thought* your arguement was that multi-level searching wasn't
supported widely enough.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:46:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 Aug 1994 13:46:27 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <0098354C.ABA6EF44.51@SHSU.edu>
Subject: RE: ISO-9660 limits
On Mon, 22 AUG 94 18:07:24 BST, Phil Taylor <CHAA006@VAX.RHBNC.AC.UK> posted:
> George, how ever could you imagine that I could think you in error? :-) As
> always, I agree with everything that George says...
Sorry to use up the bandwidth on this, but after a few late night sessions
at Santa Barbara, one specifically with Phil, as well as the little set of
exchanges at the Business Meeting, this has to go into the public record
for posterity folks. Phil (finally) agreed with me on something and now
apparently has a possibly severe case of amnesia. Not that I mind,......
8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-)
--George
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:50:46 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qceSc-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 19:51 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>Actually, I object to the notion of "needing" wild cards or ls-R files.
>You don't need them, they just make things work faster.
Ah, now I see our point of disagreement. I guess it hadn't occurred
to me that we were seriously suggesting that people set their TeX
systems up so that to find a TFM file you have to search all the PK,
VF, etc. etc. directories. Anyone like to guess how long that's going
to take on a CD-ROM?
>I *thought* your arguement was that multi-level searching wasn't
>supported widely enough.
My argument is that at least single-level directory searching is
supported pretty much universally, and it's all you need in order to
implement fonts/<type>/... fonts/<source>/... requires either more
sophisticated technology or a lot of patience...
When I was testing the rawfonts package I was interested to discover
that it took ~15sec to load 70 fonts on my Duo 230. I don't really
want to think what the time would be like if it had to search all the
PK files as well as the TFMs.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 13:59:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 Aug 94 11:57:35 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408221857.AA12539@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
> Anyone like to guess how long that's going to take on a CD-ROM?
Actually, it would likely take quite a bit less time than on a
comparably filled hard disk. You see, ISO-9660 flattens the tree
and stuffs it up into a small area at the "start" of the CD-ROM.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 14:13:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 15:11:22 -0400
Message-ID: <199408221911.PAA12671@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <199408221831.OAA12540@jasper.ora.com> <m0qceSc-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 August 1994 at 19:51, Alan Jeffrey wrote:
> >Actually, I object to the notion of "needing" wild cards or ls-R files.
> >You don't need them, they just make things work faster.
>
> Ah, now I see our point of disagreement. I guess it hadn't occurred
> to me that we were seriously suggesting that people set their TeX
> systems up so that to find a TFM file you have to search all the PK,
> VF, etc. etc. directories. Anyone like to guess how long that's going
> to take on a CD-ROM?
No longer than it'll take to search for cmr10.pk at the desired resolution
when I print the file. If I have to search all the PK directories at
least n times, is it that bad if I do it n+1 times? If it is, maybe I
ought to try to put some pressure on the developer of my implementation
of TeX to help me out.
Here's my summary of the issues:
1) TeX installations are large and complex. Organizing files into
subdirectories makes use, documentation, and maintenance easier.
1b) The TDS describes what these subdirectories are and indicates how
a large, logical structure is constructed.
2) TeX (and friends) have to find files in these various subdirectories.
3) Specifing all of the paths to search is difficult, error prone, and
impractical on many systems and downright impossible on some systems.
4) Subdirectory searching is necessary to alleviate this problem.
5) The TDS recommends a deterministic, breadth-first subdirectory search
algorithm specified by repeating the trailing subdirectory delimiter.
Implementations are free to provide shortcuts (ls-R files) and/or
alternate features as long as they provide the same functionality (i.e.
subdirectory searching).
(Phil, does this wording satisfy you that the TDS isn't encouraging
implementors to spawn dozens of "incompatible" TeX systems?)
On another note, Phil has suggested a different strategy that just
plain frightens me. But maybe I scare easily. Despite the logical,
modular structure of the scheme he suggests, I'm not ready to put
it into a standard. (But if someone implements it and demonstrates
that it's better, we can run with it in the TDS/2). I'm not trying
to close any discussion, but we do need to *finish*. Soon.
6) texmf/tex/format/package/... is how macros should be done
7) We must choose between texmf/fonts/filetype/vendor/family/... and
texmf/fonts/vendor/family/filetype...
I'm open to the texmf/fonts/filetype arrangement, but I'm unconvinced
that it's necessary. But it is an important point. I don't want to
hamstring discussions by trying to force this issue to a close, but my
feeling is that most of us are unconvinced by the /fonts/filetype
argument. If you feel otherwise, please speak now. ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 14:13:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 22 Aug 1994 15:11:36 -0400
Message-ID: <199408221911.PAA12678@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <9408221857.AA12539@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 22 August 1994 at 11:57:35, Rich Morin wrote:
> > Anyone like to guess how long that's going to take on a CD-ROM?
>
> Actually, it would likely take quite a bit less time than on a
> comparably filled hard disk. You see, ISO-9660 flattens the tree
> and stuffs it up into a small area at the "start" of the CD-ROM.
Music to my ears.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 15:09:00 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcf4i-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 22 Aug 94 20:30 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>No longer than it'll take to search for cmr10.pk at the desired resolution
>when I print the file.
Well yes, and that'll take n+m times longer, where n is the number of
modes, and m is the number of other filetypes (afm, pfa, etc.).
In fact, hold on a moment, how am I meant to specify a printer mode in
the fonts/<source>/... structure? With fonts/<type>/... I can say:
PKFONTS = $TEXMF/fonts/pk/CanonCX//
With fonts/<source>/... if I've got wild cards I can say:
PKFONTS = $TEXMF/fonts//pk/CanonCX//
But even with an ls-L file I can't see how I'm meant to specify a
printer mode in the fonts/<source>/... structure. Perhaps I'm just
being dim...
>If it is, maybe I
>ought to try to put some pressure on the developer of my implementation
>of TeX to help me out.
And what do you do if your developer says `well, you can make
everything much faster by ignoring TDS'? That's what I'd say if I was
a developer.
> I don't want to
> hamstring discussions by trying to force this issue to a close, but my
> feeling is that most of us are unconvinced by the /fonts/filetype
> argument.
Not that I'm stringing things along or anything :-) but I'd like to
point out that my other partner in crime in suggesting this directory
structure (David Carlisle) is on holiday at the moment.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Aug 1994 21:39:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 AUG 94 20:32:38 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <20202861_000E4160.009835856866E2E6$23_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> 5) The TDS recommends a deterministic, breadth-first subdirectory search
>> algorithm specified by repeating the trailing subdirectory delimiter.
>> Implementations are free to provide shortcuts (ls-R files) and/or
>> alternate features as long as they provide the same functionality (i.e.
>> subdirectory searching).
>> (Phil, does this wording satisfy you that the TDS isn't encouraging
>> implementors to spawn dozens of "incompatible" TeX systems?)
Oh, I'm easily satisfied: George will tell you that... ! But I do have
some reservations: `deterministic breadth-first' still doesn't actually
define the search strategy: that still depends on how the tree is
structured. Although that may be logically consistent across all
systems by courtesy of TDS, internally there may be differences
and that will affect the search strategy. I think we need to be
even more precise. And why worry about the syntax? Surely that should
simply be `appropriate to the operating system under consideration'?
In VMS, [TeX.Inputs...] is instantly recognisable; [TeX.Inputs..]
just looks like an almighty c@ck-up!
>> If you feel otherwise, please speak now. ;-)
I do, but whereas I can justify my other arguments, here I am relying
purely on intuition.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 02:48:43 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 23 Aug 1994 08:49:03 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:131760:940823074927"@cl.cam.ac.uk>
fonts/source/family/type *is* supported by anything that supports full
subdir searching (eg emtex, y&ytex), even without embedded wild
cards. i know, i use it. i think what alan is saying is that unless an
implementation supports mid-path "//", it isnt efficient? yes? and
Karl says who cares, its too slow anyway so you need an ls-lR effect.
so we areback to efficiency, not absolute possibility
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 05:48:58 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qctQ0-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 23 Aug 94 11:49 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>fonts/source/family/type *is* supported by anything that supports full
>subdir searching (eg emtex, y&ytex), even without embedded wild
>cards. i know, i use it. i think what alan is saying is that unless an
>implementation supports mid-path "//", it isnt efficient? yes? and
>Karl says who cares, its too slow anyway so you need an ls-lR effect.
OK, I'll do some experiments to find out the relative times of these
schemes under OzTeX (I would do it under web2c except that it's so
fast that you can't possibly measure the amount of time it takes to
load 200 fonts :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 08:00:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408230858.KAA15387@spice.iti.informatik.th-darmstadt.de>
Subject: Re: the font hierarchy, for the umpteenth time
To: TWG-TDS@SHSU.edu
Date: Tue, 23 Aug 1994 10:58:38 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >if he cant adduce another example of
> >a TeX where it will work today, then lets forget the
> >problem.
>
> Argh, one more time... In order to implement the fonts/<source>/...
> structure you need either a) wild cards, or b) an ls-R file.
Can you elaborate why you think you need wild cards? I cannot see it.
And an ls-R file is clearly `only' an implementation issue, not a
necessary precondition.
On another point you mentioned in an earlier mail (at least I think
it was you): You said that an ls-R file is impossible to implement
for a Mac. Why? I'm not so familiar with Macs, but up to now I
thought they have a hierarchical filesystem, too.
Note: When I write `ls-R file' I don't mean a file with a Unix `ls
-R' listing. I mean a database with the set of all filenames in one
respective file system (sub-)hierarchy. The external storage format
of such a database may be system-dependent, of course.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 08:10:47 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 23 Aug 1994 13:55:52 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:273210:940823125601"@cl.cam.ac.uk>
i had an interesting note from Tom Rokicki, who is going to add
`native' subdir searching to dvips (since he cant/wont incorporate
kpathsea). he is very much in favour of the `inline wildcard' system,
so it'll be interesting to see what he comes up with in terms of
performance. given that he writes previwers, he'll certainly care
about speed.
it seems to me that the majority feel that fonts/vendor/familty/type
is nicer, but are worried about performance, and existing TeXs that
can't handle inline wildcards. is th the only objection?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 08:31:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 23 AUG 94 14:29:09 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <202034B8_00335138.0098361BCC92E486$24_5@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> `native' subdir searching to dvips (since he cant/wont incorporate
^^^^/^^^^
Tut tut, Sir: and you a native British speaker, indeed. Or have
you just given up apostrophes for Lent?
>> it seems to me that the majority feel that fonts/vendor/familty/type
>> is nicer, but are worried about performance, and existing TeXs that
>> can't handle inline wildcards. is th the only objection?
No. I lay in bed last night and introspected on why I currently prefer
[TeX.Fonts.Tfm...], [TeX.Fonts.Pk...] and so on, rather than
[TeX.Fonts.Adobe.Tfm...], etc. And I think the real reason (quite
apart from efficiency, which is of course important in any real-world
situation) is that the division into Tfm, Pk, <...>, etc., is a `natural;
division which most TeX users would instinctively understand; but a division
into (say) Knuth, Monotype, Bitstream, <...>, is highly artificial. I suspect
that the slightly aware user would understand divisions between the 75
canonical fonts, the LaTeX fonts, the AMSTeX fonts and so on, but once
they get on to Times.Pfb they probably (a) have no idea whose Times it is
in the first place, (b) care, and (c) appreciate that there might be $n$
fonts, all called Times.Pfb, all coming from different vendors, and all
with subtly different font metrics. So both for reasons of efficiency,
and for reasons of user acceptability (_now_ look whose compromising his
own standards!), I prefer to place <type> higher in the hierarchy than
<vendor>.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 09:40:08 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcwzn-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 23 Aug 94 15:38 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>it seems to me that the majority feel that fonts/vendor/familty/type
>is nicer, but are worried about performance, and existing TeXs that
>can't handle inline wildcards. is th the only objection?
That's the main one. And I still don't see how to specify a printer
mode without wildcards.
Anyhow, I implemented TDS-except-with-fonts/<type>/... on my Duo this
afternoon. Results are quite reasonable... Time to load 50 fonts:
OzTeX as shipped: 4sec
with TDS-except: 8sec
To find out how OzTeX would fare under fonts/<vendor>/... if it had
full subdirectory searching, I added the PK folders to the TFM search
path, and got a running time of 82sec(!) Boy you should have heard my
hard disk whirr.
Previewing times are still acceptable, and would be much improved if I
split the PKs into 300dpi and 72dpi fonts.
If anyone's interested, this is running with a 33MHz 68030 Duo 230.
I've not got that many fonts mounted---I do my serious fonts work in
the department. My fonts/tfm directory ended up looking like this:
adobe
courier
helvetic
mathptm
symbol
times
zapfchan
knuth
cm
concrete
dc
misc
misc
ams
bbold
flint
latex
malvern
mon
oldgerm
stmary
wncyr
wnipa
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 10:09:55 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Tue, 23 Aug 1994 16:10:37 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:033260:940823151046"@cl.cam.ac.uk>
> situation) is that the division into Tfm, Pk, <...>, etc., is a `natural;
> division which most TeX users would instinctively understand; but a division
> into (say) Knuth, Monotype, Bitstream, <...>, is highly artificial. I suspect
any snetence containibg the pharase `most TeX users' is automatically
suspect :-}
> with subtly different font metrics. So both for reasons of efficiency,
> and for reasons of user acceptability (_now_ look whose compromising his
> own standards!), I prefer to place <type> higher in the hierarchy than
> <vendor>.
but it breaks one of our underlying principles, which is to group
stuff together by source package. if you get the ams fonts, you keep
them together tyo make it easy to maintain them
sebastian
PS no not lent just very very slow line where editing is a pain
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 10:39:11 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qcxFW-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 23 Aug 94 15:54 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Ooops, a correction to my previous post. When I did the experiment to
find out how OzTeX would handle fonts/<vendor>/ I forgot to make OzTeX
search all the way through the PK heirachy (I had it only search
fonts/pk/screen/knuth/cm rather than fonts/pk/screen/knuth/cm/300).
Once you do that the figures to load 50 fonts are:
OzTeX standard folders: 4 sec
TDS with fonts/<type>/: 8 sec
TDS with fonts/<vendor>/: 165 sec (not 80 sec)
You should probably halve the last figure to account for the fact that
OzTeX will find each font 1/2 way through the search on average.
Anyway, I think that'll do as my answer to Joachim's question:
>Can you elaborate why you think you need wild cards? I cannot see it.
:-)
>On another point you mentioned in an earlier mail (at least I think
>it was you): You said that an ls-R file is impossible to implement
>for a Mac. Why? I'm not so familiar with Macs, but up to now I
>thought they have a hierarchical filesystem, too.
I didn't say impossible, I just don't know how to do it, and I've
never seen a similar directory listing on any piece of Mac software.
I'm rather worried that we're proposing a strucure which needs (unless
you've got a lot of spare time on your hands) non-standard techniques
to support it, whereas the fonts/<type> structure can be supported
with off-the-shelf technology.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 11:47:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408231647.SAA20047@spice.iti.informatik.th-darmstadt.de>
Subject: Re: the font hierarchy, for the umpteenth time
To: TWG-TDS@SHSU.edu
Date: Tue, 23 Aug 1994 18:47:59 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Ooops, a correction to my previous post. When I did the experiment to
> find out how OzTeX would handle fonts/<vendor>/ I forgot to make OzTeX
> search all the way through the PK heirachy (I had it only search
> fonts/pk/screen/knuth/cm rather than fonts/pk/screen/knuth/cm/300).
> Once you do that the figures to load 50 fonts are:
>
> OzTeX standard folders: 4 sec
> TDS with fonts/<type>/: 8 sec
> TDS with fonts/<vendor>/: 165 sec (not 80 sec)
>
> You should probably halve the last figure to account for the fact that
> OzTeX will find each font 1/2 way through the search on average.
>
> Anyway, I think that'll do as my answer to Joachim's question:
>
> >Can you elaborate why you think you need wild cards? I cannot see it.
>
> :-)
I'm not really convinced. Your answer boils down to ``I have one
implementation where it's really slow.'' But my question was
concerned with principles. In particular: I suspect that the
implementation runs through the file system each time anew instead of
caching its results. (Honestly, I would name such a strategy poor at
least, if not deficient.)
To elaborate even further: I would not call the method as presented
here `recursive wild card searching' anyhow. `wild card' usually
means that one can specify a _pattern_ (formally: a regular
expression, a grammar of category CH-3) that is matched against a
list of possible values. What is done by kpathsea and similar
implementations is canonically called `search tree pruning' (CH-4,
actually) and *much* easier to implement.
Bloody hell, in all the time we're writing mails here, one could have
done already an implementation...
> >On another point you mentioned in an earlier mail (at least I think
> >it was you): You said that an ls-R file is impossible to implement
> >for a Mac. Why? I'm not so familiar with Macs, but up to now I
> >thought they have a hierarchical filesystem, too.
>
> I didn't say impossible, I just don't know how to do it, and I've
> never seen a similar directory listing on any piece of Mac software.
We seem to have a communication problem. We need two functions: An
iteration over the contents of a directory, and the ability to
determine the file type of an entry in such a contents list. Then
it's not only possible, then it's trivial to write. That was what I
meant with `hiearchical file system'. These two possibilities *must*
be available on the Mac, its whole interface depends on them.
With these two functions, it needs about 5 minutes to write a program
that creates a directory listing (simply one line per file, each
entry relative to the starting directory, with arbitrary but fixed
delimiters between directory names) and another 10 minutes to write a
routine that searchs in such a list and delivers a matched name for
an arbitrary input. (And another 20 minutes to transfer the recursion
to an iteration for efficiency reasons. And another 20 to make it
more space-efficient... :-) But still -- c'mon, you cannot believe
your sentence
> I'm rather worried that we're proposing a strucure which needs (unless
> you've got a lot of spare time on your hands) non-standard techniques
> to support it,
yourself. We don't talk about ``a lot of spare time'' here.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 13:08:39 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qd0Fw-0006QEC@rsuna.crn.cogs.susx.ac.uk>
Date: Tue, 23 Aug 94 19:07 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Argh, it's not my day is it...
>When I did the experiment to
>find out how OzTeX would handle fonts/<vendor>/ I forgot to make OzTeX
>search all the way through the PK heirachy (I had it only search
>fonts/pk/screen/knuth/cm rather than fonts/pk/screen/knuth/cm/300).
Before anyone leaps in, this is of course wrong since the TDS mandates
breadth-first search. Once I mimicked that, the figures to load 50
fonts were:
OzTeX standard folders: 4 sec
TDS with fonts/<type>/: 8 sec
TDS with fonts/<vendor>/: 15 sec
which is a bit better! However, there's still a problem---previewing
or printing with PK fonts requires searching the entire fonts
directory before finding the correct PK files. For previewing a
document with 25 fonts we get 5 sec under TDS with fonts/<type>/ and
110 sec under TDSwith fonts/<vendor>/.
Sebastian---you said you'd managed decent performance out of Y&Y
TeX... presumably that's bitmap free, which would account for the
difference in performance. Or is there another reason?
But apart from the fonts area, I've not had many problems running TDS
so far. There are some intricacies about BibTeX and Makeindex
though... I'll play with the current installation a bit more and send
a report.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Aug 1994 15:30:40 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qd2TT-0006QDC@rsuna.crn.cogs.susx.ac.uk>
Date: Tue, 23 Aug 94 21:29 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>We seem to have a communication problem.
We do indeed. I'm interested in what's been implemented. You're
interested in what's implementable. That seems to be the main
difference.
There is a lot of experience with fonts/<type>/ as a directory
structure. Some form of it is implemented on most TeX setups already.
There is a lot less experience with fonts/<vendor>/, and at the moment
it can't be implemented efficiently on some TeX platforms (the ones
without search pruning or directory caching or ls-R or...).
If we're going to go for fonts/<vendor>/ then we need to think very
carefully about our timetable for the task. I'd envisaged a fairly
short alpha-test stage which just consisted of making sure that the
TDS could be run on the major platforms.
But if we're going for a TDS which requires reimplementation of the
TeX implementaions, we're going to have to give more time for it.
Norm, any idea of how long we should give for this to go through? The
best case is that all the major implementors think it's very important
to support TDS, and include TDS support in their next release---this
should only add a year or so onto the amount of time it takes for TDS
to become established. Worst case is that some of the implementors
refuse to play ball, and then we're a bit stuck.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 03:09:32 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 24 Aug 1994 09:09:47 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:072210:940824081020"@cl.cam.ac.uk>
Tom asks about what happens if the directory tree changes in mid
job. ie if MakeTeXPK is called, and makes anew directory. i know this
doesnt matter to TDS, since it doesnt mandate the implementation, but
what do people think about the principle? i assume a startup cache is
almost inevitable, but under what circumstances should it be rebuilt?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 03:12:08 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 24 Aug 1994 09:13:01 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:073390:940824081308"@cl.cam.ac.uk>
i think before alan goes furthe he needs to find if OzTeX caches. the
answer about Y&Y is that it does, i think. since it has no inline //,
i have just pointed it at texmf/fonts// and let it rip. ditto
emtex. no, i dont have a huge amount of pk files (why would one want
to?), about 60 perhaps
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 03:28:29 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 24 Aug 1994 09:28:52 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:081880:940824082925"@cl.cam.ac.uk>
i didnt see the TDS as pragmatic as Alan thinks. I see the TDS as
describing a common langauge, a starting point. i dont care what
implementors do, so long as all documenattions describes the
differences between it and TDS.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 05:38:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 Aug 1994 06:39:12 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408241039.AA15684@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: determinism and breadth-firsters
5) The TDS recommends a deterministic, breadth-first subdirectory search
As I've pointed out before, current kpathsea subdirectory searching is
*not* deterministic (let alone breadth-first), it would be hard to make
it be so, and to no particular advantage that I can see.
Thus, I think we should recommend only ``sufficiently fast''
fully-recursive subdirectory searching (at the end of the path). I
posted proposed wording a few days (several thousand messages :-) ago.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 06:29:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 AUG 94 11:55:05 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: the font hierarchy, for the umpteenth time
Message-ID: <20204EF3_000E8820.009836CF70D8F086$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Tom asks about what happens if the directory tree changes in mid
>> job. ie if MakeTeXPK is called, and makes anew directory. i know this
>> doesnt matter to TDS, since it doesnt mandate the implementation, but
>> what do people think about the principle? i assume a startup cache is
>> almost inevitable, but under what circumstances should it be rebuilt?
Whenever necessary. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 06:49:46 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 24 Aug 1994 12:50:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:180530:940824115043"@cl.cam.ac.uk>
> >> what do people think about the principle? i assume a startup cache is
> >> almost inevitable, but under what circumstances should it be rebuilt?
>
> Whenever necessary. ** Phil.
well gosh thanks phil, i had got there too. these areas of agreement
are becoming embarrasing
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 07:02:24 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Date: Wed, 24 Aug 1994 13:03:17 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:186070:940824120325"@cl.cam.ac.uk>
it will no doubt amuse people to hear that i have been trying to make
the TDS work with a variety of tools with limited success. ine the
Black Appendix of softwarethat is a heap of cr@p ([c] P taylor 1994),
add
dviwin - no virtual fonts, no subdirs, no path list
texshell - cant accept the !! notation of emtex
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 07:17:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 AUG 94 13:00:12 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: determinism and breadth-firsters
Message-ID: <20204EF3_002FEBA8.009836D889D9EA46$19_15@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> As I've pointed out before, current kpathsea subdirectory searching is
>> *not* deterministic (let alone breadth-first), it would be hard to make
>> it be so, and to no particular advantage that I can see.
I've no idea what `kpathsea' is, but I thought we were discussing
philosophy, not implementations. If we are going to be restricted
to what has already been done, then I see no need for a group at
all: each implementer will do what he or she see fit, and that's
the end of it.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 07:21:26 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qdHKz-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 24 Aug 94 13:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>i think before alan goes furthe he needs to find if OzTeX caches.
I'm pretty sure it doesn't.
>emtex. no, i dont have a huge amount of pk files (why would one want
>to?), about 60 perhaps
I've got about 6M worth. Quite why I'm not entirely sure...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 07:45:49 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: determinism and breadth-firsters
Date: Wed, 24 Aug 1994 13:46:15 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:205910:940824124639"@cl.cam.ac.uk>
>
> I've no idea what `kpathsea' is, but I thought we were discussing
it would have been polite, Phil, when you got stuck into this, to get
some background info.
> philosophy, not implementations. If we are going to be restricted
> to what has already been done, then I see no need for a group at
> all: each implementer will do what he or she see fit, and that's
tush, tush.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 08:00:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 AUG 94 13:57:29 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: determinism and breadth-firsters
Message-ID: <2020543E_000E3408.009836E08A51DFC6$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> > I've no idea what `kpathsea' is, but I thought we were discussing
>> it would have been polite, Phil, when you got stuck into this, to get
>> some background info.
I did. There is no mention of `kpathsea' that I can locate in Drv-Norm.TeX.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 09:58:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408241459.QAA13095@spice.iti.informatik.th-darmstadt.de>
Subject: Re: determinism and breadth-firsters
To: TWG-TDS@SHSU.edu
Date: Wed, 24 Aug 1994 16:59:28 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >> > I've no idea what `kpathsea' is, but I thought we were discussing
>
> >> it would have been polite, Phil, when you got stuck into this, to get
> >> some background info.
>
> I did. There is no mention of `kpathsea' that I can locate in Drv-Norm.TeX.
Even if one objects to the tone of sebastian's comment, in its
content it was completely to the point. The draft document is not
``background info,'' it's foreground info. The background is (a) the
backlog of the discussion and (b) knowledge about current
implementations on many different platforms.
kpathsea -- that's the freely distributable library that does the
file searching for web2c/xdvik/dvipsk -- was mentioned *very* often
in the discussion of this mailing list. Without having checked it,
I'm quite sure that George has organised archiving this mailing list,
as always. Take a look at ftp.shsu.edu.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 11:54:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 AUG 94 17:53:49 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: determinism and breadth-firsters
Message-ID: <2020543E_0032FCF8.009837018DE081C6$31_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
The criticism that I have not read the entire backlog of TWG-TDS correspondence
is valid; but time is finite, and I prefer to look to the future rather than to
the past. Yet even with Joachim's explanation of `kpathsea', my substantive
observation remains unchanged: I thought that we were discussing philosophy,
not existing implementations. There is absolutely no point in convening a
group to discuss and propose standards if that group's discussions are to be
constrained by what has been done, rather than by what can be done.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 12:38:40 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 24 Aug 1994 13:36:48 -0400
Message-ID: <199408241736.NAA22534@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: determinism and breadth-firsters
References: <2020543E_0032FCF8.009837018DE081C6$31_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
On 24 August 1994 at 17:53:49, CHAA006@vax.rhbnc.ac.uk wrote:
> There is absolutely no point in convening
> a group to discuss and propose standards if that group's discussions
> are to be constrained by what has been done, rather than by what can
> be done.
I don't agree (at least not whole-heartedly). In fact, to be
devils advocate, I'll turn it around:
There's no point in convening a group to discuss and propose standards
if there is no evidence that those standards can or ever will be
implemented.
The purpose of this group, as I understand it, is to describe a
canonical directory structure that can be implemented today (or
tomorrow, but not next year) that is also clear enough, structured
enough, and general enough to be useful for the forseeable future.
We are trying to solve _todays_ problems for most users.
I *want* to talk about everything that _can_ be done, but I don't
necessarily want to wait until it _has_ been done to publish the
TDS. And I don't think the TDS should contain requirements that
haven't been tested *in practice*.
There are a couple of things that have been discussed that I think we
should experiment with, but I don't think we should delay the publication
of the TDS for them:
- Use of the package/format structure instead of format/package in
the macros area.
- Use of the notion of a 'current' directory in path searching.
The thorny issues that remain are the meaning of subdirectory
searching and the organization of the fonts tree. (Well, there may
be other thorny issues as well, but those are the ones in the forground
right now ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 12:41:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408241742.TAA13924@spice.iti.informatik.th-darmstadt.de>
Subject: Re: determinism and breadth-firsters
To: TWG-TDS@SHSU.edu
Date: Wed, 24 Aug 1994 19:42:00 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> my substantive
> observation remains unchanged: I thought that we were discussing philosophy,
> not existing implementations. There is absolutely no point in convening a
> group to discuss and propose standards if that group's discussions are to be
> constrained by what has been done, rather than by what can be done.
Oh, the old ANSI/IEEE vs. ISO discussion: Let's iterate it again.
The ANSI/IEEE viewpoint on a standard is that it shall codify
existing practice, to benefit the existing (and maybe the further)
users of systems that follow this practice and enable the exchange of
applications within that domain. In particular, IEEE demands that
there must be at least one implementation and sufficient experience
with the practicality of this implementation before something gets a
standard.
This viewpoint brought us standards on C, Scheme, TCP/IP, POSIX,
etc.; standards that are in wide use all over the world. POSIX is a
nice example, indeed: Originally catered to a specific target group
(Unix programmers), it is now recognized in virtually all forthcoming
operating systems. (Even MVS will be POSIX.1 compliant in the next
version!)
ISO standards concentrate on the philosophy. They are made by people
who prefer to start with a blank sheet of paper, who want to get the
things right from the beginning, and who do not care much about
practical experiences and existing practice. (Note: I did _not_ write
that they don't care at all.)
This viewpoint brought us such overwhelming standards as OSI
(i.e., X.25, slowing down all European networks by magnitudes, X.400,
not working at all, the rest is not implemented...), baroque SGML,
complex HyTime, etc. Btw, all these examples have one thing in
common: Not *ONE* full implementation exists for them, even years
(decades in the case of OSI) after the standard was issued.
I think my bias is clear: I would like to have a TDS that is
empirically validated and orients along existing practice. That does
not imply that TDS must immediately be usable on all TeX
implementations. It implies that the needed functionality to support
it must be implementable with reasonable effort (i.e., person weeks,
not months) and there must be enough positive experience in using the
structure.
That's the reason why I am in favor of the `directory tree searching
with subtree pruning' approach. (1) There is an implementation, even
a freely distributable one. (2) There is empiric evidence, that it is
sufficiently fast. (3) There is experience that it leads to a
maintainable system. (4) The effort to realize it for an arbitrary
TeX implementation is neglectable, assuming POSIX.1 equivalent system
functionality.
That's also the reason why I am against the `packages at the very
top' approach: There is no experience yet. I like the idea, 'though,
and think it should be given a try -- for a later revision of TDS.
In a mail some time ago, sebastian pointed out that this should not
be a second DVI Driver Standards committee, that does not produce
further results for years. Once again, I'm in agreement with him; the
involvement in this committee was a pain in the back.
Cheers,
Joachim
PS: Contrary to the opinion of many I was never and I am not the
chair of the DVI Driver Standards committee. I was the secretary
responsible in editing the level 0 document, as published in TUGboat,
not more. (Please excuse this personal note, but that's important to
me.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 12:59:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 24 Aug 1994 13:57:49 -0400
Message-ID: <199408241757.NAA22559@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Rehash: recursive searching
Reply-To: TWG-TDS@SHSU.edu
Rehashing again: (hopefully each time we go through this we'll get closer
and closer to a final resolution)
Following recent discussions:
It seems sufficient to say that recursive subdirectory searching is
a requirement and
- It needs to support arbitrary depth but need not support single
level or any specific number of levels
- The search order is system dependent
I know that this statement reads "non deterministic" in some eyes ;-)
but the more I think about it, the less I think that that is important.
It may be that some operating systems provide nice features for a
fully deterministic search (alphabetical order of files, strictly
breadth first, etc.) but that isn't true in any universal sense.
Requiring that implementors provide that sophisticated a search engine
in environments where it is non-trivial (both UNIX and DOS, for example,
return the files in their physical order on disk---which has no other
meaning) is impractical---implementors simply won't do it.
The argument that you must be able to know what order the search will
proceed in so that you can know which of two identically named files will
be found is flawed (IMHO).
1) If the files occur in two different search trees (like the latex
and latex209 trees, for example) then you *do* know which one will
be found!
2) If the files occur in the same tree, you've probably got problems
that the TDS can't hope to address---like two packages using the
same filename. Granted, if we had a modular search as Phil
suggested, it would be ok; but realistically we never have had such
a system so there's no reason to think that any author is
relying on it. (I'm not sure that it would really help anyway,
but send me private email if you want an example---let's not clutter
the TDS list more than necessary.)
I'm putting on my chairman's hat and moving to close this issue for this
version of the TDS. Objections?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 13:13:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Wed, 24 Aug 1994 14:11:34 -0400
Message-ID: <199408241811.OAA22794@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
References: <"swan.cl.cam.:273210:940823125601"@cl.cam.ac.uk> <m0qcwzn-00003QC@csrj.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 23 August 1994 at 15:38, Alan Jeffrey wrote:
> >it seems to me that the majority feel that fonts/vendor/familty/type
> >is nicer, but are worried about performance, and existing TeXs that
> >can't handle inline wildcards. is th the only objection?
>
> That's the main one. And I still don't see how to specify a printer
> mode without wildcards.
That's handled by the drivers with a different kind of wild carding, I
think. Both dvips and emtex's drivers use some kind of %-cards in the
font name to indicate the mode. [I'm sure someone will correct me if
I'm miss-remembering]. Something like "search for "%m/dpi%d/%f.pk"
where %m is the mode, %d is the resolution and %f is the font name.
So when the driver is recursively looking for a 320dpi version of
cmr10 for the canoncx mode, it's only ever going to match
'canoncx/dpi320/cmr10.pk'.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 13:19:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 AUG 94 19:18:43 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: Rehash: recursive searching
Message-ID: <202058F7_00360BE8.0098370D60476B06$31_6@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> I'm putting on my chairman's hat and moving to close this issue for this
>> version of the TDS. Objections?
I appreciate your desire both to bring this discussion to a close, and to move
on, but I'd prefer not to be associated with a proposal which I believe is
wrong: so, with regret, I ask you to excuse me from membership of this group.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 13:29:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 Aug 1994 13:29:34 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <009836DC.A4D385C4.326@SHSU.edu>
Subject: Re: determinism and breadth-firsters
On Wed, 24 Aug 1994 16:59:28 +0200 (MESZ), Joachim Schrod
<schrod@iti.informatik.th-darmstadt.de> posted:
> kpathsea -- that's the freely distributable library that does the file
> searching for web2c/xdvik/dvipsk -- was mentioned *very* often in the
> discussion of this mailing list. Without having checked it, I'm quite sure
> that George has organised archiving this mailing list, as always. Take a
> look at ftp.shsu.edu.
There are a few reference files in systems/web2c on ftp.shsu.edu (should be
on all CTAN hosts and mirrors). Karl may have something more specific on
this -- most likely included in one of the tar files in that directory.
As far as the archives -- look in the directory [FILESERV.TWG-TDS] on
Niord.SHSU.edu for the files via anonymous ftp. Alternately, look in the
"archives of TeX-related mailing lists run at SHSU.edu" (or somesuch
similar) on the gopher running on Niord.SHSU.edu where I am now building a
to-be-updated-nightly searchable index for the list.
--George
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 14:26:29 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qdN3p-00003QC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 24 Aug 94 19:28 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
>That's handled by the drivers with a different kind of wild carding, I
>think. Both dvips and emtex's drivers use some kind of %-cards in the
>font name to indicate the mode.
OK, if we go for fonts/<vendor>/... then are we going mandate
search pruning explicitly, or are we going to say implementors can do
what they like, but they might like to consider either search pruning
or directory caching plus %-cards?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Aug 1994 16:19:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408242120.XAA15241@spock.iti.informatik.th-darmstadt.de>
Subject: Re: the font hierarchy, for the umpteenth time
To: TWG-TDS@SHSU.edu
Date: Wed, 24 Aug 1994 23:20:39 +0200 (MESZ)
Content-Type: text
Alan wrote:
>
> OK, if we go for fonts/<vendor>/... then are we going mandate
> search pruning explicitly, or are we going to say implementors can do
> what they like, but they might like to consider either search pruning
> or directory caching plus %-cards?
IMO the latter, in a <implementation-hint> element, with an emphasis
that it will enhance efficiency. Perhaps the former can be mentioned
as one implementation strategy that should come early to mind.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 Aug 1994 03:32:09 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Rehash: recursive searching
Date: Thu, 25 Aug 1994 09:32:19 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:042500:940825083238"@cl.cam.ac.uk>
Joachim's and Norm's last postings made me happy. but it doesnt quite
resolve the font thing. i regard Alan's case as unproven, and getting
shakier, so i think we should revert to the current draft.
a paragraph somewhere in the TDS saying that the standard will be
reviewed once a year might help.
sebastian
PS i disagree about SGML, by the way. the IEEE would have vdlidated
LaTeX :-}
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 Aug 1994 03:34:35 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Rehash: recursive searching
Date: Thu, 25 Aug 1994 09:35:30 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:043750:940825083536"@cl.cam.ac.uk>
i dont think we should accept Phil's resignation without further
persuasion attempts! surely there is a difference, Phil, between a
standard which is not (in your eyes) rigorous enough in defining what
searching means, and one which is *wrong*. it what way is the current
TDS actually *bad*, as opposed to less than ideal? cant TDS/2 be more
positive about search order etc when we have some more experience?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 Aug 1994 06:46:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 AUG 94 12:43:31 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: Rehash: recursive searching
Message-ID: <21E0069E_000E42C0.0098379F5FF12BF5$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> i dont think we should accept Phil's resignation without further
>> persuasion attempts! surely there is a difference, Phil, between a
>> standard which is not (in your eyes) rigorous enough in defining what
>> searching means, and one which is *wrong*. it what way is the current
>> TDS actually *bad*, as opposed to less than ideal? cant TDS/2 be more
>> positive about search order etc when we have some more experience?
I appreciate your concern, but I really feel it is better for TWG-TDS
to move forwards without my disruptive influence. Norman quite reasonably
wants to reach a concensus as quickly as possible, and I feel that my
reservations are only serving to delay matters. So please allow me to
leave: I wish you all the best in your deliberations, and sincerely hope
that my reservations are ill-founded. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 Aug 1994 15:35:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 Aug 1994 15:35:27 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: Tom.Kiffe@math.tamu.edu
CC: twg-tds@SHSU.edu
Message-ID: <009837B7.653CDE84.177@SHSU.edu>
Subject: TDS and Mac -- FYI, fwd
I took the liberty to ask Tom Kiffe <Tom.Kiffe@math.tamu.edu>, a fellow
Texan located about 55 miles from here, who is developer of the CMacTeX
package, to have a look at some of the TDS items as they might impact on
implementations for the Mac or their feasibility for implementation or any
input he might offer. In between his current updating for version 2.2 of
CMacTeX, he was nice enough to have a look and respond. His kind reply of
Thu, 25 Aug 1994 14:54:05 -0500 was:
> I have looked at most of the traffic about the TeX Directory System and
> there is really very little that I could add to the discussion. I don't
> think there would be any problems on the Macintosh with any of the
> proposals. Filenames on the Macintosh can contain upto 32 characters, any
> printing characters in any order.
Since this is going to be a critical question in getting any kind of
acceptance for the TDS, I guess its worthwhile to ask if he might have an
interest in following the TDS once it is beyond its draft form (but that
can be handled privately). 8-)
Thanks for your input, Tom -- it's truly appreciated!
Regards, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Aug 1994 12:07:45 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qfABY-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 29 Aug 94 18:07 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Installing TDS under OzTeX
As promised, some notes on installing and running TDS under OzTeX.
I've been using it for a few days now, and it seems fine.
This is the relevant bit of the config file I ended up with:
Help folder = :texmf:oztex:help:
FMT folder = :texmf:oztex:formats:
TeX input folder(s) = :texmf:tex:latex:* |
:texmf:tex:plain:* |
:texmf:tex:hyphen:
TFM folder(s) = :texmf:fonts:tfm:adobe:* |
:texmf:fonts:tfm:knuth:* |
:texmf:fonts:tfm:misc:*
PK folder(s) = :texmf:fonts:pk:canoncx:knuth:* |
:texmf:fonts:pk:canoncx:misc:*
PS folder(s) = :texmf:oztex:ps: |
:texmf:oztex:ps:Encodings:
Text-to-PS prolog = :texmf:oztex:ps:TEXTtoPS.ps
DVI-to-PS prolog = :texmf:oztex:ps:DVItoPS.ps
VF folder(s) = :texmf:fonts:vf:adobe:* |
:texmf:fonts:vf:misc:*
Features that aren't compliant with TDS v0.41:
* fonts/<type> rather than fonts/<source> as you'd expect.
* an `oztex' directory under texmf for OzTeX-specific files. This is
instead of the ini/<system> directory.
* OzTeX lives in the same folder as the texmf folder, which is why all
the paths can be given as relative paths rather than absolute paths
(e.g. "Macintosh HD:TeX:texmf:oztex:help:"). This is important, since
otherwise installing config files (eg when upgrading versions of
OzTeX) is a pain.
* the `Configs' folder *has* to live in the same folder as the OzTeX
application.
* `misc' rather than `public' as the home for miscellaneous fonts.
* `300' rather than `dpi300' for the pk directory name,
since this is what OzTeX searches for.
* Mac Bibtex and Mac Makeindex can't cope with specifying folders or
aliases, so the bibtex and makeindx folders are pretty useless.
The fonts area ended up looking like this (this is the TFM area, the rest
is similar):
tfm
adobe
courier
helvetic
mathptm ** should this be part of times?
symbol
times
zapfchan
knuth ** not part of 0.41, but I feel CM shouldn't be in misc
cm
concrete
dc ** not by DEK, but where else?
misc ** manfnt, logo, etc.
misc
ams ** or should the AMS be a source?
bbold
flint
latex
malvern
mcyr
mon
oldgerm ** or should Yannis be a source?
stmary
wncyr
wnipa
So modulo the fonts directory structure and the texmf/SYSTEM directory,
it pretty much works.
I think it would be useful to have appendices in the report `Implementing
TDS for system FOO'. I can write an OzTeX one, if suitable volunteers
can be found for other systems.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Aug 1994 15:16:42 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 29 Aug 1994 16:14:49 -0400
Message-ID: <199408292014.QAA15556@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: CHAA006@VAX.RHBNC.AC.UK
Subject: Re: Rehash: recursive searching
References: <21E0069E_000E42C0.0098379F5FF12BF5$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
On 25 August 1994 at 12:43:31, CHAA006@vax.rhbnc.ac.uk wrote:
> >> i dont think we should accept Phil's resignation without further
> >> persuasion attempts! surely there is a difference, Phil, between a
> >> standard which is not (in your eyes) rigorous enough in defining what
> >> searching means, and one which is *wrong*. it what way is the current
> >> TDS actually *bad*, as opposed to less than ideal? cant TDS/2 be more
> >> positive about search order etc when we have some more experience?
>
> I appreciate your concern, but I really feel it is better for TWG-TDS
> to move forwards without my disruptive influence. Norman quite reasonably
> wants to reach a concensus as quickly as possible, and I feel that my
> reservations are only serving to delay matters.
Phil,
I never felt that your observations where disruptive, and I sincerely
hope that I didn't offend you in some way. I think that a happy
medium can be reached between the most theoretically perfect solutions
and the most practical. I'm sorry that you don't feel the same way.
As I've stated before, I feel strongly that we must move forward and
produce an initial specification. After the TDS exists, there will
naturally be a period of experimentation and refinement. I hope that
we can convince you to return to the discussion as it evolves into
something more theoretical and speculative.
In the meantime, your comments have given us new avenues to explore
and I thank you for them. You will be missed.
> So please allow me to
> leave: I wish you all the best in your deliberations, and sincerely hope
> that my reservations are ill-founded. ** Phil.
I hope so to.
Warmest regards,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Aug 1994 06:38:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408301139.NAA15610@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS under OzTeX
To: TWG-TDS@SHSU.edu
Date: Tue, 30 Aug 1994 13:39:09 +0200 (MESZ)
Content-Type: text
Alan wrote:
>
> * an `oztex' directory under texmf for OzTeX-specific files. This is
> instead of the ini/<system> directory.
What's in this directory? Config files? FMT files? Is it possible to
move the latter to ini/oztex/ ?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Aug 1994 07:43:36 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qfSXj-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 Aug 94 13:44 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS under OzTeX
>> * an `oztex' directory under texmf for OzTeX-specific files. This is
>> instead of the ini/<system> directory.
>What's in this directory? Config files? FMT files? Is it possible to
>move the latter to ini/oztex/ ?
Contents:
texmf/oztex/formats -- format and pool files
texmf/oztex/ps -- downloaded PS files
texmf/oztex/help -- online help files
In general, I think it's fair to allow TeX implementations to have
arbitrary stuff in their texmf/SYSTEM directory. Of course, we could
put all the SYSTEM directories into one directory under texmf, but it
seems a bit odd that xfig, dvips etc. get directories under texmf, but
TeX implementations don't!
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Aug 1994 08:44:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 Aug 94 14:45:39 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9408301345.AA12426@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: the font hierarchy, for the umpteenth time
Alan says.
> but I'd like to point out that my other partner in crime in
> suggesting this directory structure (David Carlisle) is on holiday
> at the moment.
I'm back today, but still got a few hundred messages to catch up on.
So I may reply in detail later.
But I agree with Alan: If we tell people to search over all the pk
files to load a tfm file, they will *not* use the tds structure at
all.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Aug 1994 09:12:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408301413.QAA14163@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS under OzTeX
To: TWG-TDS@SHSU.edu
Date: Tue, 30 Aug 1994 16:13:11 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >> * an `oztex' directory under texmf for OzTeX-specific files. This is
> >> instead of the ini/<system> directory.
>
> >What's in this directory? Config files? FMT files? Is it possible to
> >move the latter to ini/oztex/ ?
>
> Contents:
>
> texmf/oztex/formats -- format and pool files
> texmf/oztex/ps -- downloaded PS files
> texmf/oztex/help -- online help files
>
> In general, I think it's fair to allow TeX implementations to have
> arbitrary stuff in their texmf/SYSTEM directory. Of course, we could
> put all the SYSTEM directories into one directory under texmf, but it
> seems a bit odd that xfig, dvips etc. get directories under texmf, but
> TeX implementations don't!
Oh, I wasn't against the <system> directory under texmf/. I was more
speculating about moving the ini/<system> stuff to that directory and
to get rid of the ini/ directory instead. Reading my mail again, I
notice that I didn't express my thoughts in a good way.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Aug 1994 09:17:48 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qfU0l-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 Aug 94 15:18 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS under OzTeX
>Oh, I wasn't against the <system> directory under texmf/. I was more
>speculating about moving the ini/<system> stuff to that directory and
>to get rid of the ini/ directory instead.
That's exactly what I was proposing :-)
I think the original idea was that the only implementation-specific
files were `ini' files (eg formats, pools, etc.) This ain't
necessarily so...
But there is a problem with allowing arbitrary texmf/SYSTEM
directories, which is that the texmf directory may end up rather
cluttered with one directory for every TeX implementation, MF
implementation, driver, etc. But I'm not sure what else to suggest...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 Aug 1994 05:18:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 Aug 1994 06:19:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408311019.AA04745@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: tex input directories
TeX input folder(s) = :texmf:tex:latex:* |
:texmf:tex:plain:* |
:texmf:tex:hyphen:
Can someone summarize the current scheme for TeX input directories?
I got lost in the maze of generic vs. plain vs. hyphen, whether plain
should be in the latex path (no, right?), where things that work under
both latex and plain work (generic?), whether initex-only stuff gets put
in its own directory, etc., etc.
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 Aug 1994 05:18:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 Aug 1994 06:19:34 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199408311019.AA04737@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: font sources
TFM folder(s) = :texmf:fonts:tfm:adobe:* |
:texmf:fonts:tfm:knuth:* |
:texmf:fonts:tfm:misc:*
OK, let's talk about font sources.
Here's my thoughts:
1) For fonts that do follow the fontname scheme, I think the
directory names should precisely follow the scheme: ptm ==
adobe/times, fmv = public/malvern (or something/malvern, I'm not
wedded to public/; misc/ would probably be better).
2) All directory names must have only two levels, that is,
source/typeface. E.g., misc/ams/cyrillic is a loser; either
misc/cyrillic or ams/cyrillic. I don't have strong opinions about
which, but since the AMS already has their fonts packaged up, a
separate ams/ source directory would be clean and unobjectionable, I
think.
3) For fonts that don't follow fontname -- cm*, dc*, cc*, pn*, ... -- I
don't have strong opinions, since they are a special case anyway. I
personally don't see much point to having knuth/ or yannis/ or
whatever, but it doesn't matter much to me one way or another.
Overclassifying all the people/companies with one or two typefaces seems
like a lose. The time that having a separate source directory really
matters is if the foundry (or whatever) has dozens of typefaces. A
large part of having the font hierarchy in the first place was to avoid
having huge directories; on the other hand, having zillions of tiny
directories seems almost as bad. I don't think there is any perfect a
priori scheme to arrange everything, any more than there is for TeX
inputs; things just have to be arranged as best as possible.
I never intended to make (nor do I think I ever made) the distinction
between ``commercial'' and ``non-commercial'' (viz. I have always had
ams/ as a source). It's more like ``many'' and ``few'', which, as it
happens, boils down to almost the same thing.
As for dc/, if knuth/ does get his own source directory, then I think
dc/ goes in misc/, not knuth/.
I will append a small mapping file (will be in the next release of
fontname) that lists the common special cases. I know it's incomplete.
It still uses public/, but changing to misc/ would be
% @mapfile{
% [blah blah blah]
% }
% First the extra CM fonts from the AMS, where the names must match exactly.
cmbsy5 ams extracm
cmbsy6 ams extracm
cmbsy7 ams extracm
cmbsy8 ams extracm
cmbsy9 ams extracm
cmcsc8 ams extracm
cmcsc9 ams extracm
cmex7 ams extracm
cmex8 ams extracm
cmex9 ams extracm
cmmib5 ams extracm
cmmib6 ams extracm
cmmib7 ams extracm
cmmib8 ams extracm
cmmib9 ams extracm
manfnt public misc
% The rest all have pointsizes on the end, so the pattern to search for
% is $1.*[0-9]$.
cm public cm
dc public dc
cc public concrete
icm public latex
ilcm public latex
lasy public latex
lcm public latex
lcirc public latex
line public latex
logo public logo
pn public pandora
wn ams cyrillic
eu ams euler
msam ams symbols
msbm ams symbols
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 Aug 1994 05:45:42 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qfnB8-00007DC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 31 Aug 94 11:46 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>1) For fonts that do follow the fontname scheme, I think the
> directory names should precisely follow the scheme: ptm ==
> adobe/times, fmv = public/malvern (or something/malvern, I'm not
> wedded to public/; misc/ would probably be better).
misc/ is fine by me... My problems with public/ are just that sorting
fonts by cost is a rather strange mechanism :-)
>2) All directory names must have only two levels, that is,
> source/typeface. E.g., misc/ams/cyrillic is a loser; either
> misc/cyrillic or ams/cyrillic. I don't have strong opinions about
> which, but since the AMS already has their fonts packaged up, a
> separate ams/ source directory would be clean and unobjectionable, I
> think.
If we're having ams as a source, are we allowing anyone who
distributes ~10 families a source directory? If the ams get in, then
why not Yannis, who's got at least as many fonts under his belt?
>3) For fonts that don't follow fontname -- cm*, dc*, cc*, pn*, ... -- I
> don't have strong opinions, since they are a special case anyway. I
> personally don't see much point to having knuth/ or yannis/ or
> whatever, but it doesn't matter much to me one way or another.
My main attatchment to a `knuth' directory is politeness. I think it
would be rather rude of us to stick cm and friends into `misc'.
Really I'd like a directory name that meant
`cm+dc+concrete+manfont+logo' ie the fonts whose glyph shapes were
designed by DEK. Were it not for the dc fonts, `knuth' would be a
good name.
>As for dc/, if knuth/ does get his own source directory, then I think
>dc/ goes in misc/, not knuth/.
One possibility. Seems a bit odd having cm and dc so far away from
each other, but hey ho... Swings and roundabouts.
>cmbsy5 ams extracm
Should these be in a separate directory from the other CM fonts?
Some of these are `standard LaTeX fonts' so for LaTeX users they're
not options any longer.
Alan.
From owner-twg-tds@shsu.edu Thu, 01 Sep 1994 07:01:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409011202.OAA17356@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Thu, 1 Sep 1994 14:02:25 +0200 (MESZ)
Content-Type: text
You wrote:
>
> TeX input folder(s) = :texmf:tex:latex:* |
> :texmf:tex:plain:* |
> :texmf:tex:hyphen:
>
> Can someone summarize the current scheme for TeX input directories?
I can summarize what I think is the current scheme. Things where I
was unsure are marked by `????'...
texmf/
tex/
<format>/ % in general
<package>/ % in general
base/ % reserved package name ????
misc/ % reserved package name
latex/ % allocated format name
distrib/
<package>/ % as above
contrib/
<package>/ % as above, without base/
hyphen/ % reserved format name
<language>/
generic/ % reserved format name:
% INITeX processable files
% e.g., fontinst
Actually, I don't like generic/. I would rename it to initex/ or
none/, IMO it makes clearer what's in this directory.
I was/am in favor of an additional directory, first proposed by sebastian:
plaincodes/ % reserved format name:
% files for all <format>s that
% use plain TeX catcodes.
> I got lost in the maze of generic vs. plain vs. hyphen, whether plain
> should be in the latex path (no, right?), where things that work under
> both latex and plain work (generic?),
The last two issues were not resolved. (Above is my opinion. :-)
If anybody has a different view on our discussion results, please name
them.
On a related topic, concerning web2c: How do you think you'll realize
different search paths for different executable names? (I'm referring
to your question ``whether plain should be in the latex path'' --
there is no latex path currently, right?)
I'm interested more platonically: I use shell script wrappers
anyhow; there I can set TEXINPUTS for each <format> and do not depend
on path names compiled into the executable. (I did mention that I
*hate* software systems that I cannot easily move around, did I?) The
overhead for the shell script is neglectable anyhow, compared to the
load time of TeX + FMT file over NFS.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 01 Sep 1994 07:35:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 01 Sep 1994 07:35:01 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00983CF4.7059F684.34@SHSU.edu>
Subject: Re: tex input directories
On Thu, 1 Sep 1994 14:02:25 +0200 (MESZ),
Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> posted:
> I can summarize what I think is the current scheme. Things where I
> was unsure are marked by `????'...
>
> texmf/
> tex/
> <format>/ % in general
> <package>/ % in general
> base/ % reserved package name ????
> misc/ % reserved package name
> latex/ % allocated format name
> hyphen/ % reserved format name
> <language>/
> generic/ % reserved format name:
> % INITeX processable files
> % e.g., fontinst
>
> Actually, I don't like generic/. I would rename it to initex/ or none/,
> IMO it makes clearer what's in this directory.
Instead of "generic/" might "base/" be an acceptable name? These kinda are
the "base" aren't they and they are in line with a wording we are already
using to some extent.
> I was/am in favor of an additional directory, first proposed by sebastian:
>
> plaincodes/ % reserved format name:
> % files for all <format>s that
> % use plain TeX catcodes.
And would it be acceptable to simply include the proposed plaincodes/ into
base/ (or have I screwed up my concepts again -- I'll admit to being in
over my head on this).
--GDG
================================================================================
From owner-twg-tds@shsu.edu Thu, 01 Sep 1994 08:14:15 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qgB6p-0006PTC@rsuna.crn.cogs.susx.ac.uk>
Date: Thu, 1 Sep 94 13:19 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
> generic/ % reserved format name:
> % INITeX processable files
> % e.g., fontinst
I suppose I ought to make fontinst iniTeX processable to justify this
:-) If we're splitting generic into to two directories, then initex
or virtex seem like better names. But I'm not sure there's enough
files to justify initex and plaincodes, so generic may be better.
>On a related topic, concerning web2c: How do you think you'll realize
>different search paths for different executable names? (I'm referring
>to your question ``whether plain should be in the latex path'' --
>there is no latex path currently, right?)
On systems like web2c this will presumably be with scripts. On
systems like OzTeX there's no mechanism for pruning the search path
(apart from config files, which Andrew doesn't like since it scuppers
a lot of the nice drag'n'drop facilities of OzTeX).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 01 Sep 1994 10:10:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409011511.RAA16475@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Thu, 1 Sep 1994 17:11:24 +0200 (MESZ)
Content-Type: text
Goerge wrote:
>
> > generic/ % reserved format name:
> > % INITeX processable files
> > % e.g., fontinst
> >
> > Actually, I don't like generic/. I would rename it to initex/ or none/,
> > IMO it makes clearer what's in this directory.
>
> Instead of "generic/" might "base/" be an acceptable name? These kinda are
> the "base" aren't they and they are in line with a wording we are already
> using to some extent.
>
> > I was/am in favor of an additional directory, first proposed by sebastian:
> >
> > plaincodes/ % reserved format name:
> > % files for all <format>s that
> > % use plain TeX catcodes.
>
> And would it be acceptable to simply include the proposed plaincodes/ into
> base/ (or have I screwed up my concepts again -- I'll admit to being in
> over my head on this).
Just for the record: I would like to combine these two directories
into one. In fact, on my machine it is one directory named inputs/.
I.e., it's the macro directory which was on any TeX installation from
the very beginning and currently holds all files I haven't moved to
<format>-specific directory trees at some time. Let's look:
spice $ ll /common/tex+mf/tex/inputs/
total 312
-rw-r--r-- 1 tex software 15314 Jun 17 1993 cwebmac.tex
drwxr-sr-x 2 tex software 512 Jul 29 08:42 doc
-rw-r--r-- 2 tex software 30216 Jan 12 1993 german.sty
-rw-r--r-- 2 tex software 30216 Jan 12 1993 german.tex
-rw-r--r-- 1 tex software 1550 Jun 7 1993 specials.sty
-rw-r--r-- 1 tex software 2280 Jul 23 1993 logos.sty
-rw-r--r-- 1 tex software 2193 Mar 9 1993 names.sty
-rw-r--r-- 1 tex software 212 Aug 13 1989 null.tex
-rw-r--r-- 1 tex software 20758 Jun 7 1993 tables.tex
-rw-r--r-- 1 tex software 31278 Aug 29 1993 tugboat.cmn
But somebody (I don't remember who) complained that there <format>s
that cannot read arbitrary files since they use other catcodes
settings. That's true, I'm guilty myself writing a nroff emulating
<format> that cannot use any of the above files. So there seemed to be
the need for another name for that directory.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 01 Sep 1994 18:46:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Sep 94 16:44:16 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409012344.AA03303@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: plaincodes (EEP!)
PLEASE don't use names with more than eight characters!
-r
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 05:41:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Sep 1994 06:42:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409021042.AA11752@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: font sources
are we allowing anyone who
distributes ~10 families a source directory?
``allowing'' seems an awfully strong term. I'm sorry, I just don't see
directory names as a big moral issue :-)
If the ams get in, then
why not Yannis, who's got at least as many fonts under his belt?
I don't know, I never really thought about it, since I've only used a
couple of his fonts.
Since his names don't follow fontname (right?), I guess having a yannis/
source is fine.
I wonder, though -- we don't want to be gratuitiously incompatible with
CTAN. The AMS fonts are distributed as a package. PostScript fonts
(some of them, anyway) come in a package. Do Yannis'? I don't think
so. I guess this is the main reason why I've been putting all the
miscellanous Metafonts into one directory ... they're not distributed
in groups.
My main attatchment to a `knuth' directory is politeness. I think it
would be rather rude of us to stick cm and friends into `misc'.
I don't see ``rude''. But I don't feel strongly about it, so I bow to
yours and others' judgment.
Seems a bit odd having cm and dc so far away from
each other
Put them all in misc/, then :-)
Should these be in a separate directory from the other CM fonts?
Yes. IMO. They are files created and distributed by the ams, not part of
the standard CM set. Why put them in the same directory? That defeats
the whole purpose, to my mind.
Some of these are `standard LaTeX fonts' so for LaTeX users they're
not options any longer.
Bully for them. The extracm fonts were still separately created. All
fonts are optional for people who don't want to use them, after all.
I don't see the TDS as trying to divide things by ``optional'' and
``non-optional''. Or how it could, for that matter. The goal, as I
understood it -- certainly the goal of Pierre's and my original
directory hierarchy -- was to structure the TeX library files in a way
that made upgrades or whatever maintenance easier.
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 06:32:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Sep 94 12:32:50 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409021132.AA15317@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: font sources
A> Some of these [ams extracm] are `standard LaTeX fonts' so for
A> LaTeX users they're not options any longer.
K> Bully for them. The extracm fonts were still separately created. All
K> fonts are optional for people who don't want to use them, after all.
I'm not really that bothered about where we place individual fonts.
However perhaps the disagreement here is due to the fact that the rest
of you probably are not aware that the AMS *explicitly* gave us (L3 team)
permission to unbundle those extra cm fonts out of the amsfonts
distribution, and distribute them as part of standard LaTeX. Of course
they are still in amsfonts as well. ctan just has the appropriate
symbolic links, but as we know we have to pretend that we have never
heard of links in this forum....
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 06:57:04 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qgXFG-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 2 Sep 94 12:57 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>the AMS *explicitly* gave us (L3 team)
>permission to unbundle those extra cm fonts out of the amsfonts
>distribution, and distribute them as part of standard LaTeX.
And the upshot of this is that A. N. User (or his sister A. N.
Sysadmin) using LaTeX just sees a bunch of CM fonts. They have no
reason to know that some of these fonts had parameter files written by
DEK and some by the AMS.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 07:01:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409021202.OAA15119@spice.iti.informatik.th-darmstadt.de>
Subject: Re: font sources
To: TWG-TDS@SHSU.edu
Date: Fri, 2 Sep 1994 14:02:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >the AMS *explicitly* gave us (L3 team)
> >permission to unbundle those extra cm fonts out of the amsfonts
> >distribution, and distribute them as part of standard LaTeX.
>
> And the upshot of this is that A. N. User (or his sister A. N.
> Sysadmin) using LaTeX just sees a bunch of CM fonts. They have no
> reason to know that some of these fonts had parameter files written by
> DEK and some by the AMS.
Yeah, but they won't (read: should not have to) look in the fonts/
directory either.
Remember: the TDS benefits directly system administrators and
distributors, not end users. And in particular for the sysadmins the
difference (DEK vs. AMS) is crucial, it's the difference where to
find the source and what to delete in case of updates.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 07:01:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qgXJs-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 2 Sep 94 13:02 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>``allowing'' seems an awfully strong term. I'm sorry, I just don't see
>directory names as a big moral issue :-)
Funnily enough, I don't really care either. I just wanted to point
out that the current scheme was a bit underspecified. I do think
that a CM+concrete+manfont+logo+... directory would be polite to DEK
though.
>Bully for them. The extracm fonts were still separately created. All
>fonts are optional for people who don't want to use them, after all.
If you want to use CM under LaTeX these days, the extracm fonts aren't
optional at all (see thousands of `where can I get cmmib8?' messages
on c.t.t.).
Something like:
knuth-or-a-better-name-please
cm
concrete
dc
extracm
misc
would seem good to me.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 07:06:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409021207.OAA15132@spice.iti.informatik.th-darmstadt.de>
Subject: Re: font sources
To: TWG-TDS@SHSU.edu
Date: Fri, 2 Sep 1994 14:07:25 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Something like:
>
> knuth-or-a-better-name-please
> cm
> concrete
> dc
> extracm
> misc
Thinking about it -- I had such a directory. I called it knuth-modern.
It subsumed all fonts that are derived from DEKs MF programs/driver
files. These were _not_ stored under cm/, there were only the cm
parameter files.
But then came this new notion of foundries up, and I changed
everything... :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 07:08:32 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qgXQR-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 2 Sep 94 13:08 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>Remember: the TDS benefits directly system administrators and
>distributors, not end users. And in particular for the sysadmins the
>difference (DEK vs. AMS) is crucial, it's the difference where to
>find the source and what to delete in case of updates.
Presumably the CTAN structure will mirror whatever structure we come
up with (at least via symbolic links) so this is a good argument for
putting the CM extra fonts somewhere next to the CM fonts. At the
moment to install CM for LaTeX, a sysadmin has to get DEK's CM fonts,
and the extracm from a completely different directory. This is not
cool.
Putting them in an extracm directory is fine. Putting the extracm
directory miles away from the cm directory is not. Unless you want to
be seeing those `where is cmmib8?' messages for the forseeable
future...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 08:23:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 02 Sep 1994 08:23:30 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00983DC4.606FE744.32@SHSU.edu>
Subject: Re: font sources
Following up on Karl's post of Fri, 2 Sep 1994 06:42:02 -0400:
> I don't see the TDS as trying to divide things by ``optional'' and
> ``non-optional''. Or how it could, for that matter. The goal, as I
> understood it -- certainly the goal of Pierre's and my original directory
> hierarchy -- was to structure the TeX library files in a way that made
> upgrades or whatever maintenance easier.
I, too, was under this impression. Not so much what is or is not optional
as that would defeat to a large extent the portability of TeX (not so much
OS portability as portability of what and how you and I and everyone else
approach things using TeX). For LaTeX users, extracm is indeed needed --
but only for LaTeX users (and other places where these are kinda needed).
If I were personally in a space crunch, I can promise you that my fonts
would be reduced to the standard CM set, plus those used by LaTeX, and
probably very few others.
The beauty of the Karl and Pierre's approach is that, as Karl notes,
maintenance is easier. The very important extra item he omits is the
"without losing functionality" clause. The beauty of the TDS, at least my
impression of it, is that I can "see" if something is available for use.
For example, if I get on another machine somewere, I know I can look in
(say) <whatever-the-hell-texmf/-translates-to>/fonts/source/family/type (or
whatever structure is adopted) to see is a certain file exists on a system
(or macros or whatever). Having something this consistent and nice would
have been a real help in Santa Barbara during TUG94, for example, when I
was forced onto Mac and MS-DOS to do some work (and a few files I routinely
use here didn't exist there -- but do now 8-)).
--George
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 08:23:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 02 Sep 1994 09:24:16 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: font sources
To: TWG-TDS@SHSU.edu
Message-ID: <778512256.731842.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
(i'm just catching up on the traffic after being away at a standards
meeting for two weeks. since the committee i'm on is the one that
spawned sgml, i must admit some amusement at joachim's comments on
the differences between ieee and iso; i would tend to disagree that
ansi x3v1, at least, is closer in philosophy to ieee than iso -- after
all, x3v1 is responsible in the u.s. for oda as well as sgml ...)
regarding packaging of the fonts that ams "claims", there are two
reasons for requesting some clear identification of ams as the
source: so that we can create unconfusing and unambiguous
documentation, and so that people will know where to go if there
are problems. in the case of extracm the problems have (thankfully)
been few -- but there *have* been problems. (for one font, the
sauter parameter set yields slight differences, including checksum,
from the ams parameters, though both have been "blessed" by knuth;
we're working on getting that anomaly obliterated.) and that's the
reason that on ctan the actual extracm files are in the ams area,
while the latex area holds links. that's not possible on a cd-rom,
as someone has already mentioned. nonetheless, we really would
appreciate it if our job were not made more complicated than
necessary.
separating the extracm from other ams-source files wouldn't be a
real big thing, and certainly it's logical to place them near the
"original" cm's, but ... i don't know whether there are any extra
cm's on ctan that were generated from the sauter parameters -- if
there are, i do hope they're not merged with the ones from ams.
doing that, plus scattering the rest of the ams fonts (euler, ms*m,
wncy*, ...) without any identification would be a nightmare. (i
assume the sauter parameters *will* be included in the collection.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Sep 1994 09:00:08 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qgZAL-00006mC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 2 Sep 94 15:00 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>separating the extracm from other ams-source files wouldn't be a
>real big thing, and certainly it's logical to place them near the
>"original" cm's, but ... i don't know whether there are any extra
>cm's on ctan that were generated from the sauter parameters -- if
>there are, i do hope they're not merged with the ones from ams.
Eek no, mixing the AMS and Sauter CM extensions would certainly be a
bad move! Something like:
knuth-derived-fonts-in-eight-letters
cm
cmams
cmsauter
concrete
dc
misc
perhaps? Of course this raises the problem of what you do if you've
got both the AMS and the sauter fonts, but hey ho...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 03 Sep 1994 06:29:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 3 Sep 1994 07:30:05 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409031130.AA03870@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: font sources
Look, extracm/ are fonts created, distributed, maintained, and
updated by the ams. Therefore they should go in ams/extracm,
The alternative is to either make this a special case
(which I am vehemently against) or to completely rework
the font hierarchy in some completely different and as-yet-undetermined
way. If someone has an alternative proposal, I'd love to hear it.
But let's not ad hoc everything in sight. Otherwise, what's the point?
We might as well give up now.
Sauter generates the same TFM's for the extracm fonts as the
AMS parameter files. It didn't always, but I made them do so
a while ago.
There's some other set of Computer Modern fonts, though, called
``text1'' or something like that. I think they are different TFM's.
I never really looked into them; it was on my list, but never got done.
================================================================================
From owner-twg-tds@shsu.edu Sat, 03 Sep 1994 12:05:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 03 Sep 1994 13:06:00 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: font sources
To: TWG-TDS@SHSU.edu
Message-ID: <778611960.879804.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
thanks to karl for the verification that the sauter parameters now
generate the same tfm's for the extracm fonts; i thought the problems
had been fixed, but couldn't find a record.
regarding the text1 package, there are indeed quite a few extra cm's
in it. all are present in macros/text1/fonts/... on ctan at shsu.
mostly the .mf parameter files are for integral point sizes of 11,
12, 14, 18, 24, and 36, with 12 usually absent when that's already
available in the canonical knuth set. for the most part, there are
no "competitors" are on ctan (but see below). there are also several
files for smaller sizes:
cmbxti8, 9
cmcsc8, 9
cmssbx9
of these, the only ones in possible conflict are the two cmcsc's,
which are also present in the ams collection; i don't know whether
they generate the same tfm's (like karl, we never had time to look
into it).
in the directory systems/knuth/local/cm there are 14 .mf files for
cm styles and sizes not in the canonical 75. these, i believe,
should indeed be placed into an extracm area linked to the main
cm's, and identified as originating with knuth; they're not
described anywhere in "computers & typesetting a-e" though some
of them may be used there. (the directory also holds the concrete
fonts, some files named gen*.mf, and odigs.mf; i didn't research
what the latter two are used for.) at any rate, there is indeed
a duplicate file name in the text1 collection:
cmbxti12
again, i don't know whether the tfm's come out the same.
there are some other conflicts as well with these knuth extras:
cmcscsl10 -- macros/latex209/contrib/asaetr
cmman.mf -- fonts/cm/utilityfonts/manualfonts
(probably the same; file length differs by 2 bytes)
the concrete .mf file names also appear in fonts/concrete -- these
have later dates than the ones in systems/knuth/local/cm and are
probably the authoritative ones. all conflicts should be checked
and the non-authoritative ones removed, if possible, from ctan
before the cd master is made. can someone volunteer to check
this, please? (the files ascribed to knuth should also be
investigated at labrea, and if there are duplicates, it should
be relatively easy to decide which are correct. i suspect there
will be only one .tfm file for each, that can be associated by
date with one of the .mf's; i also suspect that most of the
difference will be in a comment header rather than in anything
significant. if there *are* "duplicates" at labrea, the person
to contact is dan kolkowitz, kolk@cs.stanford.edu, the volunteer
maintaining the tex portion of the labrea installation.)
sorry to bother this group with all these details, but they really
should get cleared up and not be perpetuated by polluting the cd.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sat, 03 Sep 1994 12:24:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 03 Sep 1994 19:25:27 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: font sources
To: TWG-TDS@SHSU.edu
Message-ID: <01HGOQ3AUS0Y934POK@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I dont know if the text1 package is still supported and maintained by
someone. Their fonts are buggy---sorry to say so, but this is the fact.
For example text1's cmcsc14.mf claims a design_size for 14 point, but is in
fact (as can be examined from the height parameters) a 14.4 font. This
leads to endless troubles, if you try to load it at 14.4pt.
I vote for not including those fonts at all into a cd or TDS, unless new
information comes up and makes me revise my mind.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Sat, 03 Sep 1994 12:34:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 3 Sep 94 18:35:53 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409031735.AA16459@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: font sources
K> Look, extracm/ are fonts created, distributed, maintained, and
K> updated by the ams. Therefore they should go in ams/extracm,
Sounds reasonable to me. Some people will probably just have `LaTeX
fonts' without the full amsfonts collection, and they may have to find
some ad hoc place to stick the extracm fonts (probably with the other
latex fonts) but any reasonable TeX setup ought to have amsfonts
anyway so there does not seem to be any reason for us to worry about
this.
David
================================================================================
From owner-twg-tds@shsu.edu Sun, 04 Sep 1994 07:58:48 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qhHA5-000072C@csrj.crn.cogs.susx.ac.uk>
Date: Sun, 4 Sep 94 13:59 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font sources
>K> Look, extracm/ are fonts created, distributed, maintained, and
>K> updated by the ams. Therefore they should go in ams/extracm,
Since barbara's on this list, I think we can just leave it up to
her---we just stick the AMS fonts wherever the AMS want them.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 07 Sep 1994 18:46:18 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 7 Sep 1994 16:45:58 -0700
From: mackay@cs.washington.edu
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409072345.QAA04470@manta.cs.washington.edu>
To: rcpt@urc.tue.nl
CC: TWG-TDS@shsu.edu, unixtex@u.washington.edu, mackay@cs.washington.edu
Subject: PK specials for ps2pk
The discussions of the TUG Working Group on establishing
a TeX Directory Standard (TWG-TDS) have agreed that
the wretched 8+3 filename restrictions of DOS will
have to be obeyed if the standard is to have any
generality at all. This decision causes some real
difficulties for the rest of us, among which is
the fact that <fontname>.<DPI>pk is impossible
in such a straitjacketed environment. The
reluctantly reached compromise is to use
a tree ending in something like
.../pk/dpi300/cx/
and to allow only the extension .pk on fontnames
in strict conformity with the TDS. (I hasten to assure
you that <fontname>.<DPI>pk will not go out of existence,
certainly not while we Unix people retain a voice.)
At the time of the decision, I was very unhappy about
the notion of maintaining a file system with a dozen or
so files all named cmr10.pk, and distinguished only
by locality. I still am, but I think that some
amelioration of the situation can come if every
PK font contains the PK specials which are provided
in Karl Berry's modes.mf file for METAFONT output.
But ps2pk doesn't use modes.mf, and I have therefore added
some code to your program to achieve the same effect.
The diff files generated from ps2pk14 sources have
been sent to you under separate cover, along with
a revised ps2pk.1.
The idea is to provide not only an internal identification
of the font, so that one version of putr.pk (DOS style short
name for Utopia-Regular) can be distinguished from another,
but also a reasonable indication of how a closely similar
pk file could be generated from METAFONT source.
Here is an example. This font is presumed to be generated
for a CItoh 310 printer at 144x240 dpi. The Xres value
however is 300, so the font is generated as Utopia-Regular10.300pk.
which would go into the TDS tree as .../pk/dpi300/citohtoz/putr.pk
The command line for this was:
ps2pk -v -R 240 -r 144/240 -X 300 Utopia-Regular.pfa
where the new switches are -R<baseresolution> and -r<aspect_ratio>
( The -Y value is in this instance derived from the aspect_ratio. )
The specials out of this font as listed by pktype are:
4069: Special: 'fontid=Utopia-Regular'
4092: Special: 'codingscheme=AdobeStandardEncoding'
4128: Special: 'fontfacebyte'
4142: Num special: 15335424
4147: Special: 'mag=1.250'
4158: Special: 'mode=ps2pk output'
4177: Special: 'pixels_per_inch=240'
4198: Special: 'aspect ratio=144 / 240'
4222: Postamble
The "mag" value has here come out as a direct value.
If it had been close to a magstep, it would have been
expressed as a magstep.
The only thing that is missing is the indication that this was
intended as output for the CItoh 310. Perhaps that should be added.
It would be easy to change the mode special to
'mode=CItohThreeOneZero(ps2pk)' or 'mode=citohtoz(ps2pk)'
by adding a -m<mode> switch to the command line. I would want to preserve
the indication that this was ps2pk output here as well as in the
initial comment. I more or less must do this to be honest, since
the mode is not really the same as that in modes.mf.
But 'mf "\mode=citohtoz; mag=1.250;" input putr.mf'
would produce a roughly equivalent result.
I have tried to make sure that the necessary values for
the generation of these specials can be found easily in
utilities such as MakeTeXPK.
Please let me know what you think of this. The proliferation of
options is perhaps unfortunate, but ps2pk is very likely to be
run inside a script, so the options will be generated
mechanically.
The collected file of diffs is on june.cs.washington.edu
in ~ftp/tex/ps2pk-m.tar.gz
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 05:18:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 8 Sep 1994 06:18:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081018.AA27216@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: font families
I'm not sure where we left the typeface family names discussion, but I
thought of one small reason recently to minimize the number of family
names -- if we're catering to deficient implementations that force users
to use paths like $TEXMF/fonts/tfm/adobe:$TEXMF/fonts/tfm/other:..., the
fewer families there are, the better. In fact, I suspect DOS will run
out of environment space fairly soon.
I think the only fonts for which it really matters are those that (1)
follow the standard naming scheme (the adobe/monotype/etc. fonts), or
(2) are distributed in clear, separate packages (the ams fonts).
How about the name other/ (instead of misc/) for the reminaing fonts? I
certainly wouldn't want to call Computer Modern ``miscellanous'', yet
having separate family directories (knuth/, yannis/, ...?) for no clear
reason seems wrong to me.
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 05:36:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081035.MAA11077@spice.iti.informatik.th-darmstadt.de>
Subject: Re: PK specials for ps2pk
To: TWG-TDS@SHSU.edu
Date: Thu, 8 Sep 1994 12:35:46 +0200 (MESZ)
Content-Type: text
First, let me say that I like the enhancement to ps2pk and I think one
should add this additional option -m.
But -- I must add that putting the specials in the PKs is a
Quichotte's fight. Even distributions that are based on web2c come
often with fonts that don't have them. Don't ask me why they do not
simply use modes.mf, but obviously many people prefer to distribute
their own quirks. (To wit: The TeX distribution of Slackware Linux. I
just discarded it last weekend and built everything anew -- TDS
conform, of course... ;-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 06:14:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 8 SEP 94 12:12:17 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: PK specials for ps2pk
Message-ID: <202076E2_00325B80.0098429B540B75BE$19_6@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
[I know I'm no longer a member of this group, but since I still receive its
messages...]
Concerning [...DPInnn] or .../DPInnn or ...\DPInnn as a part of
the path to PK files:
I have always used directories of this form, but in re-implementing
TeX for Alpha/VMS I was forced to create aliases of the form [...nnn],
as one driver (I regret I forget which) couldn't cope with DPI as well.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 06:21:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 8 SEP 94 12:19:53 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: font families
Message-ID: <202076E2_003256F8.0098429C649C605E$19_9@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> In fact, I suspect DOS will run out of environment space fairly soon.
DOS doesn't run out of environment space: you simply give it more in
Config.Sys
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 07:56:55 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qij16-00007FC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 8 Sep 94 13:55 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: font families
>I'm not sure where we left the typeface family names discussion, but I
>thought of one small reason recently to minimize the number of family
>names -- if we're catering to deficient implementations that force users
>to use paths like $TEXMF/fonts/tfm/adobe:$TEXMF/fonts/tfm/other:..., the
>fewer families there are, the better.
Don't you mean <source>s here rather than <family>s. The number of
<family>s shouldn't make too much difference.
>How about the name other/ (instead of misc/) for the reminaing fonts? I
>certainly wouldn't want to call Computer Modern ``miscellanous'', yet
>having separate family directories (knuth/, yannis/, ...?) for no clear
>reason seems wrong to me.
While `other' accurately reflects my opinion of where the CM fonts fit
in this heirachy, I'm not sure everyone would agree :-)
BTW, does your example path `$TEXMF/fonts/tfm/adobe' indicate that
you've been won over to the cause of fonts/<type>/...? :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 10:13:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081512.RAA22828@spice.iti.informatik.th-darmstadt.de>
Subject: Texinfo documents
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 8 Sep 1994 17:12:45 +0200 (MESZ)
Content-Type: text
Is there any specified place for GNU Info documents in the TDS?
In texmf/doc/info/? texmf/doc/texinfo/? texmf/info?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 10:15:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081514.RAA13364@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TUG'94: changes to TDS...
To: TWG-TDS@SHSU.edu
Date: Thu, 8 Sep 1994 17:14:47 +0200 (MESZ)
Content-Type: text
Eons ago, Norm wrote:
>
> On 11 August 1994 at 12:24:57, K. Berry wrote:
>
> > I really think the TDS should specify the bibtex/bib and bibtex/bst
> > directories.
Btw, I agree.
> > If there are multiple types of makeindex (we should specify
> > a portable name for this one -- makeind?)
>
> makeindx ?
Yes, please; the DOS (& other impovered OS) version is called so.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 10:18:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081517.RAA13371@spice.iti.informatik.th-darmstadt.de>
Subject: Re: top-level directories
To: TWG-TDS@SHSU.edu
Date: Thu, 8 Sep 1994 17:17:41 +0200 (MESZ)
Content-Type: text
Karl once wrote:
>
> OK, so what goes in their respective directories? I use makeindex, but
> I don't know of any system-wide style files or other such stuff.
There are a lot. The most prominent ones are those that accompany
LaTeX's doc package.
The next major version of MakeIndex will use style files heavily; in
fact, one will use no style file only in very few circumstances.
(Markup transformation for sort key construction, sort orders, and
alphabets for different languages are defined in the style file
then.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 10:20:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409081519.RAA14150@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Here I go again...
To: TWG-TDS@SHSU.edu
Date: Thu, 8 Sep 1994 17:19:28 +0200 (MESZ)
Content-Type: text
The comments of Rich Morin under this subject are IMHO a good start
for a general introduction on the whole aim of TDS.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 08 Sep 1994 15:35:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 08 Sep 1994 15:35:03 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: kb@cs.umb.edu
Message-ID: <009842B7.A868AB60.88@SHSU.edu>
Subject: RE: PK specials for ps2pk
A side note to Pierre's post of Wed, 7 Sep 1994 16:45:58 -0700 -- a "for
what its' worth", if you will, as a result of some recent font creating
here.
> It would be easy to change the mode special to
> 'mode=CItohThreeOneZero(ps2pk)' or 'mode=citohtoz(ps2pk)'
As much as I hate to hamstring things, I found a problem with Karl's
modes.mf in that VMS didn't want to recognize, in my particular case:
mode=LNOthree;
(which translaes to his definition for ricohlp). I was determined to
figure this out on my own, but Phil was the proud recipient of a few
questions, which he was kind enough to help with as best he could -- gave
me the clue which finally opened the door (fair warning -- unlike quite a
few of you, I try and avoid font creation to the point of even having
problems spelling MF). Turned out that if I defined
mode_def lnothree
(or aliased it with the extra line
lnothree := ricohlp;
in modes.mf), everything worked fine.
My point here, as it is related to a few items on the font
placement/contents issue, is that in my (admittedly small sample) tests,
VMS appears to be case sensitive to the point that portability, if that's
what we're really after, suggests that a requirement of lowercase mode
specifications might be in order -- and certainly considered as add-ons for
a future version modes.mf. Maybe I'm just stupid on this (I'm stupid in
other areas as well; I'm just potentially adding this one), but it was most
certainly a non-trivial, non-obvious problem with a seemingly-trivial
solution.
Regards, George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu
Department of Economics and Business Analysis THEnet: SHSU::BED_GDG
College of Business Administration Voice: (409) 294-1266
Sam Houston State University FAX: (409) 294-3612
Huntsville, TX 77341-2118 USA
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:32:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 1994 06:32:39 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091032.AA12227@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo documents
The texinfo source should presumably go in doc/<package>/<package>.texi
or whatever.
If you distribute the generated info files, I guess that would be
doc/info/foo.info*. Unless you leave them in the doc directory
and let people install them.
Although info/ has many meanings, I can't think of any other reasonable
name. That is one directory name that is actually the same at
all the sites I know about.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:36:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 1994 06:36:23 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091036.AA12249@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: font families
Yes, I do mean <source>, not <family>. Sorry.
So, who doesn't agree with other/ for the <source> for non-fontname'd
fonts.
No, I am still dead-set against fonts/<type>; I just didn't want
to confuse the issues.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:39:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 1994 06:38:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091038.AA12300@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
(Oops, I think this never made it out.)
Thanks for the summary, Joachim. Now that I have something concrete to
criticize, I will :-)
base/ % reserved package name ????
I think this is right, so no ??? needed. The base/ directory is for the
minimal set of stuff put out by the package maintainer(s). I'm not sure
this actually applies to anything but latex.
misc/ % reserved package name
This is for one-file add-ons (using format <format>), as I recall.
<package>/ % in general
For multiple-file add-ons.
latex/ % allocated format name
distrib/
<package>/ % as above
contrib/
<package>/ % as above, without base/
Why should latex/ be any different than anything else? I would argue
just the opposite, that latex/ should be the prototypical <format>,
since it's the most common.
Thus, according to the current scheme, I would rename distrib/ to base/,
with no <package> underneath (what's that for?), and move everything in
<contrib>/ up to under latex/.
If the consensus is to make base/ (or distrib/, whatever) and contrib/
directories under texmf/<format>, so that all the contrib packages have
an extra level on them, then I think that should apply to all formats,
not just latex. I personally don't see the need for the extra level.
hyphen/ % reserved format name
<language>/
generic/ % reserved format name:
% INITeX processable files
% e.g., fontinst
Actually, I don't like generic/. I would rename it to initex/ or
none/, IMO it makes clearer what's in this directory.
I agree with you. Here is my proposal:
1) Declare that generic/ is for files that can be processed by more than
one variant of TeX -- plain + latex, plain + amstex, latex + amstex (if
there are any), etc. I think there are relatively few of these files,
(null.tex, btxmac.tex, paths.sty, texnames.sty, ...?) and there's no
need to have a directory for each of the combinations.
This is essentially your plaincodes/, I think. I don't see that
catcodes in particular matter; they're just the primary aspect of what
``processable by format XXX'' means.
This directory would be in the search path for all formats.
2) If there are non-hyphen files that can be processed by initex, then
rename to hyphen/ to initex, and put both the hyphenation stuff and
these other files there. If there are no such files, then leave hyphen/
as the name.
I personally don't know of any such files. I can't imagine why fontinst
should be initex-processable.
Or are we talking about plain.tex, lplain.tex (named something else in
2e, I know), etc.? I think those belong in <format>/base. In fact, I
think they are the archetypal contents of <format>/base.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:42:07 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091041.MAA21918@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Texinfo documents
To: TWG-TDS@SHSU.edu
Date: Fri, 9 Sep 1994 12:41:19 +0200 (MESZ)
Content-Type: text
You wrote:
>
> The texinfo source should presumably go in doc/<package>/<package>.texi
> or whatever.
>
> If you distribute the generated info files, I guess that would be
> doc/info/foo.info*. Unless you leave them in the doc directory
> and let people install them.
No, put them in doc/info/, that can be appended to $INFOPATH. Norm, do
you add this to the TDS document?
> Although info/ has many meanings, I can't think of any other reasonable
> name. That is one directory name that is actually the same at
> all the sites I know about.
Then let me tell you the first... info/ is used by IBM's InfoExplorer,
and in this @#$$# software one cannot configure that name. :-( So we
changed the GNU Info name. Not that I would recommend that for any
other installation.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:50:15 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj3WJ-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 11:49 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: font families
>So, who doesn't agree with other/ for the <source> for non-fontname'd
>fonts.
Well I still marginally prefer misc/ to other/, but I don't care very
much, as long as we're consistent, eg tex/latex/other etc. And I
still reckon that DEK-and-derivatives-of-some-sort-or-another should
be a <source>, anything else is just rude.
I think that what would be nicest for the punters is a <source> called
something like `standard' which consists of the fonts you have to have
if you want to run LaTeX. That way when we get asked `where do I get
the fonts for LaTeX from' we can say `get them from fonts/standard on
CTAN' rather than `get fonts/other/cm, fonts/other/dekmisc and
fonts/ams/cmextra'. But trying to find a name for `standard' (not to
mention agreeing on its contents) might be tricky...
>No, I am still dead-set against fonts/<type>; I just didn't want
>to confuse the issues.
Rats. :-) I just find it odd that we're switching between worrying
about current implementation restrictions to cut down on the number of
<source>s, but we're not worrying about the fact that fonts/<source>/
just can't be implemented on some platforms at the moment.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 05:57:04 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj3ct-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 11:56 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
>Thus, according to the current scheme, I would rename distrib/ to base/,
>with no <package> underneath (what's that for?), and move everything in
><contrib>/ up to under latex/.
There's a lot more than just base under distrib... there's tools,
psnfss, babel, etc. The distinction is between stuff maintained by us
(ie stuff you should send *us* bug reports on) and contributed stuff.
I think that this distinction is useful at CTAN, but I think I could
live without it being in the TDS. David may disagree with me. He
usually does. And he's usually right :-)
>2) If there are non-hyphen files that can be processed by initex, then
>rename to hyphen/ to initex, and put both the hyphenation stuff and
>these other files there. If there are no such files, then leave hyphen/
>as the name.
I'd do it the other way round---if the only initex-processable files
are hyphenation patterns, then keep the directory called hyphen and
ditch initex.
>I can't imagine why fontinst should be initex-processable.
Because at the moment a lot of TeX's memory is wasted on macros to do
with typesetting, which fontisnt doesn't do a lot of :-) Making
fontinst processable with iniTeX or virTeX would save a lot of memory.
>Or are we talking about plain.tex, lplain.tex (named something else in
>2e, I know), etc.? I think those belong in <format>/base. In fact, I
>think they are the archetypal contents of <format>/base.
Agreed. latex.ltx should live in latex/base. Should the .dtx files
(the documented source code) live in tex/latex/base or doc/latex/base?
Or even src/latex/base? :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:11:08 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091110.NAA23119@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Fri, 9 Sep 1994 13:10:57 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> latex/ % allocated format name
> distrib/
> <package>/ % as above
> contrib/
> <package>/ % as above, without base/
>
> Why should latex/ be any different than anything else?
Because it's creators want so. Seriously, Alan or David will react, so
I don't need to rehash the arguments. My position: I don't care and go
with the stuff that leads to the smallest discussion. I don't go with
the arguments of the LaTeX team because I don't believe that users
will ever grasp this difference. In a good installation they will
never ever look at this directory structure. But if it makes the LaTeX
team happy, I'll go for it. :-) :-)
> 1) Declare that generic/ is for files that can be processed by more than
> one variant of TeX -- plain + latex, plain + amstex, latex + amstex (if
> there are any), etc. I think there are relatively few of these files,
> (null.tex, btxmac.tex, paths.sty, texnames.sty, ...?) and there's no
> need to have a directory for each of the combinations.
>
> This is essentially your plaincodes/, I think.
> This directory would be in the search path for all formats.
Yes. The second voice for this proposal. Put on the table. Any vetos? None?
Norm -- put it in the document. :-) :-) :-)
> 2) If there are non-hyphen files that can be processed by initex, then
> rename to hyphen/ to initex, and put both the hyphenation stuff and
> these other files there. If there are no such files, then leave hyphen/
> as the name.
Another vote for hyphen. Settled?
> Or are we talking about plain.tex, lplain.tex (named something else in
> 2e, I know), etc.? I think those belong in <format>/base.
Yes.
> In fact, I think they are the archetypal contents of <format>/base.
No, e.g., latex//base/ contains all `standard' style files.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:15:24 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj3ub-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 12:14 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
>> 2) If there are non-hyphen files that can be processed by initex, then
>> rename to hyphen/ to initex, and put both the hyphenation stuff and
>> these other files there. If there are no such files, then leave hyphen/
>> as the name.
>Another vote for hyphen. Settled?
Oooops... Joachim actually read what Karl wrote correctly :-) We're
all busy agreeing with each other and I didn't notice :-)
The only thing I would disagree with is that even if there are other
initex files kicking around, then I'd rather see those separated from
the hyphenation patterns. It makes it easier for format-building
files like latex.ltx to read hyphen files but not other
initex-processable files.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:17:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091117.NAA16605@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Fri, 9 Sep 1994 13:17:17 +0200 (MESZ)
Content-Type: text
Alan wrote [just arrived while I was writing my followup]:
>
> >2) If there are non-hyphen files that can be processed by initex, then
> >rename to hyphen/ to initex, and put both the hyphenation stuff and
> >these other files there. If there are no such files, then leave hyphen/
> >as the name.
>
> I'd do it the other way round---if the only initex-processable files
> are hyphenation patterns, then keep the directory called hyphen and
> ditch initex.
???? ``The other way round'' -- that's the same opinion, n'est pas?
The third vote. Settled if no vetos. Norm?
> latex.ltx should live in latex/base.
Please document that in the installation instructions in the next
LaTeX2e distribution. Currently these files are not installed. I.e.,
please add the equivalent to `cp *.ltx $TEXMF/latex/distrib/base' to
install.txt.
> Should the .dtx files
> (the documented source code) live in tex/latex/base or doc/latex/base?
> Or even src/latex/base? :-)
Yes, IMO that's the correct place for it. That's simple, it's the
place where I put them, so it must be the correct place. :-) :-) But
the TDS should not tell anything about source trees, that would open a
Pandora's box -- we'll never finish then.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:22:26 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj41R-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 12:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
>> latex.ltx should live in latex/base.
>Please document that in the installation instructions in the next
>LaTeX2e distribution. Currently these files are not installed. I.e.,
>please add the equivalent to `cp *.ltx $TEXMF/latex/distrib/base' to
>install.txt.
Yes, I expect a lot of the *.txt instructions will have to be
rewritten once TDS arrives.
>Yes, IMO that's the correct place for it. That's simple, it's the
>place where I put them, so it must be the correct place. :-) :-)
Heavens, people might read them if you put them in a doc directory :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:27:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 94 12:27:28 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409091127.AA02433@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
As Alan invited me to disagree...
Karl said:
> Why should latex/ be any different than anything else? I would argue
> just the opposite, that latex/ should be the prototypical <format>,
> since it's the most common.
It's simply that unlike the `base' plain TeX distribution which is
essentially just plain.tex, the `base' LaTeX distribution contains
many files that have a directory structure of their own, with
directories for
`base' (ie so really basic it's described in Lamport's book:-)
`babel' (multi-lingual stuff)
`tools' (the old Mainz packages, mainly)
etc.
As one of these directories is currently called base, the suggestion
was to call the top level distrib, and have
1)
latex
distrib
base
tools
babel
...
contrib
misc
seminar
...
The TeX inputs tree isnt as deep as the font tree so we can afford
that extra level so I dont really see any objection. The alternatives
are
2)
latex
base
<new name for what is currently in base>
tools
babel
...
misc (for one-file things)
seminar
...
ie just as for the other formats except with a `base' tree with its
own internal structure.
or
3)
latex
base (current base stuff)
tools
babel
misc
seminar
....
ie make tools graphics babel etc have the same status as contributed
files.
Of the three I dont really have any strong feelings about whether to
use the first or second, but I have already sent too many messages
explaining why I do not like the last alternative at all.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:39:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 94 12:39:02 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409091139.AA02439@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
A> > latex.ltx should live in latex/base.
J> Please document that in the installation instructions in the next
J> LaTeX2e distribution. Currently these files are not installed. I.e.,
J> please add the equivalent to `cp *.ltx $TEXMF/latex/distrib/base' to
J> install.txt.
Er, I think the installation instructions are correct (Alan?). *.ltx
are not needed for processing documents, so can be discarded or just
keep with the source tree (keeping them speeds up installing a patch
release)
I agree with Joachim, that dtx files and other source files are not
really within the scope of the TDS to specify (although many sites may
choose to put sources somewhere below /texmf/)
David
PS
About the latex/distrib/contrib issue, this is a small point that
really isnt worth arguing over too much as if all else fails I'll back
down so we can get this thing done. However we *must* make a final
decision on the font tree soon as that seems to be the main major thing
that is threatening to hold up this report ever being finalised.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:41:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091141.NAA18377@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Fri, 9 Sep 1994 13:41:45 +0200 (MESZ)
Content-Type: text
I wrote:
>
> Alan wrote [just arrived while I was writing my followup]:
> >
> > >2) If there are non-hyphen files that can be processed by initex, then
> > >rename to hyphen/ to initex, and put both the hyphenation stuff and
> > >these other files there. If there are no such files, then leave hyphen/
> > >as the name.
> >
> > I'd do it the other way round---if the only initex-processable files
> > are hyphenation patterns, then keep the directory called hyphen and
> > ditch initex.
>
> ???? ``The other way round'' -- that's the same opinion, n'est pas?
> The third vote. Settled if no vetos. Norm?
Hmpf, I shouldn't send as quick in the mood I am. (Yesterday some
<censored> added a machine as 127.0.0.1 to our LAN. I had to diagnose
and to fix it...) Back to the topic:
In my list I mentioned
hyphen/
<language>/
Is that so or do we drop that language directory?
CTAN currently keeps all files in one directory, named hyphenation.
There are rarely more than one file for a language, so we'll end up
with lots of directories with only one file.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 06:45:04 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409091144.NAA21777@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tex input directories
To: TWG-TDS@SHSU.edu
Date: Fri, 9 Sep 1994 13:44:49 +0200 (MESZ)
Content-Type: text
David wrote:
>
> A> > latex.ltx should live in latex/base.
>
> Er, I think the installation instructions are correct (Alan?). *.ltx
> are not needed for processing documents, so can be discarded
I would love to have them at a defined place in the TDS. One needs
them to create new format files. (E.g., when one decides that one
needs yet another language support.) Then one can ease the description
how to create FMT files -- all needed files are in the TDS, users
don't need to search the source (dtx) files.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 07:04:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 Sep 94 13:04:26 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409091204.AA02461@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
> I would love to have them at a defined place in the TDS. One needs
> them to create new format files. (E.g., when one decides that one
> needs yet another language support.) Then one can ease the description
> how to create FMT files -- all needed files are in the TDS, users
> don't need to search the source (dtx) files.
Sounds reasonable, but we seem to be drifting off subject again, if
latex.ltx is being kept around, it should go in the analogous place to
plain.tex, which is presumably latex/<path-to-be-decided>/base.
But this seems to be a matter of writing the latex documentation
rather than a matter for this group.
I suppose my previous viewpoint may be connected with the fact that I
never ``decides that one needs yet another language support.''
All the formats at Manchester only have US hyphenation:-)
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 07:17:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 SEP 94 13:15:32 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: PK specials for ps2pk
Message-ID: <2020850C_000E75B8.0098436D54A38E9E$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> My point here, as it is related to a few items on the font
>> placement/contents issue, is that in my (admittedly small sample) tests,
>> VMS appears to be case sensitive to the point that portability, if that's
>> what we're really after, suggests that a requirement of lowercase mode
>> specifications might be in order -- and certainly considered as add-ons for
>> a future version modes.mf. Maybe I'm just stupid on this (I'm stupid in
>> other areas as well; I'm just potentially adding this one), but it was most
>> certainly a non-trivial, non-obvious problem with a seemingly-trivial
>> solution.
You just have a defective MetaFont, George: a decent version preserves
the case of all text passed. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 07:18:51 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj4ty-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 13:17 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
>> Er, I think the installation instructions are correct (Alan?). *.ltx
>> are not needed for processing documents, so can be discarded
The reason for keeping the *.ltx files is so that you can easily
install the new patch levels on the highly unlikely occurrence that a
bug is discovered. It's probably easier to just bung them in with
latex/base rather than have a whole new directory for such things.
>I would love to have them at a defined place in the TDS. One needs
>them to create new format files.
Better in latex/.../base than initex/.../latex I'd say.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 07:21:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qj4wS-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 9 Sep 94 13:20 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
>CTAN currently keeps all files in one directory, named hyphenation.
>There are rarely more than one file for a language, so we'll end up
>with lots of directories with only one file.
I'd prefer the <language> level, just so that the punters get british/
american/ deutch/ etc. when they ls $texmf/hyphen, rather than
ukhyph.tex, dehyph1.tex etc. And it fits better with the
<format>/<package>/<file> heirachy. But this is splitting hairs
somewhat...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 08:01:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 09 Sep 1994 08:01:23 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00984341.725AACA0.4@SHSU.edu>
Subject: RE: PK specials for ps2pk
On Fri, 9 SEP 94 13:15:32 BST, Phil Taylor <CHAA006@VAX.RHBNC.AC.UK>
posted:
> You just have a defective MetaFont, George: a decent version preserves the
> case of all text passed. ** Phil.
Guess I wasn't clear on this -- the mode=lnothree; which I finally used was
a command-line option and not embedded within anything. Even the standard
VMS trick of double quoting failed, which I found very odd. The problem is
(unless you know how to pass it so it remains cased; in which case, we need
some very clear and concise VMS-specific documentation in systems/vms about
it which can probably be published in a number of places) that if you write
a generic DCL command file (shell script) to make a set of fonts at various
magsteps, you almost *have* to pass this information as a command-line
option. Unless you do a little tweaking to some of the distributed source
files (which I abhor), I don't see how to avoid this.
I replicated this, BTW, with the latest MF-for-Alpha-VMS yesterday thinking
maybe it was a buggy MF on my older VAX/VMS implementation.
MF is obscure enough to most users (absolutely essential, admittedly; yet
absolutely obscure realistically) that anything which can be done to
simplify it so it becomes more usable without a bunch of special cases is
worth the effort (as is the case with TeX and other friends, IMO). Asking
that modes.mf merely add a few more aliases is all it appears to me to be
necessary to do this and I think Karl might be willing to support this
(maybe not, but I think so).
--George
================================================================================
From owner-twg-tds@shsu.edu Fri, 09 Sep 1994 08:13:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 9 SEP 94 14:11:20 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: RE: PK specials for ps2pk
Message-ID: <2020850C_003547C0.00984375208C50DE$19_6@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> > You just have a defective MetaFont, George: a decent version preserves the
>> > case of all text passed. ** Phil.
>> Guess I wasn't clear on this -- the mode=lnothree; which I finally used was
>> a command-line option and not embedded within anything. Even the standard
>> VMS trick of double quoting failed, which I found very odd.
No, you were very clear! I have seen the problem in ancient TeX's:
they str$lowercase everything, forgetting that case can be preserved
if the CLD file defines the parameter as a quoted string.
>> The problem is
>> (unless you know how to pass it so it remains cased; in which case, we need
>> some very clear and concise VMS-specific documentation in systems/vms about
>> it which can probably be published in a number of places) that if you write
>> a generic DCL command file (shell script) to make a set of fonts at various
>> magsteps, you almost *have* to pass this information as a command-line
>> option. Unless you do a little tweaking to some of the distributed source
>> files (which I abhor), I don't see how to avoid this.
I do use MetaFont all the time, and I do use mixed-case modes: there
really _isn't_ a problem so long as your MetaFont isn't brain-damaged.
>> I replicated this, BTW, with the latest MF-for-Alpha-VMS yesterday thinking
>> maybe it was a buggy MF on my older VAX/VMS implementation.
Well, perhaps Christian is still str$lowercasing things; my version is
from BHK, and I pointed out the sillyness of str$lowercasing things years
ago, so he hasn't fallen into that trap since.
>> MF is obscure enough to most users (absolutely essential, admittedly; yet
>> absolutely obscure realistically) that anything which can be done to
>> simplify it so it becomes more usable without a bunch of special cases is
>> worth the effort (as is the case with TeX and other friends, IMO). Asking
>> that modes.mf merely add a few more aliases is all it appears to me to be
>> necessary to do this and I think Karl might be willing to support this
>> (maybe not, but I think so).
Two points: (1) I think it important that VMS be not seen as brain-dead;
and (2): modes.mf is already far too big for many MetaFonts to use at all.
Rather than make it even bigger, we need to liaise with Christian Spieler,
who from my e-mail correspondence seems an eminently approachable implementor,
and ask him to remove the str$lowercase if he's using it. If he's not,
then I'm afraid it's down to your d@mned command procedures, George (`shell
scripts' indeed!). ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 06:44:19 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qk9n6-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 12 Sep 94 12:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Summary of case for fonts/<type>/
Okay, like David said, I think we need to get the fonts directory
structure sorted out.
So... as a `summary for the prosecution' I'll try to explain why I much
prefer fonts/<type>/ over fonts/<source>/.
Basically I'm worried about the uptake of TDS. If we go for
fonts/<type>/, then most TeX platforms will be able to support TDS
immediately. This means that (once TDS has been tested fully), package
writers can assume TDS conformance.
For example, the *.txt installation files that come with LaTeX would be
able to assume a TDS conformant system, and rather than waffle like (from
install.txt):
These may be kept in a TeX inputs directory or folder, which is
usually called something like...
we would be able to write something like `now move any file called *.dtx
to texmf/doc/latex/base, and every other file to texmf/tex/latex/base'.
Much better for all concerned.
If we go for fonts/<source>/ then TDS uptake will be much slower. If I
were optimistic, I'd guess it would put back the day when we (the L3 team)
could assume TDS conformance by a year. If I were pessimistic, I'd guess
we may never be able to use TDS (LaTeX has to run on just about anything
that can run TeX, including obsolete TeX platforms).
I'd like to be able to use TDS, and I'd like the LaTeX documentation to
encourage sites to move over to TDS. With fonts/<type>/ this should be
possible by the end of the year. With fonts/<source>/ I don't know if or
when this will be possible.
That's about it. Perhaps someone should produce a short summary of the
case for fonts/<source>/ and then Norm can work out some way to get a
decision salvaged out of all this :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 08:07:36 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Mon, 12 Sep 1994 14:06:48 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:273200:940912130713"@cl.cam.ac.uk>
Alan's case only holds water if you think that all TeX systems
can/will support fonts/type within a few moinths. it seems to me that
there is no more evidence for this than that they
they will support fonts/package or whatever.
many many TeX `products' cant support any form of TDS at all, so they
might as well go the whole hog or nothing. strikes me Alan's case
rests on the always maverick OzTeX...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 08:34:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 12 Sep 94 14:20:48 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409121320.AA04471@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Sebastian says:
> strikes me Alan's case rests on the always maverick OzTeX...
It is not just Oztex, a fonts/source tree forces searching over
the whole pk tree for tfm files. Despite arguments that an ls-R file
setup makes this feasable, only web2c currently has such a file, and
even with that, and the fonts//tfm notation, it still in principle
is impossible to prune the search to just tfm directories with such a
directory structure. I think we are going to have a hard job
convincing anyone that this amount of extra searching has any
benefits. Insisting on this could easily wreck the whole project.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 08:36:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 12 Sep 1994 09:33:36 -0400
Message-ID: <199409121333.JAA29909@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Sorry, folks...
Reply-To: TWG-TDS@SHSU.edu
Just a quick note of apology. I was out of town (again) last week.
I'm back now and plan to assimilate all the messages on the list today
or tomorrow.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 09:01:20 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Mon, 12 Sep 1994 15:00:05 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:296550:940912140016"@cl.cam.ac.uk>
I dont buy David's argument either. Karl, who writes subdir searching
code, Joachim, who Knows Things, and Tom R who Is God, all say that
the `search tree pruning' is easy to implement and not
inefficient. No-one says that the thing should scan the PK files, but
bypassing this is (They say) quite easy. cant we trustthem?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 09:14:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 12 Sep 94 15:13:30 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409121413.AA04515@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
>>>>> "Sebastian" == Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk> writes:
Sebastian> I dont buy David's argument either. Karl, who writes subdir
Sebastian> searching code, Joachim, who Knows Things, and Tom R who Is
Sebastian> God, all say that the `search tree pruning' is easy to
Sebastian> implement and not inefficient. No-one says that the thing
Sebastian> should scan the PK files, but bypassing this is (They say)
Sebastian> quite easy. cant we trustthem?
No, never trust anyone:-)
I can well believe that pruning a search tree is easy, but it is not
possible to prune the search tree to just tfm files with the proposed
setup. TEXFONTS=texmf/fonts//tfm does not prune the search space at
all, in principle you have to search the whole tree looking for any
directory called tfm.
Now it may well be that given ls-R, texmf/fonts/tfm// is no more
efficient, as the system probably greps for cmr10.tfm over the whole
file in both cases, but that is an implementation issue that I do not
want to know about. I do not see how we can put forward a system that
makes it impossible to specify that TeX only searches tfm files to
find a tfm file.
> No-one says that the thing should scan the PK files,
Apart from web2c that is exactly what we are saying should happen
so even if you `trust them' are you saying that sites should not
implement the TDS until they have a TeX that can support it without
this searching over PK's? As Alan said, in practice this will put TDS
back years, maybe for ever.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 12 Sep 1994 17:42:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 12 Sep 1994 12:54:30 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409121654.AA28793@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: the same old arguments for the twenty millionth time
I am trying to understand the argument for fonts/type, and I just can't
do it. Alan and David, you've raised your objections before (several
times), and I've answered them before (several times). Did you read my
replies? I hope they made them out. I'll recapitulate them again.
Your argument: fonts/source is too inefficient.
My response: ever searching the disk, even only TFM directories, is too
inefficient for a practical number of directories.
Commentary: A ``practical number'' of directories are the basic cm
etc. fonts + the dvips fonts + perhaps the dvilj fonts.
Alan's oztex experiments are consistent with this. He found:
OzTeX as shipped: 4sec
with fonts/type: 8sec
and he had only around 20 directories. If there were another 15-20
directories, the search time even with fonts/type would, I suspect,
become too slow. Even doubling the search time will be too slow for
some people.
Conclusion: Implementors will have to do *something* to make searches
faster if we adopt *any* kind of subdirectory hierarchy. So the TDS
will *not* work on ``most TeX platforms'' now.
So if that's the goal, I think we must abandon subdirectory
searching, both for TeX macros and fonts. And if we do that, I see a
little point in a TDS at all. And I don't think any of us wants that.
I gave more detailed numbers in my earlier message (which I can't find
just now).
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 04:04:30 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Tue, 13 Sep 1994 09:11:01 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:023550:940913081118"@cl.cam.ac.uk>
i still dont think David has taken in the points of Karl and
Joachim. They say that foo//tfm can be programmed to *not* search
foo/pk with not much difficulty. but they should comment, not me
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 04:06:23 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 12 Sep 1994 17:18:29 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409130018.RAA12606@june.cs.washington.edu>
To: rcpt@urc.tue.nl
CC: TWG-TDS@shsu.edu, unixtex@u.washington.edu
Subject: revised patches for ps2pk14
The collection of patches ps2pkdiff-v2.tar.gz adds
the -m flag, and corrects some minor glitches.
It is a replacement for the patches in the
previous message, not an add-on.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 10:54:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qkX46-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 13 Sep 94 13:34 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: the same old arguments for the twenty millionth time
>Alan and David, you've raised your objections before (several
>times), and I've answered them before (several times).
Yes, I think we've gone through the arguments enough times. We just
need a decision.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 10:55:29 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
Date: Tue, 13 Sep 1994 16:06:44 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:131730:940913150656"@cl.cam.ac.uk>
I dont think my last message went to everyone, just to BNB. anyway
what i said was "lets issue a draft TDS with the Right Scheme
(family//tfm) and then see if the implementors moan". give them a
chance to react as Alan and David say they will. otherwsie we are
prejudging their abilities. I maintain that *all* of them except Karl
will have to do some wokr
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 10:58:35 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9409131143.AA00566@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Tue, 13 Sep 94 07:42:10 -0400
From: bob@microprograms.com
I haven't contributed a lot to this discussion of late, but I have been
following it. Thank you, David and Alan, for taking my concerns about
the font organization.
I share your concerns. Since the stated purpose of the TDS (by members
of this committee) is to benefit the system administrator, not the
user, it is going to be very hard to convince a large body of 'x86
computer users (i.e. MSDOS hackers) to spend a lot of work to fix
something that in their minds is not broke.
Dealing with these people every day, I am convinced that I will have to
modify all my programs to implement the TDS in a transparent way. Most
users don't know from config.sys files, autoexec.bat files, environment space, etc.
Bob Harris
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 10:59:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Sep 94 10:46:55 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409130946.AA05058@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
>>>>> "Sebastian" == Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk> writes:
Sebastian> i still dont think David has taken in the points of Karl
Sebastian> and Joachim. They say that foo//tfm can be programmed to
Sebastian> *not* search foo/pk with not much difficulty. but they
Sebastian> should comment, not me
No, it can not be so programmed. This is not an implementation
question. foo//tfm *has* to search under foo/pk as the tree may look
like
foo
xxx
tfm
cmr10.tfm
xxx
pk
tfm
cmr11.tfm
Now this is a stupid directory layout, but search strategies do not
work by common sense. A specification of foo//tfm, given the above
tree *must* find cmr11. That is the specification of the search path.
If you *specify* that the whole tree must be searched, no amount of
smart programming will get round that.
By `search under pk' I mean search in the conceptual tree, whether or
not it searches the actual disk or some cached more efficient
representation is another matter entirely.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:00:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Sep 1994 06:14:41 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409131014.AA13360@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
CC: s.rahtz@elsevier.co.uk
I did comment. Is my mail not making it through?
Here's what I sent -- if you don't see it on the list,
could you repost it?
To: twg-tds@shsu.edu
Subject: the same old arguments for the twenty millionth time
I am trying to understand the argument for fonts/type, and I just can't
do it. Alan and David, you've raised your objections before (several
times), and I've answered them before (several times). Did you read my
replies? I hope they made them out. I'll recapitulate them again.
Your argument: fonts/source is too inefficient.
My response: ever searching the disk, even only TFM directories, is too
inefficient for a practical number of directories.
Commentary: A ``practical number'' of directories are the basic cm
etc. fonts + the dvips fonts + perhaps the dvilj fonts.
Alan's oztex experiments are consistent with this. He found:
OzTeX as shipped: 4sec
with fonts/type: 8sec
and he had only around 20 directories. If there were another 15-20
directories, the search time even with fonts/type would, I suspect,
become too slow. Even doubling the search time will be too slow for
some people.
Conclusion: Implementors will have to do *something* to make searches
faster if we adopt *any* kind of subdirectory hierarchy. So the TDS
will *not* work on ``most TeX platforms'' now.
I gave more detailed numbers in my earlier message (which I can't find
just now).
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:01:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409131027.MAA19543@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Summary of case for fonts/<type>/
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Sep 1994 12:27:42 +0200 (MESZ)
Content-Type: text
sebastian wrote:
>
> i still dont think David has taken in the points of Karl and
> Joachim. They say that foo//tfm can be programmed to *not* search
> foo/pk with not much difficulty. but they should comment, not me
???? Karl has answered it. To get decent answering times for any
scheme one must implement a cache. I.e., the result of a directory
tree traversal must be stored somewhere for fast lookup.
This cache can be simple (like ls-lR in the web2c implementation) or
it can be more complex, providing inverted indices for directories.
This cache can be computed off-line by another program (like ls in
the web2c implementation) or it can be produced by the respective
library when some directory timestamp changes. This is all a matter of
implementation. The case is that this implementation must be done for
*any* scheme, be it fonts/<type>/ or fonts/<source>/. One must not
traverse directory trees all the time.
Perhaps the conception problem is that we talked at some point about
a Unix method to traverse a hollow file tree faster. That's not of
interest for the TDS discussion, since it's not portable to other
OSes.
As Karl wrote: If you really think about searching the disk all the
time you're running TeX or a driver, you should drop the whole TDS
structure in the fonts subtree. Then you have to use
fonts/<device>/dpi<number>/<font>.<type> and fonts/tfm/<font>.tfm
without any occurence of <source>. But don't expect this to be really
fast either, the search through large directories is pathological
slow on many systems.
If that is the case, an appendix ``TDS font structure on a
non-brain-dead OS^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HUnix'' is
needed... :-) :-) :-) :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:01:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Sep 94 10:34:23 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409130934.AA05049@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: the same old arguments for the twenty millionth time
> Conclusion: Implementors will have to do *something* to make searches
> faster if we adopt *any* kind of subdirectory hierarchy. So the TDS
> will *not* work on ``most TeX platforms'' now.
Karl,
Yes, we did get your earlier arguments putting this position but I
still have two basic objections to it.
Let me rephrase my objections.
1) I dont want to recommend a directory structure that makes it
impossible to *specify* that TeX only searches tfm directories.
Efficiency is not the issue here. With fonts/type you would need
some mechanism for saying do not search below pk/ or /vf etc.
and I can not imagine any good syntax for that.
TEXFONTS=texmf/fonts//tfm
does not prune the search as the `tfm' directory could be in any
part of the tree below fonts (as far as TeX knows, even if it is
unlikely to be under pk).
I want this to make it explainable to *humans* what TEXFONTS etc
are all about. It may be that implementing searching via ls-R
means that essentially the whole tree is `searched' anyway, but that
is not the point, tfm files are conceptually very different from pk
files or vf files or ... implementations have always had
separate search paths for different kinds of files, and I dont see
why we should loose this now.
Some may think point (1) rather academic if in fact implementation
issues mean that the apparent search over the whole tree
texmf/fonts//tf is just as fast as the search over a subtree
texmf/fonts/tf//, but there is nothing wrong with being an academic:-)
However here is a more pragmatic objection (which is Alan's objection,
he probably wouldnt have argued (1) above)
2) fonts/source will require a change to most TeX implementations.
This will mean that at the most optimistic estimate it will be mid
1995 before TeX implementations have the necessary features.
This would mean 1996/7 before there was any reasonable body of
sites running such a TeX. Until the majority of TeX sites have/
could have such an implementation, no package will be able to
assume a TDS layout in its installation scripts or documentation.
Thus we lose the main aim of the TDS.
With fonts/type all sites would have to do to implement TDS
would be move a few files, and change a few paths. This would mean
that we could re-write the LaTeX installation instructions assuming
a TDS layout *now* to come out with the next full release in
December 1994.
Karl says that sites that have more than the standard cm fonts will
need a ls-R type implementation to run even with fonts/type. If he
says so, I believe him, but sites who are picking up such fonts will
probably pick up the latest TeX implementations too, so they will
have such a thing.
So to summarise I think that fonts/type gains you at least two years
on takeup of TDS, your argument appears mainly to be the technical one
that fonts/type is no more efficient than fonts/source. Perhaps so,
but what do you *gain* with fonts/source?
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:07:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409131607.SAA18288@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Summary of case for fonts/<type>/
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Sep 1994 18:07:34 +0200 (MESZ)
Content-Type: text
David wrote:
>
> By `search under pk' I mean search in the conceptual tree, whether or
> not it searches the actual disk or some cached more efficient
> representation is another matter entirely.
No, that's exactly the matter. Inverted caches allow to look *only* at
the contents of tfm directories and none else. This is the reason why
it's so important that no patterns are used in the search path; one
could not create an inverted index then. That's the difference between
pattern matching and search tree pruning. (cf. Horowitz & Sahni or any
other good algorithm & data-structure book)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:15:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409131614.SAA23681@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Summary of case for fonts/<type>/
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Sep 1994 18:14:51 +0200 (MESZ)
Content-Type: text
You wrote:
>
> I haven't contributed a lot to this discussion of late, but I have been
> following it. Thank you, David and Alan, for taking my concerns about
> the font organization.
>
> I share your concerns. Since the stated purpose of the TDS (by members
> of this committee) is to benefit the system administrator, not the
> user, it is going to be very hard to convince a large body of 'x86
> computer users (i.e. MSDOS hackers) to spend a lot of work to fix
> something that in their minds is not broke.
>
> Dealing with these people every day, I am convinced that I will have to
> modify all my programs to implement the TDS in a transparent way. Most
> users don't know from config.sys files, autoexec.bat files, environment
> space, etc.
I don't understand you. Do you want to drop the whole TDS proposal? Or
do you expect to implement it?
Again: You cannot implement fonts/<type>/<source>/* without a cache
*and* get decent response. In particular, not on DOS. Proved by
experience. Period.
NOTE: If an agreement is taken to use the fonts/<type>/ scheme, I
will be strongly against including <source> anywhere. In fact, then I
will be against the whole subdirectory searching in the complete TDS;
with *exactly* the same arguments as Alan & David are telling
currently. 0.5 :-) They assume an implementation without a cache
and such an implementation will *always* be too slow.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:32:31 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409131632.SAA19372@spice.iti.informatik.th-darmstadt.de>
Subject: Re: the same old arguments for the twenty millionth time
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Sep 1994 18:32:07 +0200 (MESZ)
Content-Type: text
David wrote:
>
> 1) I dont want to recommend a directory structure that makes it
> impossible to *specify* that TeX only searches tfm directories.
> Efficiency is not the issue here. With fonts/type you would need
> some mechanism for saying do not search below pk/ or /vf etc.
I don't understand this sentence.
> and I can not imagine any good syntax for that.
> TEXFONTS=texmf/fonts//tfm
Hmm, IMO this is the specification you ask above.
> does not prune the search as the `tfm' directory could be in any
> part of the tree below fonts (as far as TeX knows, even if it is
> unlikely to be under pk).
Yes, and? That doesn't influence that one does not search in the
intermediate directories. (Perhaps it's better if you start to look
at a filesystem as a general graph instead of a tree.)
> I want this to make it explainable to *humans* what TEXFONTS etc
> are all about.
The above means ``search through all directories named tfm that are
somewhere below texmf/fonts''. What's wrong with this explanation?
> 2) fonts/source will require a change to most TeX implementations.
As will fonts/type.
> With fonts/type all sites would have to do to implement TDS
> would be move a few files, and change a few paths.
I tried this (on an old Atari installation that does not support
directory tree searching) and did not succeed. How do I do this? Note:
I did not accept that I have to change paths every time I install a
new LaTeX bundle, or fonts from a new source. They have to be current
automatically.
> Karl says that sites that have more than the standard cm fonts will
> need a ls-R type implementation to run even with fonts/type. If he
> says so, I believe him, but sites who are picking up such fonts will
> probably pick up the latest TeX implementations too, so they will
> have such a thing.
???? Currently they don't do, with the exception of web2c. (emTeX's
searching is not efficient enough.) But PostScript fonts are used on
_many_ sites. Do I miss something?
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 11:36:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Sep 94 17:36:13 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409131636.AA05273@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Joachim> No, that's exactly the matter. Inverted caches allow to look
Joachim> *only* at
Ah! So now I understand your point. However I am still rather worried
that the proposed scheme requires such a sophisticated method
(OK by the standards of search algorithms its pretty simple), but what
you are saying, in layman's language is: It doesnt matter how
convoluted the actual file tree is, because we can organise the cache
in a completely different way, but this begs the question, if bringing
out the tfm layer is such a good idea in the cache, why not organise
the file system the same way?
So I would consider that you have answered my concern (1) if you could
tell me why, apart from being no less efficient, you want fonts/source
ie what do you gain?
However point (2) is the real killer, If we publish TDS in a document
that explains that before organising files in a tree of this form, you
must install TeX and drivers implementing a search strategy using
inverted caches (of which no current examples exist) then how long do
you think it is going to be before TDS will be installed at a majority
of TeX sites?
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Sep 1994 14:38:46 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qkcfs-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 13 Sep 94 19:33 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Argh, I was trying to stay out of this, but...
>Again: You cannot implement fonts/<type>/<source>/* without a cache
>*and* get decent response.
I run OzTeX with TDS-except-with-fonts/<type> all the time. It is
slightly slower (a few extra seconds on jobs which take a minute or
two---if people want more accurate figures I can try running a test
document on my machine and a comparison non-TDS machine) but it's
quite acceptable.
So you should add `... if you have large numbers of font families' to
the end of Joachim's sentence.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 03:01:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 13 Sep 1994 22:01:38 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409140501.WAA14009@june.cs.washington.edu>
To: TWG-TDS@shsu.edu
Subject: [te@informatik.uni-hannover.de: TeX Directory Standard]
From: te@informatik.uni-hannover.de
Date: Tue, 13 Sep 94 15:05 MET DST
To: mackay@cs.washington.edu
Subject: TeX Directory Standard
Hello,
in texmf/doc/lw35nfss/README you mention the TDS. Could you
please give me a hint where I can get it?
Thanks in advance,
Thomas
My response:
We are still working on it. Its current status is a bit healthier
than the Health-Insurance Reform bill in the U.S. Congress.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 03:03:35 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 13 Sep 1994 21:57:26 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409140457.VAA13752@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
From: David Carlisle <carlisle@cs.man.ac.uk>
Sebastian Rahtz on Tue, 13 Sep 1994 09:11:01 +0100)
Subject: Re: Summary of case for fonts/<type>/
No, it can not be so programmed. This is not an implementation
question. foo//tfm *has* to search under foo/pk as the tree may look
like
foo
xxx
tfm
cmr10.tfm
xxx
pk
tfm
cmr11.tfm
Now this is a stupid directory layout, but search strategies do not
work by common sense. A specification of foo//tfm, given the above
tree *must* find cmr11. That is the specification of the search path.
If you *specify* that the whole tree must be searched, no amount of
smart programming will get round that.
Am I being overly dense? It seems to me that in no---absolutely no---
version of the TDS proposed would it be possible to do anything so
bizarre as put tfm UNDER pk. The TDS cannot possibly be subjected to the
requirement that it make life easier for any system that would do that.
If we had to account for that sort of perversity, we would be right back to
flat directories as the only solution.
People who wish to put tfm/ under pk/ must dree their own wierd. The
TDS would, and rightly so, proscribe any such nonsense. The question
is not how we can handle anything so bizarre as that, but rather whether
a large enough number of current and near-future systems can
handle ./source/typeface/tfm rather than tfm/source/typeface.
As I look at my directory tree, and contemplate the near-catastrophe
of ./pk/dpiNNN/<printengine>, which I am willing, though with extreme
reluctance, to adopt (and to reserve the rational approach for symbolic
links), I am increasingly convinced that ./tfm/source/typeface is
the straw that will break this camel's back. Sure, that could be done
with symbolic links too, but the topology would give Norm Walsh's
spider hysterics.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 10:04:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Sep 1994 06:08:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409141008.AA05347@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
David asks what the win is to fonts/source. This is a fair question.
We talked about this long ago.
The win is maintenance -- having all the files relevant to a particular
font family in one directory is much easier to deal with than
having them be siblings in separate trees. Pierre can attest to this.
I think Sebastian's suggestion of publishing a TDS with fonts/source,
and letting the implementors complain (or start implementing :-),
was the most reasonable way out of this quagmire.
Unless we're giving up.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 10:06:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409141035.MAA13860@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Summary of case for fonts/<type>/
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Sep 1994 12:35:29 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Argh, I was trying to stay out of this, but...
We won't continue long, I'll leave for 2 weeks vacancies soon. :-)
> >Again: You cannot implement fonts/<type>/<source>/* without a cache
> >*and* get decent response.
>
> you should add `... if you have large numbers of font families' to
> the end of Joachim's sentence.
That's true, of course. I don't expect many installations with a small
number of font families in the mid-term future.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 10:11:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409141057.MAA13378@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Summary of case for fonts/<type>/
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Sep 1994 12:57:17 +0200 (MESZ)
Content-Type: text
David wrote:
>
> So I would consider that you have answered my concern (1) if you could
> tell me why, apart from being no less efficient, you want fonts/source
> ie what do you gain?
-- consistency
The macros are organized this way already, we don't spread
INITEX and TeX input of LaTeX2e over the tree.
-- modularity
(1) higher modul abstraction: The information about a given
source is not spread all over the tree.
(2) lower modul coupling: If I want to delete one type family,
it can be done more easier.
Take as an example the dreaded TeX distribution of Slackware Linux:
It installs -- without asking -- hundreds of kilobytes of font
information about HP LJ 4 builtin fonts. Since I don't have such a
printer at home, I want to delete them. In the current scheme I can
just delete everything below one font source directory, otherwise I
would have too search for the files in the whole fonts/ tree.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 10:13:33 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: the same old arguments for the twenty millionth time
Date: Wed, 14 Sep 1994 09:08:11 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:169960:940914080825"@cl.cam.ac.uk>
> With fonts/type all sites would have to do to implement TDS
> would be move a few files, and change a few paths. This would mean
this simply isnt true. how would you do it with VMS TeX? with TeXs
that have a fixed directory? withall those drivers? try dviwin, for
example, which allows *one *directory for PK files.
> So to summarise I think that fonts/type gains you at least two years
> on takeup of TDS, your argument appears mainly to be the technical one
> that fonts/type is no more efficient than fonts/source. Perhaps so,
> but what do you *gain* with fonts/source?
>
i am much more convinced by your argument of logic, that differenmt
file types should root in different places. what you agin with
fonts/source is isolating a font family in one place, hence ease of
(de)installation. i cant just say `rm -rf yinit' at some point. but i
admit this is feeble, since i cant `rm -rf martian' since its
scatterd over fonts, latex, hyphenation etc.
if it gets TDS out, i'll agree to more or less anything that has
subdirectory searching principles. since we agree that a TDS/2 might
suggest a Taylor-like scheme, we do admit of future change, so we
*could* go from fonts/tfm to source//tfm or vice versa. the point is
that both are logical, and amenable to automation, which is what we
want.
if David and Alan stop saying that `most current TeX systems can `do'
TDS now except for source//tfm', and argue on academic logic, i'll be
convinced
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 11:41:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Sep 94 15:54:27 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409141454.AA00459@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
> Am I being overly dense? It seems to me that in no---absolutely no---
> version of the TDS proposed would it be possible to do anything so
> bizarre as put tfm UNDER pk.
No my point was that the specification fonts//tfm *allows* that in
principle and therefore forces TeX to go off looking for tfm
directories under pk/ even though there will never be any such
directories.
Joachim correctly pointed out that this is not the case if a suitably
indexed cache is produced, which cheered me up considerably, but the
fact remains that no current TeX has such a suitably indexed cache.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 12:31:22 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qkyCL-0006Q7C@rsuna.crn.cogs.susx.ac.uk>
Date: Wed, 14 Sep 94 18:32 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Joachim argues in favour of fonts/<source>:
> -- consistency
> The macros are organized this way already, we don't spread
> INITEX and TeX input of LaTeX2e over the tree.
I'd have said this was an advantage for fonts/<type>... inside tex/
we segregate according to the format, rather than according to the
source. For example I've got tex/latex/asaj and tex/latex209/asaj
rather than tex/asaj/latex and tex/asaj/latex209.
Similarly, .ist, .bst, .bib etc. files are all segregated by file type
rather than by source. So I'd say consistency is on the side of
fonts/<type>.
> -- modularity
> (1) higher modul abstraction: The information about a given
> source is not spread all over the tree.
Depends how you think the search is going to be performed, e.g. are
people more likely to search by file type (I need to send ptmr7t.tfm
to my friend... where is it?) or by source (I need to send all the
Adobe Times stuff to my friend... where is it?) This one is pretty
much an even call.
> (2) lower modul coupling: If I want to delete one type family,
> it can be done more easier.
This is true. Also adding type families is easier.
So on usability I'd say it's quite a close call, with fonts/<source>
slightly ahead.
The question is, is this slight improvement worth the delay in uptake,
and the risk of developers refusing to implement the necessary code?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 12:32:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Sep 94 17:16:29 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409141616.AA00535@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Karl:
David asks what the win is to fonts/source. This is a fair question.
We talked about this long ago.
The win is maintenance -- having all the files relevant to a particular
font family in one directory is much easier to deal with than
having them be siblings in separate trees.
Yes, but if I pick a random fonts directory, say
/home/tex-archive/fonts/metrics/monotype/pepitamt
(what does this font look like??)
Well whatever the font looks like the directory looks like this
00Contents afm/ fd/ sty/ vf/
README config.mp2 mp2.map tfm/
Even given fonts/source I need to concatenate the .map files on to the
global .map files, and move the sty/ and fd/ subdirectories into the tex
subtree (if you remember, Alan and I suggested keeping fd and sty
with the fonts but that was not thought a good idea by most people)
Well if I am moving the sty and fd files, moving the tfm as well doesnt
seem such a big deal. Now if I really could keep all files that were
archived together on ctan together in the TDS that *would* be a gain.
However I feel that the argument is going nowhere so I would suggest
its time for a decision.
If the decision is fonts/source, so be it, I will not complain (in
public:-) but then the TDS document *must* explain that to support
this structure one needs a caching search strategy as outlined by
Joachim. I honestly fear that on seeing such a comment the vast
majority of people will simply ignore the proposal, but we shall
see... I really do not think that the gains for fonts/source,
especially if you are having to move fd and sty files anyway is worth
jepordising the whole proposal, but I think I may have said that
before:-)
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 14:58:06 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9409141946.AA12312@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tex input directories
Date: Wed, 14 Sep 94 15:38:16 -0400
From: bob@microprograms.com
Amen!
Bob
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Sep 1994 23:10:33 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 14 Sep 1994 21:10:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409150410.VAA26137@june.cs.washington.edu>
To: TWG-TDS@shsu.edu
Subject: [te@informatik.uni-hannover.de: Re: TeX Directory Standard]
Date: Wed, 14 Sep 94 22:42:49 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
To: mackay@cs.washington.edu
Subject: Re: TeX Directory Standard
Dear Pierre,
am trying to bring up a TeX distribution for linux (except for the
binaries anything might work on other UNIX systems as well).
Believe me, I really give my best. E.g. I look for current versions
of dvi-drivers (especially those from Karl Berry), and I really read
the docs (e.g. those from kpathsea).
The slackware tex is bad and ntex-1.1 is bad as well (e.g. no ls-R
file and directries containing hundreds of files and *one*
subdirectory. Thus breaking all optimisations of kpathsea :-).
I wrote an Email to the author of ntex, so this might get better
some day.
Therefore I am very much interested in joining the discussion of
the TeX Directory Standard, or at least (if it is possible) to
get a preprint of it. Maybe I have some good ideas thar might
help to make it even better.
Thomas
--
Thomas Esser email: te@informatik.uni-hannover.de
Universitaet Hannover, Institut fuer Informatik (Systemadministration)
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 06:05:29 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9409151101.AA14878@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Thu, 15 Sep 94 06:41:19 -0400
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
Joachim asked:
I don't understand you. Do you want to drop the whole TDS proposal? Or
do you expect to implement it?
When it comes to DVILASER/HP, DVILASER/PS and Preview, I am able (and
probably willing) to make the necessary changes. It is up to David
Fuchs if he wants to make the changes to MicroTeX since he still owns
it. The ROI for commercial implementors of TeX is rapidly diminishing.
This will not happen overnight.
BTW, we have never mentioned another brain-dead environment: MS Windows
(it is even deader than MSDOS, but it is so letharic that it doesn't
know it yet). I believe that it requires all its fonts to be in one
place. Does one using TDS duplicate the .pfb files if one is using
PostScript fonts? One of the implementors (Berthold, Lance, or
Richard) who have ported to Windows could probably give us information
we must/should consider for this environment.
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 06:05:37 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9409151101.AA14879@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Thu, 15 Sep 94 06:51:20 -0400
From: bob@microprograms.com
Joachim asked:
I don't understand you. Do you want to drop the whole TDS proposal? Or
do you expect to implement it?
When it comes to DVILASER/HP, DVILASER/PS and Preview, I am able (and
probably willing) to make the necessary changes. It is up to David
Fuchs if he wants to make the changes to MicroTeX since he still owns it.
The ROI for commercial implementors of TeX is rapidly diminishing.
Several commercial implementors have dropped out. If the remaining
commercial implementors adopt TDS, the changes will not happen
overnight. Since ORA is interested in TDS for a CD-ROM, will they force
the implementors to adopt the TDS by bringing out a CD-ROM that uses it
or will they wait to see if enough implementors adopt TDS and enough
users upgrade to that implementation to make it worth their investment
in time and money?
BTW, we have never mentioned another brain-dead environment: MS Windows
(it is even deader than MSDOS, but it is so letharic that it doesn't
know it yet). I believe that it requires all its fonts to be in one
place. Does one using TDS duplicate the .pfb files if one is using
PostScript fonts? One of the implementors (Berthold, Lance, or
Richard) who have ported to Windows could probably give us information
we must/should consider for this environment.
Bob
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 06:40:25 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Thu, 15 Sep 1994 12:38:54 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:216930:940915113904"@cl.cam.ac.uk>
re Windows, I brought up the same point about .pfb files before, I
think. I think the answer is that it'll be tedious to enter the
different paths in ATM, but possible. i'd do it by editing atm.ini :-}
since that gives absolute path names for each font, it should be OK
i am using dviwindo witha TDS-like setup, and its fine. ditto
Y&Ytex. Berthold has put subdirectory searching into all his code, and
it seems OK (though of course <cue David and Alan> it doesnt support
soyurce//tfm)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 07:45:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 15 Sep 1994 08:42:39 -0400
Message-ID: <199409151242.IAA07242@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
References: <199409131614.SAA23681@spice.iti.informatik.th-darmstadt.de> <9409151101.AA14879@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 15 September 1994 at 06:51:20, bob@microprograms.com wrote:
> The ROI for commercial implementors of TeX is rapidly diminishing.
> Several commercial implementors have dropped out. If the remaining
> commercial implementors adopt TDS, the changes will not happen
> overnight. Since ORA is interested in TDS for a CD-ROM, will they force
> the implementors to adopt the TDS by bringing out a CD-ROM that uses it
> or will they wait to see if enough implementors adopt TDS and enough
> users upgrade to that implementation to make it worth their investment
> in time and money?
Sebastian and I plan to use the TDS on the CD (the TDS is what's slowing
down production of the CD, actually). If you can't use the TDS with your
implementation, you'll have to install the files off the CD onto your disk,
but you'll still have them in a neat, organized, understandable structure
on the CD so even installation off the CD should be easy.
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 07:47:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Thu, 15 Sep 1994 08:44:16 -0400
Message-ID: <199409151244.IAA07246@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: The envelope please...
Reply-To: TWG-TDS@SHSU.edu
Hello everyone,
Regarding the fonts subdirectory tree, about the only thing we all
seem to agree on is that it's time to make a decision. As chairman,
I feel that it's my responsibility to do so. I could put it up for a
vote; but I don't really feel that there are enough of us on the
committee to make 'majority rules' very fair.
I agonized over this for a long time and I've waffled back and
forth several times. Here's how I feel about it: (everything below
is my _opinion_, no diplomacy here; no offense intended to anyone)
First off, I think we should acknowledge that there are implementors,
users, and system administrators who will never adopt the TDS. A lot of
people subscribe to the misguided philosophy that 'if it ain't broke,
don't fix it' and if they have working TeX systems, they aren't about to
use the TDS. I don't care. Really. I think the arguments in favor
of the TDS speak for themselves but I don't expect every single A. N.
User to switch. You shouldn't either.
- Most platforms can use fonts/type
I don't believe it. There are only four implementations that can
do subdirectory searching *at all* so the reality is most implementations
can't use the TDS without some modifications.
Of those four systems, one includes optimizations that make the TDS
practical for large numbers of fonts, two don't, and one only works
with fonts/type. Hardly a strong case for any particular organization.
- (Related) the L2e/3 team can start expecting the TDS to be standard by
December if we use fonts/type, but not if we use fonts/source.
I don't believe it. It'll be years before everyone switches. If it
was god's gift to file organizations, it'd be years anyway. The L3
team can start using it for documentation as soon as everyone knows what
it is. In other words, it can be an understood standard that people
use for 'interchange' if they have local variation. If the L3 team
is waiting for every user, they'll never be able to use it.
- fonts/source requires searching all the PK files
In an unoptimized system, yes. But very reliable sources have indicated
that even if you don't search the PKs you won't like the performance
of an unoptimized system. And your DVI driver has to look at all these
files too, so if you don't have some optimization; you're doomed.
(yes, you TeX more often than you use a driver---but not much more often)
A few systems provide CMR in scalable form so there won't be many PKs
anyway (yeah, it's weak).
- fonts/type allows the user to specify different search paths for different
sorts of files (search the /tfm directory for tfms, the /vf directory for
vfs, etc.).
Good point. Most users don't care, though. They'd probably rather not
specify different paths for different things that they don't really
understand.
- fonts/source wins on modularity and maintainability
Gotta agree.
- fonts/type is more logical
Separating files by type is a logical way to organize the tree. We
have chosen that methodology for some types of files.
- fonts/source is more logical
Separating files by typeface is a logical way to organize the tree.
We have organized other parts of the TDS by high-level concept (typeface
being roughly analagous to format).
And the winner is ... (drumrole please) ...
`fonts/source/typeface/type'
Feel free to curse me to everlasting torment if it'll help. ('course I
would have had to say that no matter which arrangement I selected ;-)
Let's propose it this way and let the implementors offer suggestions if
they find it too difficult. I'll try to explain both sides of the issue
in the documentation and provide an address where implementors can
complain.
'nuff said?
--norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 08:03:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 15 Sep 94 14:03:19 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409151303.AA01161@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
> And the winner is ... (drumrole please) ...
Well, as you might expect I think this is a very bad decision which
will probably kill off TDS, however *any* decision is better than no
decision so I dont propose to restart the discussion at this point.
I think the thing to do now is to wait until Norm gets time to redraft
the document. Then we can see exactly how this is phrased, to see if
we can live with it.
I will just comment on one point that Norm raised
> - (Related) the L2e/3 team can start expecting the TDS to be standard by
> December if we use fonts/type, but not if we use fonts/source.
>
> I don't believe it.
I think you missed our point. It wasnt a statement about what we
`expected' to happen, it was a statement of fact.
With fonts/type we *would* have re-written the latex installation
documentation assuming TDS for the next release this Christmas.
Anyone not using TDS would have had to translate accordingly.
With fonts/source we will not write the documentation assuming TDS at
any point in the forseable future.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 08:23:37 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
Date: Thu, 15 Sep 1994 14:22:57 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:261050:940915132317"@cl.cam.ac.uk>
unexpcected bitterness from David - latex2e wont recommend the TDS to
people at all? thats a bit harsh, without waitiong to see whether the
implementors *do* react favourably?
if the LaTeX documentation takes an anti-TDS stand, then i say we have
to give in to blackmail and do what they want. seriously. the whole
thing is pointless if its not recommended by such a big player.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 08:28:44 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qlGqv-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 15 Sep 94 14:27 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
I agree with David on the merits of the decision, but the referee's
decision being final and all that...
>Let's propose it this way and let the implementors offer suggestions if
>they find it too difficult. I'll try to explain both sides of the issue
>in the documentation and provide an address where implementors can
>complain.
I can live with that, if we put together a draft which says `here are
the arguments for TDS... here are the arguments for fonts/<type>/...'
and send it to implementors. Of course by the time it goes out to the
general public we'll have to get rid of any `minority reports'.
I'm quite happy to write an appendix on the advantages of
fonts/<type>/, although whether everyone else would want it included
is another matter :-)
In the mean time, before we send a draft to the implementors, I'd like
to send a letter out asking about subdirectory searching in the
various TeX platforms. I'll attatch a draft for people to comment on.
I think this information would be useful in composing the TDS draft
for implementors.
Cheers,
Alan.
--- cut here for letter to TeX implementors ---
Dear TeX implementors,
As you may already know, TUG has got a technical working group looking
into standardizing on a directory structure for TeX platforms. Such a
standard directory structure would allow TeX packages to be
distributed more easily, with documentation saying `put these files in
texmf/tex/latex/graphics' rather than `put these files somewhere where
TeX searches for input files'.
In order to know how best to arrange these structures, we need to know
how different TeX platforms can cope with multi-level directory
structures. If you could take the time to fill in the attatched form
and send it to me at alanje@cogs.susx.ac.uk, this would be very
useful!
Thanks for your time,
Alan.
Alan Jeffrey Tel: +44 273 678526 alanje@cogs.susx.ac.uk
School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK
--- cut here for form ---
NAME:
EMAIL:
TEX IMPLEMENTATION:
This version of TeX currently supports (delete ones which don't apply):
* only one directory for each sort of file (for example, all tfm
files have to be in fonts/tfm)
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
* many-level subdirectory searching with pruning (for example you can
specify fonts//tfm and it will find
fonts/adobe/times/tfm/ptmr7t.tfm)
* many-level subdirectory searching with a cache to avoid
searching the whole directory structure for every file (for
example, the ls-R file in kpathsea).
* something else (please specify!)
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
* many-level subdirectory searching with a cache
* something else
If the TUG technical working group ask us to, we will implement:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
* many-level subdirectory searching with a cache
* something else
Any other comments:
Please mail this to alanje@cogs.susx.ac.uk.
--- end of form ---
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 09:51:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 15 Sep 94 07:49:47 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409151449.AA00117@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: TDS on CDs
> Sebastian and I plan to use the TDS on the CD (the TDS is what's slowing
> down production of the CD, actually).
By accidents of timing and product design, Issue 1-1 of TeXcetera avoided
getting held up by the TDS discussions. If and when a clean TDS emerges,
however, PTF would hope to use it as well. This is not an attempt to force
anything on anyone; simply an endorsement of the reason why the TDS effort
was started: TeX needs a clean, understandable, and implementable structure
for its rather overwhelming number of files and directories. As publishers
of CDs, neither ORA nor PTF can afford to go off on some non-standard hack,
however nifty it might seem at the time. The costs in support are simply
too large to be worth it...
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 09:55:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409151454.QAA20309@spice.iti.informatik.th-darmstadt.de>
Subject: Re: The envelope please...
To: TWG-TDS@SHSU.edu
Date: Thu, 15 Sep 1994 16:54:19 +0200 (MESZ)
Content-Type: text
Alan wrote:
>
> In the mean time, before we send a draft to the implementors, I'd like
> to send a letter out asking about subdirectory searching in the
> various TeX platforms. I'll attatch a draft for people to comment on.
Please add:
If there is a freely distributable implementation of a fast
directory tree file searching algorithm, implemented in C, would
you use this modul to enable a TDS conformant behaviour?
Legal add-on question: Can this implementation be under a MIT
X style copyright? (I.e., you can use it as you like but have to
acknowledge its source -- namely, TUG -- in your documentation.)
Or must it be really public domain?
I would like to know how many TeX implementors would use such an
implementation.
You can also add the question, if they would like an implementation in
Common Lisp -- but I think the answer is known in advance. :-(
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 10:02:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 15 Sep 94 08:00:07 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409151500.AA00274@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Minor nit
Without a reason to do so, most implementors will not be putting in most of
the searching strategies you mention. Hence, it may make more sense to ask
whether they would be *willing and able* to introduce new strategies, as:
> By this time next year, this version of TeX should (don't worry, we
could
It may also be worthwhile to offer a sample implementation for at least one
operating system.
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 10:15:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 15 Sep 94 08:13:10 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9409151513.AA00432@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Legal add-on question
I suspect that an X-style copyright would not cause too much heartburn
in general, but it might cause some at large, overstuffed institutions.
If you want to be safe, put the code into the public domain but request
that users retain the copyright notice. Most will comply.
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 10:20:24 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
Date: Thu, 15 Sep 1994 16:10:16 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:013140:940915151034"@cl.cam.ac.uk>
alan's letter sounds cool to me. i just hope thatthe tex-implementors
list or whatever he uses has the driver writers on. eg the dviwin man,
Paul Vojta, etc, not just those who make TeX. was it clear in the
letter that this applies to any dvi driver as well as a TeX?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 10:50:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 15 Sep 1994 11:49:51 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
To: TWG-TDS@SHSU.edu
Message-ID: <779644192.14788.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
following up on sebastian's question whether the tex-implementors
includes driver writers, yes, it has on it all who are known to
me. however, paul vojta is not.
sebastian, and anyone else interested and willing, would you please
review the list (i'll send you a copy separately -- just let me
know you will do it before the weekend, because i am leaving town
early next week and won't be back until oct 6) and send me any
updates you can think of. i'll do the updating and notification
to anyone who's added.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 14:37:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 15 Sep 1994 12:37:43 -0700
Message-ID: <199409151937.MAA03530@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
> Date: 15 Sep 1994 11:49:51 -0400 (EDT)
> From: bbeeton <BNB@MATH.AMS.ORG>
> Subject: Re: The envelope please...
> To: TWG-TDS@SHSU.edu
>
> following up on sebastian's question whether the tex-implementors
> includes driver writers, yes, it has on it all who are known to
> me. however, paul vojta is not.
Allow me to introduce myself. I am Paul Vojta; I maintain xdvi, a dvi
previewer for the X Window System. This is not to be confused with xdvik,
maintained by Karl Berry, which implements subdirectory searching,
although we do share code fixes at times. I guess you could call my version
of xdvi the "OEM version."
My version of xdvi implements a cruder form of subdirectory searching:
without the // and ls-R features, but with arbitrarily deep nesting.
It's actually Karl's code from way back.
So please put me on your list; my e-mail address is vojta@math.berkeley.edu
--Paul Vojta
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 15:00:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 15 Sep 1994 15:59:54 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
To: TWG-TDS@SHSU.edu
Message-ID: <779659194.696100.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 15:41:23 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qlNdg-0006PXC@rsuna.crn.cogs.susx.ac.uk>
Date: Thu, 15 Sep 94 21:42 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Minor nit
>> By this time next year, this version of TeX should (don't worry, we
> could
I thought about `could' here, but the problem is that it might be
interpreted as `is it technically feasible to implement <blah>', to
which the answer is almost always `yes', since these machines are
presumably Turing complete :-) I was just wanting a gradient of `this
is what we do at the moment, this is what we're planning to do, this
is what we'll do if leant on'. I think what you're wanting is closer
to the third question...
>It may also be worthwhile to offer a sample implementation for at least one
>operating system.
True. I'll try to draft something which says `we'll offer code if you
want it'.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Sep 1994 16:02:04 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qlNff-0006PXC@rsuna.crn.cogs.susx.ac.uk>
Date: Thu, 15 Sep 94 21:44 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: The envelope please...
> If there is a freely distributable implementation of a fast
> directory tree file searching algorithm, implemented in C, would
> you use this modul to enable a TDS conformant behaviour?
OK, I'll try to come up with a form of words which says this and keeps
the form reasonably easy to fill in.
>You can also add the question, if they would like an implementation in
>Common Lisp -- but I think the answer is known in advance. :-(
Or David and myself could implement it inside TeX itself :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 16 Sep 1994 14:46:45 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9409161938.AA27331@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Fri, 16 Sep 94 12:56:25 -0400
From: bob@microprograms.com
Sebastian was kind enough to respond with:
re Windows, I brought up the same point about .pfb files before, I
think. I think the answer is that it'll be tedious to enter the
different paths in ATM, but possible. i'd do it by editing atm.ini :-}
since that gives absolute path names for each font, it should be OK
Does that not imply the user is running atm? (Yes, I am when forced to
use Windows, but does everyone?). Will they not also have to change
win.ini. Will non-TeX programs find fonts correctly after such changes?
Windows is such a Rube Goldberg arrangment I hate to touch anything!
Bob
================================================================================
From owner-twg-tds@shsu.edu Fri, 16 Sep 1994 18:43:55 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qlmy2-0006QKC@rsuna.crn.cogs.susx.ac.uk>
Date: Sat, 17 Sep 94 00:45 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
>Does that not imply the user is running atm? (Yes, I am when forced to
>use Windows, but does everyone?). Will they not also have to change
>win.ini. Will non-TeX programs find fonts correctly after such changes?
>Windows is such a Rube Goldberg arrangment I hate to touch anything!
The situation on the mac is (of course) much worse. Fonts have to
live in the systems/fonts/ folder in a proprietry Mac suitcase format.
PFA, PFB, bitmaps etc. just don't exist on the Mac---these are just
resource forks from the suitcase file. Hey ho, on some architectures
fonts live where the writers of the OS told you. Life is hard.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 17 Sep 1994 05:23:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 17 Sep 1994 06:23:13 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409171023.AA26974@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Well if I am moving the sty and fd files, moving the tfm as well doesnt
seem such a big deal. Now if I really could keep all files that were
archived together on ctan together in the TDS that *would* be a gain.
I think this is a good point.
Perhaps the .sty and .fd files should be in the fonts/ directory after
all. I really don't have much of a stake in putting them under the TeX
inputs tree, though I guess I was arguing for it before.
Putting them under fonts/ works for me -- but this will require even
more from the implementation (since many more directories will now be
searched). Doesn't bother me, but I rather think it's a lose on ``can
be implemented now'' front.
Not all typefaces have .fd and/or .sty files distributed with them, but
a lot do, I agree.
Pierre, perhaps you could comment?
================================================================================
From owner-twg-tds@shsu.edu Sat, 17 Sep 1994 05:23:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 17 Sep 1994 06:23:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409171023.AA26982@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
The question is, is this slight improvement worth the delay in uptake,
and the risk of developers refusing to implement the necessary code?
Alan, *even if* it was fonts/type, implementations *still* have to
change. Don't kid yourself that existing implementations are usable
with the currently specified subdirectory searching for either
fonts/type or fonts/source. (Except if you have few font directories,
but we can't make the TDS usable only at such sites!)
If you want to make the TDS usable at most sites, with most
implementations, you can't have subdirectory searching at all. So far
as I can see.
================================================================================
From owner-twg-tds@shsu.edu Mon, 19 Sep 1994 04:23:45 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
Date: Mon, 19 Sep 1994 10:23:05 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:200170:940919092311"@cl.cam.ac.uk>
> Does that not imply the user is running atm? (Yes, I am when forced to
> use Windows, but does everyone?). Will they not also have to change
you are thinking of non-ATM users accessing the PS fonts from Word, or
something? god knows how that works.
> win.ini. Will non-TeX programs find fonts correctly after such changes?
yes...
> Windows is such a Rube Goldberg arrangment I hate to touch anything!
quite. but one can, if need be. simpler to add \psfonts to ones list
of header directories for dvi to PS programs
s
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 13:24:24 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 27 Sep 1994 11:24:19 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409271824.LAA23560@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: The envelope please...
From: norm@ora.com (Norman Walsh)
Subject: The envelope please...
And the winner is ... (drumrole please) ...
`fonts/source/typeface/type'
Feel free to curse me to everlasting torment if it'll help. ('course I
would have had to say that no matter which arrangement I selected ;-)
I have been away for ten days, so this comes to me as a welcome surprise.
The CD is not the only place where a stabilized TDS will be honored.
I have a whole collection of packages, mine and others, which are
being reshaped into TDS trees as the branches emerge from the foliage.
In so far as possible, the next organization of the UnixTeX tape
( We get about one order a month ) will be TDS compliant.
I have almost completed a script for redistributing PK files
in dpiNNN order (and then linking them back into *.NNNpk files so
that old versions of kpathsea will work). I have recompiled the
Arabtex fonts to include the informational specials, and am going
through the small set of ps2pk fonts we send out to add the
specials there.
So as soon as a reasonable firm draft of your specifications is
available, let me have it, and I will rearrange all the other stuff to fit
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 13:24:26 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 27 Sep 1994 11:24:19 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409271824.LAA23560@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: The envelope please...
From: norm@ora.com (Norman Walsh)
Subject: The envelope please...
And the winner is ... (drumrole please) ...
`fonts/source/typeface/type'
Feel free to curse me to everlasting torment if it'll help. ('course I
would have had to say that no matter which arrangement I selected ;-)
I have been away for ten days, so this comes to me as a welcome surprise.
The CD is not the only place where a stabilized TDS will be honored.
I have a whole collection of packages, mine and others, which are
being reshaped into TDS trees as the branches emerge from the foliage.
In so far as possible, the next organization of the UnixTeX tape
( We get about one order a month ) will be TDS compliant.
I have almost completed a script for redistributing PK files
in dpiNNN order (and then linking them back into *.NNNpk files so
that old versions of kpathsea will work). I have recompiled the
Arabtex fonts to include the informational specials, and am going
through the small set of ps2pk fonts we send out to add the
specials there.
So as soon as a reasonable firm draft of your specifications is
available, let me have it, and I will rearrange all the other stuff to fit
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 14:37:10 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 27 Sep 1994 12:37:06 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409271937.MAA03511@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Summary of case for fonts/<type>/
I am against putting sty and fd files in the fonts tree.
Both sorts are macro files. They may be odd macro files
but they are still TeX macros. They do not describe a font
or even its metrics. They describe modes of access to that
font and to its various sizes etc.
I emphasize this in case the placing of TFMs is brought up
as a counter-argument. TFMs are also used by TeX, but they
are not macro files. They contain character by character
details about the font, which sty and fd files do not.
But basically, the argument that macros should stay among
macros seems to me sufficient.
Pierre
(Sorry for the delay in answering. I have been out of town.)
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:06:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272006.VAA17314@spice.iti.informatik.th-darmstadt.de>
Subject: TeX macros that may be formats
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:06:39 +0100 (MEZ)
Content-Type: text
What do we do about macro packages that *may* be a format.
The most prominent example is texinfo.tex: Some sites may want to
dump it (e.g., I do it), many others will just use it as a plain TeX
macro package.
So, is stored in tex/texinfo/ or in tex/plain/texinfo/ ?
My opinion: The latter.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:13:08 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272012.VAA17324@spice.iti.informatik.th-darmstadt.de>
Subject: searchpaths for formats
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:12:48 +0100 (MEZ)
Content-Type: text
Do we assume that TeX formats have only their directory tree and
tex/generic/ in their search path?
Or can we assume that a format may have other formats as well in their
paths?
The question arises with AmS-TeX and with a TeX format of my own that
are clearly an extension to plain TeX. In such they differ from
LaTeX that shares some code, but is not an extension. It would be
nice if one could assume that AmS-TeX sources have tex/amstex,
tex/plain, and tex/generic in their default search path (in that
order). Then tex/generic could really be reserved for general,
mostly format-independent TeX macros like path.sty and texnames.sty.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:17:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272017.VAA17332@spice.iti.informatik.th-darmstadt.de>
Subject: A package level in each format directory?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:17:21 +0100 (MEZ)
Content-Type: text
Is there a package level in each TeX format directory?
E.g., tex/amstex has currently 7 files. Do I store these 7 files in
an own directory base/ that will remain the only directory therein?
How about tex/generic? We specified that single (small) files go in
misc/. Most probably all packages in this category are single files,
at least all I know of. Do we create a tex/generic/misc/ as the only
directory therein?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:23:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272022.VAA19395@spice.iti.informatik.th-darmstadt.de>
Subject: TDS compliant base set available via ftp
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:22:55 +0100 (MEZ)
Content-Type: text
I made the base set of a TDS compliant TeX available via anonymous ftp
at ftp://ftp.th-darmstadt.de/pub/tex/TDS-compliant/.
I've appended the two relevant READMEs below, fyi. I would like to
get feedback if I should tell you about major updates in this
directory tree.
Joachim
---------------- snip snap ----------------------------------------
# tex/TDS-compliant/README 27 Sep 94
#------------------------------------------------------------
TDS stands for `TeX Directory Structure', there is a TUG Technical
Working Group who tries to establish recommendations for such a beast.
This directory tree features stuff around this effort.
By now, we have the following available:
draft - read about the TDS
archives - archives with TeX files in a directory structure
that conforms to the latest TDS draft.
map.lst - map of directories that are in the archives
Contact Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> if you
want more information about the files here or if you want to make
comments on this effort. Note that the archives are a private effort,
done in my sparse time. Keeping them (a) up-to-date with the software
and (b) up-to-date to the still-changing TDS structure will be more
important than supplying lots of documentation about the archives.
---------------- snip snap ----------------------------------------
# tex/TDS-compliant/archives/README 27 Sep 94
#------------------------------------------------------------
In this tree you'll find archives for an TDS compliant installation
of a TeX author system. They must be extracted in the texmf/ directory.
By now, we have the following archive categories available:
independent - platform-independent
Currently, only basic files. More will be added as time permits and
as I need them. But even more important (for me ;-)
rs6000-aix - AIX 3.2 on RS/6000
i486-linux - Linux on PCs
hppa-hpux - HP-UX 9.x on HP 700
sun4-solaris - Solaris 2.3 on Sun Sparc
will be added RSN.
In each directory listed above, there is a file VERSIONS that keeps
information about every archive.
In one point the archives do not confirm to the TDS: There is a
directory filesets/ in there with subdirectories that do not obey the
8.3 name rule. Don't bother, I just need them for my internal
organisation, I have a bunch of shell scripts that look at such
directories and handle archive removal and update.
Contact Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> if you
want more information about the files here or if you want to make
comments on this effort. Note that the archives are a private effort,
done in my sparse time. Keeping them (a) up-to-date with the software
and (b) up-to-date to the still-changing TDS structure will be more
important than supplying lots of documentation about the archives.
---------------- snip snap ----------------------------------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:26:25 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272025.VAA15050@spice.iti.informatik.th-darmstadt.de>
Subject: hyphen directory
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:25:53 +0100 (MEZ)
Content-Type: text
Do we recommend a consistent naming of hyphenation files? Or do we
refer to the recommendation by TWG-MLC?
Namely, that's LLhyphX.tex, where LL is the ISO language abbrev and X
is a unifying letter or number, etc.
My problem: Such naming conventions are not used on CTAN. Do we
recommend or even expect that they are used in a TDS distribution? Or
do we recommend that the CTAN file names are used?
(Currently, my TDS archives use the CTAN file names. But I'm not happy
with it, a more regular name structure would give me a warm and fuzzy
feeling. ;-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:29:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272029.VAA15061@spice.iti.informatik.th-darmstadt.de>
Subject: hyphen, more
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:29:55 +0100 (MEZ)
Content-Type: text
I forgot another problem with tex/hyphen
We decided that language names are used for subdirectories therein.
I assume that we mean the English names for each language; after all,
every directory is named in English.
What do we do with languages that have more than eight characters in
their name? Currently, problematic are: icelandic, norwegian, and
portuguese. (This concerns those that are available on CTAN, I did
not check for other sources.)
Btw, can anybody check if I used correct English language names in my
TDS archive?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:34:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272034.VAA15071@spice.iti.informatik.th-darmstadt.de>
Subject: single TeX macro files always in misc?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:34:37 +0100 (MEZ)
Content-Type: text
We said that single macro files should go in tex/<format>/misc. Am I
correct, that this is really a `should' and not a `shall'?
It should be at the discretion [sp?] of the distributor if the files
go into misc or into an own directory. E.g., in my TDS archives I used
own directories for plain/texinfo and latex/texdraw, but placed other
files in misc/, as I saw it fit.
The TDS draft should make that clear.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:39:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272039.VAA15080@spice.iti.informatik.th-darmstadt.de>
Subject: subdirectories below tex/mf?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:39:22 +0100 (MEZ)
Content-Type: text
We decided to introduce a directory texmf/mf for non-font MF input
sources. (That directory is not yet part of the TDS draft.)
Shall that directory have subdirectories, for analogy with texmf/tex?
My opinion: no. Currently, this directory holds
tex:spelunke $ ll mf
total 192
-rw-rw-r-- 1 tex software 183 Aug 12 1992 expr.mf
-rw-rw-r-- 1 tex software 62178 Aug 30 17:11 modes.mf
-rw-rw-r-- 1 tex software 221 Aug 12 1992 null.mf
-rw-rw-r-- 1 tex software 22628 Jun 27 1993 plain.mf
and I don't expect to have many additional files. The only point
would be to distinguish modes.mf and the rest. But I think that this
is not so important for 4 files...
Joachim
PS: I assume that neither font test files, nor gray fonts, nor files
with symbols for DEK's C&T series are placed in this directory; they
belong under texmf/fonts.
Any contradictionary opinions?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:50:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272050.VAA17402@spice.iti.informatik.th-darmstadt.de>
Subject: directory name for logo fonts
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:50:20 +0100 (MEZ)
Content-Type: text
In my TDS archives [*], I have renamed fonts/public/logo to
.../mflogo. Even though the fonts are named logo* I think the
typeface directory name `mflogo' would reflect their intent better.
I would appreciate any comments on this renaming.
Joachim
[*] mflogo.sty is missing therein and will be added later -- when I
have checked which one to use...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 15:57:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272055.VAA17154@spice.iti.informatik.th-darmstadt.de>
Subject: Texinfo documentation
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:55:10 +0100 (MEZ)
Content-Type: text
We decided that Texinfo documentation goes in doc/info.
I would like to see a `may go' in the draft here, as a sysadmin might
want to put the Info files to the global info directory. (I surely do.)
But how about the Texinfo source files? Would you -- as a user --
expect that they are a part of a minimal distribution? Would you
expect them to be part of an auxiliary distribution bundle? We do
place such files in doc/<package> as outlined in the draft, don't we?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 16:01:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272101.WAA19211@spice.iti.informatik.th-darmstadt.de>
Subject: recommendation for PK specials
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 22:01:26 +0100 (MEZ)
Content-Type: text
Just a reminder: There was a motion that we should urge distributors
to include `modes.mf'-PK-specials into their fonts. That's still not
part of the draft.
If we add such a recommendation, we must also mention that the
distributed base files should have the special code as well.
As an example: Though the mode-definitions of Slackware TeX seams to
be created somehow from modes.mf, the produced PK files contain no
specials. (That TeX distribution is @#!!@# anyhow. On the weekend I
got rid of it...)
Joachim
[wondering if anybody will read this $n$th mail... ;-)]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 16:15:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272046.VAA24562@spice.iti.informatik.th-darmstadt.de>
Subject: test subdir for cm fonts needed
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 27 Sep 1994 21:46:01 +0100 (MEZ)
Content-Type: text
We need the explicit possibility to add more types to
fonts/<source>/<typeface> than the ones listed in the draft.
As an example, the cm fonts come with test files to test new
character implementations (3test.mf, 6test.mf, etc.) They will be
placed best in fonts/public/cm/test.
Btw, this is also an argument in favor of fonts/<source> compared to
fonts/<type>. It's easier to add new <source> or <typeface> specific
types that are irrelevant for other types.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 16:57:36 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 27 Sep 1994 14:57:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272157.OAA21496@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: directory name for logo fonts
Since the directory name is our own, and no change is made to
DEK's filenames, this seems to make a lot of sense. I
would support it.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Sep 1994 16:59:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 27 Sep 1994 14:59:36 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409272159.OAA21907@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: recommendation for PK specials
Do we really have to ship precompiled bases? They take such
a little time to compile, and are so relatively simple compared
with all that is now going into things like LaTeX2e.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Sep 1994 05:25:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Sep 1994 06:25:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409281025.AA05002@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX macros that may be formats
texinfo.tex is one file, so I am all for tex/plain/texinfo.tex.
Why have a subdirectory?
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Sep 1994 06:17:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409281117.MAA20405@spice.iti.informatik.th-darmstadt.de>
Subject: Re: recommendation for PK specials
To: TWG-TDS@SHSU.edu
Date: Wed, 28 Sep 1994 12:17:49 +0100 (MEZ)
Content-Type: text
You wrote:
>
> Do we really have to ship precompiled bases?
No, but a turn-key distribution will perhaps include them. And *if*
they are shipped, they should use modes.mf-specials.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Sep 1994 06:20:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409281120.MAA22460@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TeX macros that may be formats
To: TWG-TDS@SHSU.edu
Date: Wed, 28 Sep 1994 12:20:27 +0100 (MEZ)
Content-Type: text
You wrote:
>
> texinfo.tex is one file, so I am all for tex/plain/texinfo.tex.
> Why have a subdirectory?
Because the author of kpathsea recommends to have either directories
or files in one directory, for efficiency reasons. And who are we to
discuss with this honorable person... :-) :-)
Seriously, plain/texinfo.tex would mean a mixture of files and
directories, that's not good to explain in the TDS document.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Sep 1994 14:08:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 28 Sep 1994 12:08:57 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409281908.MAA18463@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: recommendation for PK specials
Ok. Full agreement in that case. Bases, when distributed,
should be compiled with modes.mf.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Sep 1994 05:14:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Sep 1994 06:13:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409291013.AA09420@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX macros that may be formats
Having directories with one file (or one directory) in them
seems pointless to me. The efficiency considerations aren't
paramount in this case, since the total number of files in
the directory is small. Anyway, we already know disk-based
searching is a lose :-)
Maybe plain/misc or wherever the single-file sources go?
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Sep 1994 05:14:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Sep 1994 06:14:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409291014.AA09474@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: A package level in each format directory?
E.g., tex/amstex has currently 7 files. Do I store these 7 files in
an own directory base/ that will remain the only directory therein?
Nah, why bother?
Do we create a tex/generic/misc/ as the only
directory therein?
Nah, why bother? generic is for stuff that works with multiple formats,
right? I doubt there are any multi-file packages in that category.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Sep 1994 05:14:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Sep 1994 06:14:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199409291014.AA09482@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: single TeX macro files always in misc?
We said that single macro files should go in tex/<format>/misc. Am I
correct, that this is really a `should' and not a `shall'?
We should spell out the exceptions (or the rule that makes the
exceptions), I suppose. There's no point in saying ``should'' in the
standard.
Certainly for <format>s that would otherwise have no subdirectories,
having a single subdir misc/ seems pointless to me.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Sep 1994 07:50:18 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qqKvM-00007GC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 29 Sep 94 13:49 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: A package level in each format directory?
>Nah, why bother? generic is for stuff that works with multiple formats,
>right? I doubt there are any multi-file packages in that category.
I think I'm going to ask for tex/fontinst in that case---it's not only
multi-file, it's multi-directory! The current structure could easily
fit TDS: tex/fontinst/base, tex/fontinst/examples,
tex/fontinst/malvern, etc.
Alan.
From owner-twg-tds@shsu.edu Mon, 03 Oct 1994 05:44:52 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, more
Date: Mon, 03 Oct 1994 11:44:37 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:052250:941003104449"@cl.cam.ac.uk>
we (CTAN) should change the hyphenation names to the babel ones, which
are all `ok', arent thye? then theTDS can follow
s
================================================================================
From owner-twg-tds@shsu.edu Mon, 03 Oct 1994 05:46:49 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
Date: Mon, 03 Oct 1994 11:45:40 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:052970:941003104604"@cl.cam.ac.uk>
CTAN should reflect the ML working party recommendations, i think. no
reason not to
s
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 07:22:15 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410101221.NAA22448@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, more
To: TWG-TDS@SHSU.edu
Date: Mon, 10 Oct 1994 13:21:26 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> we (CTAN) should change the hyphenation names to the babel ones, which
> are all `ok', arent thye? then theTDS can follow
On the weekend I tried to follow this proposal. There are no `babel
hyphenation names'. Or did I miss something?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 08:01:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410101301.OAA20363@spice.iti.informatik.th-darmstadt.de>
Subject: draft document
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 10 Oct 1994 14:01:45 +0100 (MEZ)
Content-Type: text
Where was the ftp site with the most current draft? I looked at
jasper.ora.com, but couldn't find it there.
Norm, any chance to make a new version soon, without restructuring and
where just the results of the recent discussion has been merged in?
Joachim
PS: This is the third WG on TDS I'm in. The last two prepared early
proposals (that looked very similar) and when it came to the
nitty-gritty details that were still inconsistent in this proposal the
work dropped. I still hope it will be better this time... :-(
PPS: I still wait for some input on my questions I sent around.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 08:06:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410101306.OAA20370@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen directory
To: TWG-TDS@SHSU.edu
Date: Mon, 10 Oct 1994 14:06:25 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> CTAN should reflect the ML working party recommendations, i think.
I think I spread misinformation. I just checked the TWG-MLC archive
and I didn't found any mention of pattern file names.
So I think we're back to make no recommendation on these file names.
Nevertheless, in preparing my example-TDS-distribution I have the
problem that some filenames don't follow the 8+3 rule. Any opinion
how distributors will/shall/should handle this? Select a name like
they want? Then we have dozens of files with the same content and
different names. Wait for CTAN to change the names?
My current action is simple: I give a damn about 8+3, as long as
file names are still unique after truncation and don't have more than
2 dots in them.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 08:59:31 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
Date: Mon, 10 Oct 1994 14:59:13 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:129090:941010135920"@cl.cam.ac.uk>
i thought the ML grouo proposed a whole set of 2 letter abbreviations,
and published them in TUGboat?
dont say "wait for CTAN to change". send a list of anomalies if you
have time, and I will change them. CTAN is Us.
what were the other two WG on TDS, may one ask?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 12:02:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410101702.SAA21639@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen directory
To: TWG-TDS@SHSU.edu
Date: Mon, 10 Oct 1994 18:02:39 +0100 (MEZ)
Content-Type: text
You wrote:
>
> i thought the ML grouo proposed a whole set of 2 letter abbreviations,
> and published them in TUGboat?
Do you mean the proposal to use the ISO two letter abbreviations for
language specific files? But I don't remember a comment about
pattern file names therein. (Actually, I did a "grep pattern" over
all documents from this TWG. As a TWG-MLC member, they are available
to me...)
The problem with hyphenation files is that there might be more than
one set of hyphenation patterns for a language, as this happens to be
for French. If one uses a distinguishing character after `XXhyph',
who decides about which is the `a' and which is the `b' set?
> dont say "wait for CTAN to change". send a list of anomalies if you
> have time, and I will change them. CTAN is Us.
I had a different question in mind: Who decides what an anomaly is?
There is an author who named his file tkhyphart.tex (just as an
example, Pierre; I would use such a name myself... :-) Will _you_
change it to tkhyphar.tex?
Anyhow, the following files in CTAN:/tex-archive/language/hyphenation/
are concerned:
hyphen.polish an internal comment says that this is
the file hyphen.pol. Therefore I renamed
it for the TDS example-distribution.
portug.hyphen A more current version is in
CTAN:/tex-archive/digests/tugboat/porthyph.tex
tkhyphart.tex A doc file, btw.
which subdirectory to use for that?
texmf/doc/hyphen/ ?
README.ghyphen where is that placed? in texmf/tex/hyphen/german/
or in texmf/doc/hyphen/ ?
in the former case one can rename it to README.
In addition, a file named ushyphen.tex or similar is missing, that
combines ushyph{1,2}.tex.
> what were the other two WG on TDS, may one ask?
Oh, you invited me to say something on the effectivity of TeX WGs?
Your fault... :-) :-) OK: two data points about TDS and one data
point that results of WGs are simply ignored by the TeX community.
The first TDS discussion did not happen in a real WG. At the EuroTeX
Meeting in Exeter (1988) we had a BOF on this topic. Somebody wrote
up a result paper. The new thing (for this time) was the
introduction of a directory for each format, instead of lumping
everything together in one inputs directory. I think to remember
that this paper was sent to some mailing lists then, but nobody was
willing to put the reactions back in the paper.
The second effort was an `official' DANTE WG. It has a Bitnet
mailing list, texdir-l@dhdurz1.bitnet. There should be backlogs at
the Bitnet listserver. Those of you who speak German can look up the
latest result of the directory tree, as of 23 Sep 91. It's in
ftp.th-darmstadt.de:/pub/tex/documentation/texdir.txt.gz . There was
one mail on this mailing list in October of this year -- and then it
died. (As I wrote, nobody wants to make the nitty-gritty details
consistent.)
Some of you might remember that I chaired a panel at the Paris EuroTeX
meeting named ``Why is TeX unusable?'' This topic was discussed there
at great length, everybody agreed that something has to be done,
nobody did something.
Now, let's look at something with results: The DVI Driver Standards
Committee (I am/have been/was the secretary) published a document
where the basic functionality of a DVI driver is described. In
particular, we went to great pain to describe rounding methods that
yield smooth placements of letters in words; readers shall not be
disrupted. I gave four [sic!] talks about the importance of this
topic on various TeX conferences; two of these talks are even
published in books.
Recently, I installed dvi2xx (actually, dviljk). I printed *one*
page. On the first look I could see that dvilj does not do the
interword letter placement correctly. There are gaps between letters
or letters that almost run into each other within words! Nobody
seems to care, at least I have never ever read any complaint on c.t.t.
I'll tell you, I'm sad that I put so much effort in this
committee, it would have been spent better for other things. TeX
users don't care for high-quality anyhow, as long as it looks good on
a shiny surface, it's enough. (I'm even more frustrated as this
sounds.)
So my bottom point is: We should not really expect that people will
have a look at any document we publish. In the DVI Driver Committee
I was willing to go to compromises ``because it won't be used
otherwise.'' Well, I should have insisted on a really clear
solution, it isn't used anyhow. This way, I would have a document
today we could be proud of, not this fuzzy thing that was produced then.
Enough gripes, back to my normal work. ;-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 13:04:51 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0quOGR-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 10 Oct 94 18:11 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
>So my bottom point is: We should not really expect that people will
>have a look at any document we publish.
Looking on the bright side, we do have CTAN representatives, and I
expect that most people who keep their systems up-to-date will just
end up using whatever comes of CTAN.
Saying:
>I was willing to go to compromises ``because it won't be used
>otherwise.'' Well, I should have insisted on a really clear
>solution, it isn't used anyhow.
is rather pessimistic... `nobody's going to use TDS so why bother'.
TeX is a lot more centralized than it was a few years ago. There's
now a central maintained source of TeXware, and a maintained LaTeX.
This makes a lot of difference.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 14:37:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 10 Oct 1994 15:33:48 -0400
Message-ID: <199410101933.PAA09188@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <199410101301.OAA20363@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 10 October 1994 at 14:01:45, Joachim Schrod wrote:
> Where was the ftp site with the most current draft? I looked at
> jasper.ora.com, but couldn't find it there.
>
> Norm, any chance to make a new version soon, without restructuring and
> where just the results of the recent discussion has been merged in?
I'm trying to get it done today...
> PS: This is the third WG on TDS I'm in. The last two prepared early
> proposals (that looked very similar) and when it came to the
> nitty-gritty details that were still inconsistent in this proposal the
> work dropped. I still hope it will be better this time... :-(
Me too.
> PPS: I still wait for some input on my questions I sent around.
For the most part, I was in favor of your suggested answers to your
questions. I didn't bother to reply since it'll be in the new draft
and we can all start arguing again from there ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 16:13:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Mon, 10 Oct 1994 17:09:43 -0400
Message-ID: <199410102109.RAA09426@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <199410101301.OAA20363@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 10 October 1994 at 14:01:45, Joachim Schrod wrote:
> Where was the ftp site with the most current draft? I looked at
> jasper.ora.com, but couldn't find it there.
It's on jasper.ora.com in /private/twg-tds
You can grab tds-spec.ps.gz if you want the PS file or tds-spec.dvi
for the DVI file. You'll need all the .tex and .sty files (plus
verbatim.sty and alltt.sty) if you want to TeX it yourself.
> Norm, any chance to make a new version soon, without restructuring and
> where just the results of the recent discussion has been merged in?
I think that that's what I've done. It's still very rough and I'm mostly
interested in whether or not I've left anything out. As soon as everything
is in there, I'll start working on cleaning it up.
Sorry this has taken so long. I've had lots of other priorities. And
I was very disheartened by the reaction to selecting fonts/source.
Hopefully my spirits will hold up better from now through the end... ;-)
Cheers,
norm
P.S. I think there are only three things that I haven't addressed in
the document that were explicitly mentioned recently:
1) Putting texinfo under plain. I'm not convinced that that's a good
idea yet. It seems to violate everything we've been working towards
without any good reason.
2) I didn't mention that a compiled base should included the modes.mf
specials. There's not really a good place for that yet. I think we'll
need a "how to build a distributable, executable TDS hierarchy" section.
3) I didn't mention that fonts/public/logo became fonts/public/mflogo.
I don't know where to say it.
And have we decided what to do with the 'source' name, anyway? Last
time around there was some feeling that 'public' was denigrating and
maybe we needed to be more liberal with names at that level. Thoughts?
P.P.S.
I added a first mention of the 'generic' directory. I think we need
to construct a real TDS skeleton soon, showing where all the standard
files go.
What's the feeling on default search paths for formats:
plain -> tex/plain tex/generic
latex -> tex/latex tex/latex209 tex/generic
latex209 -> tex/latex209 tex/generic
amstex -> tex/amstex tex/plain tex/generic
.
.
.
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Oct 1994 19:01:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 10 Oct 1994 17:01:35 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410110001.RAA14013@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> I was very disheartened by the reaction to selecting fonts/source.
It's like "the media." Good news doesn't sell. There are many
of us who have been somewhat reprehensibly silent about our huge
feelings of relief at this decision. I don't think I would have
undertaken the conversion if the decision had gone the other way.
For a font-junkie's environment, only the fonts/source approach
works.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 05:51:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Oct 1994 06:50:47 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410111050.AA24324@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
I don't see anything wrong with having filenames in distributions
that are longer than 8.3, as long as they are unique in 8.3.
As for who decides what's a problem -- whoever notices should just
email the maintainer, it seems to me. What Joachim is already doing :-)
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 06:17:00 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
Date: Tue, 11 Oct 1994 11:46:07 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:008110:941011104635"@cl.cam.ac.uk>
great, many thanks. will study at leisure and get back to you if i
hate any of it
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 07:17:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Oct 94 12:29:14 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410111129.AA02736@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen directory
Karl
> I don't see anything wrong with having filenames in distributions
> that are longer than 8.3, as long as they are unique in 8.3.
I wish this were true:-)
The LaTeX distribution does have a few files that are not 8+3
(all of them written by me:-) they cause no end of bother as it means
that if you push the LaTeX distribution onto a CD or MSDOS and then
back on to a real filesystem, it fails to work.
However while the TDS and ctan could probably recommend 8+3 names,
I do not think that we should be deciding filenames. Authors must be
allowed to chose their own names. I think we should give guidelines
stating that 8+3 monocase names are the only portable filenames
but then if authors choose to break those guidelines, so be it.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 08:20:46 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410111320.OAA15288@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Tue, 11 Oct 1994 14:20:39 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> On 10 October 1994 at 14:01:45, Joachim Schrod wrote:
> > Where was the ftp site with the most current draft? I looked at
> > jasper.ora.com, but couldn't find it there.
>
> It's on jasper.ora.com in /private/twg-tds
Thanks, I'm about to fetch it. I'll be on a DANTE meeting at
Thursday and hope to talk with a few folks that do micro
implementations (Atari & Amiga ports, driver development). I'll see
if there's any _new_ input from them.
Btw, thanks that you added the DTD this time. :-)
> I added a first mention of the 'generic' directory. I think we need
> to construct a real TDS skeleton soon, showing where all the standard
> files go.
What do you mean with this? I have a full TDS installation (well,
it's an installation that uses the TDS as I interpret it) and I have
made the platform-independent parts available in archived form on our
ftp server. Archives for the platform-dependent parts will be added
shortly. There is also a `map.lst' file that shows all directories.
What else is needed? A full ls-lR?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 09:40:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Oct 94 15:40:21 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410111440.AA02970@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
Norm,
> It's on jasper.ora.com in /private/twg-tds
Got it thanks (comments coming up later),
> I was very disheartened by the reaction to selecting fonts/source.
Perhaps I was a bit hard on you:-) I do agree that it was time to make
a decision, so no more arguments from me on that score, although
I may have some comments on that part of the draft, it's just printing
now...
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 11:26:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Oct 94 15:46:56 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410111446.AA02973@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> What's the feeling on default search paths for formats:
> plain -> tex/plain tex/generic
> latex -> tex/latex tex/latex209 tex/generic
> latex209 -> tex/latex209 tex/generic
> amstex -> tex/amstex tex/plain tex/generic
here I have (more or less)
latex -> tex/latex tex/generic
latex209 -> tex/latex209 tex/latex tex/generic
That is: all the assorted old style files I put in the standard LaTeX
path under tex/latex. Most of them work with latex anyway. If someone
reports a problem, I move that style to tex/latex209 and then either
get a new one from ctan or update it myself, or tell the user to use
latex209, depending on how much time I have.
I think this layout is better as it makes the latex209 area much
smaller (and earmarked for deletion:-)
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 12:20:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Tue, 11 Oct 1994 13:17:31 -0400
Message-ID: <199410111717.NAA12426@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <199410111320.OAA15288@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 11 October 1994 at 14:20:39, Joachim Schrod wrote:
> > I added a first mention of the 'generic' directory. I think we need
> > to construct a real TDS skeleton soon, showing where all the standard
> > files go.
>
> What do you mean with this? I have a full TDS installation (well,
I mean that I need to incorporate your map.lst file into the documentation ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 12:21:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: norm@ora.com (Norman Walsh)
Date: Tue, 11 Oct 1994 13:18:31 -0400
Message-ID: <199410111718.NAA12434@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <9410111446.AA02973@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 11 October 1994 at 15:46:56, David Carlisle wrote:
> here I have (more or less)
>
> latex -> tex/latex tex/generic
> latex209 -> tex/latex209 tex/latex tex/generic
>
> That is: all the assorted old style files I put in the standard LaTeX
> path under tex/latex. Most of them work with latex anyway. If someone
> reports a problem, I move that style to tex/latex209 and then either
> get a new one from ctan or update it myself, or tell the user to use
> latex209, depending on how much time I have.
>
> I think this layout is better as it makes the latex209 area much
> smaller (and earmarked for deletion:-)
Good point!
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Oct 1994 15:15:19 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 11 Oct 1994 13:15:21 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410112015.NAA27267@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
latex -> tex/latex tex/generic
latex209 -> tex/latex209 tex/latex tex/generic
I like that arrangement. I also cut down the latex209 to the bare minimum
and I find that the vast majority of the official latex2e packages seems
to work safely with latex209 if necessary.
Since latex209 is an executable script that sets up its own environment
anyway, it is no trouble at all to prioritize search paths.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 05:24:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 11:24:54 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121024.AA29572@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
OK some comments on the draft.
> <para>
> To avoid different implementations having different syntaxes for
> specifying recursive subdirectory searching, the TWG recommends
> that subdirectory searching be specified by a doubled
> directory separator. For example, the Unix-style pathname
> <filename role=dir>/a/b//</>
> would recursively search all directories under
> <filename role=dir>/a/b</>; likewise for
> <filename role=dir>c:\a\b\\</> under MS-DOS.
> </para>
I have no real objection to standardising on TEXINPUTS notation, but I
am not sure what advantages it has. I am hardly likely to want to
convert my .profile to anything emtex will ever read am I?
However my real concern with this paragraph is that it does not
recommend or even mention the fonts//tfm notion of recursive
searching. If we are prepared to mandate fonts/source then we
really must be prepared to recommend that implementations support some
kind of search pruning like this. I do not believe that one could
seriously claim that a TeX with only the `simple' recursive searching
mentioned in the quote can support the TDS.
> <para>
> This feature is already supported by the <emphasis>Web2C</> distributions of
> &TeX; (available for UNIX workstations and ported to MS-DOS, OS/2,
> Windows-NT, Macintosh, NeXT, and other systems) and the <emphasis>em&TeX;</>
> distribution for MS-DOS and OS/2 (although em&TeX; uses a slightly different
> syntax for specifying recursive subdirectory searching).
> </para>
If the earlier paragraph is changed as I suggested, this paragraph
would need changing. emtex does not currently support a version of
recursive directory searching powerful enough to support the TDS.
> <para>
> The most troubling limitation is monocase names because &LaTeX;
> uses mixed case names for font descriptor files. However, this
> problem is surmountable.
Half a dozen lines inserted in texsys.cfg would remove this problem
(and the longtable.sty 8+3 problem). Just needs to redefine
\input@path. texsys.cfg and \input@path are just there for this kind
of thing. (The default versions are empty and undefined respectively).
Of course the symbolic link solution you mention would be faster as it
would save LaTeX doing the lowercasing. However having LaTeX do it isnt
too slow as long as most files do not have this problem, LaTeX would
try to open the original filename, the new code doing the
lowercase/truncation would patch into the code just before the
`missing file' error was raised, and would have no effect on speed if
it wasnt used.
[ I havent actually got these `half dozen lines' to hand, but I
could commission Alan Jeffrey to produce them if required:-]
> <para>
> Awareness of the fact that storing all of the &TeX; files (including
> system-dependent files such as binaries) under a single tree can be very
> useful, has resulted in a few extension within the &tds; to allow these
> files to coexist.
> </para>
Perhaps
... resulted in a few extensions to the basic &tds; ...
would be clearer.
> ><term>bin/<replaceable>system</></>
Perhaps somewhere in this chapter there should be a note on
`conventions' That define explicitly what you mean by <term> and
<replaceable> (You could couch it in terms of the typefaces used in
the printed form, but perhaps that would break the purity of your SGML
:-)
> <filename role=dir>plain</>, <filename role=dir>latex209</>,
> <filename role=dir>amstex</>, <filename role=dir>texinfo</>,
> <filename role=dir>latex</>, and <filename role=dir>musictex</> are
> examples of <emphasis>format</>.
musictex and texinfo are often (usually?) not actually built as
formats. Especially musictex, which works, just about, with LaTeX.
Here you are only trying to give helpful examples, perhaps best just
to delete such marginal cases here, so that it is clear what a format
is. (Even if in fact we do end up suggesting that these packages are
classed as formats.)
For slightly different reasons I am also not sure about the prominence
LaTeX209 gets here and in one or two other places. Sites probably will
want to keep parallel installations of old versions of formats, and we
could point out that the TDS is compatible with this sensible
precaution. But the status of LaTeX is not special here, you might
want to keep old versions of texinfo or musictex, if that be a
format, or anything else.
> <variablelist>
> <varlistentry><term>source</>
> <listitem><para>
> is the name of the font vendor or ``<filename role=dir>public</>'' for
Shouldn't source and the other list entries be <replaceable> ie italic
in the dvi file?
> <para>
> The most heated debate among the members of the committee revolved around
> the font directory layout. Several members of the committe feel strongly
> that the layout should be:
> </para>
I think that should be
... Several members of the committee felt strongly that the layout
should have been:
The version you have is actually more correct, but I think that if I'm
puting my name to a joint report then I have to go with the decision.
So this phrase, as far as a public document is concerned, should be in
past tense. It may yet prove that we were right, and that the TDS is
not implementable, or at least wont be implemented, by any system other
than web2c TeX. In that case, perhaps this issue may have to be
re-opened, but for now it is closed.
> <para>
> <filename role=dir>texmf/fonts/</><emphasis>type</><filename
> role=dir>/</><emphasis>typeface</><filename
> role=dir>/</><emphasis>typeface</><filename role=dir>/</>
> </para>
I don't recall ever suggesting typeface/typeface.
Also, <emphasis>What happened to the logical markup</> :-)
The rest of that section purports to be a summary of the arguments for
and against fonts/source. I have serious reservations about the whole
of that text, but I will save those to a later message, once I have
thought what I want to say. Just one thing now:
> <para>
> The arguments
> in favor of <emphasis>fonts/source</> go something like this:
> </para>
> <para>
> The arguments
> in favor of <emphasis>fonts/source</> go something like this:
> </para>
These two <para> seem suspiciously similar...
> and documentation about &BibTeX;
> should be stored in <filename role=dir>doc/bibtex</>.
> </para>
I think it would be clearer if you said documentation about
<replaceable>utilities</> such as &BibTeX; should be...
I read your document first as some unique privliged position for
BibTeX, which I am sure is not what was intended.
> martian-1.0/tex/latex/martian/martian.sty
> martian-1.0/tex/latex/martian/OT1mart.fd
According to the earlier section, this should be
martian-1.0/tex/latex/contrib/martian/martian.sty
martian-1.0/tex/latex/contrib/martian/OT1mart.fd
Does it matter that this makes the canonical ctan pathname for
martian.sty
/tex-archive/macros/latex/contrib/supported/
martian-1.0/tex/latex/contrib/martian/martian.sty
Which is quite long:-)
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 08:19:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121154.MAA13204@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 12:54:19 +0100 (MEZ)
Content-Type: text
David wrote:
>
> According to the earlier section, this should be
>
> martian-1.0/tex/latex/contrib/martian/martian.sty
> martian-1.0/tex/latex/contrib/martian/OT1mart.fd
>
> Does it matter that this makes the canonical ctan pathname for
> martian.sty
>
> /tex-archive/macros/latex/contrib/supported/
> martian-1.0/tex/latex/contrib/martian/martian.sty
I didn't understand it that way. I thought the CTAN structure would
be
/tex-archive/macros/latex/contrib/supported/martian-1.0/martian.dtx
README
MANIFEST
martian.ins
etc., where the README tells that the files created by martian.ins
shall be installed in texmf/tex/latex/contrib/martian/.
As an example, take the installation of the ssqquote bundle I did
yesterday. The archive list names
./tex/latex/contrib/ssqquote/ssqquote.sty
./tex/latex/contrib/ssqquote/T1cmssq.fd
./tex/latex/contrib/ssqquote/OT1cmssq.fd
./doc/latex-styles/ssqquote.dvi
as the installed data files of this bundle. On CTAN these files do
not even exist.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 08:25:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 14:25:51 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121325.AA29907@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
Joachim
> I didn't understand it that way. I thought the CTAN structure would
> be
>
> /tex-archive/macros/latex/contrib/supported/martian-1.0/martian.dtx
> README
> MANIFEST
> martian.ins
>
> etc., where the README tells that the files created by martian.ins
> shall be installed in texmf/tex/latex/contrib/martian/.
Yes I think that was really my question. Your suggestion looks better
from a ctan structure point of view, but I do not think that you can
actually take a literal reading of
> We encourage package authors to build their distribution archives in
> a structure that parallels the &tds;.
to mean this, can you?
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 08:29:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv3jb-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 14:28 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
>I didn't understand it that way. I thought the CTAN structure would
>be
>/tex-archive/macros/latex/contrib/supported/martian-1.0/martian.dtx
> README
> MANIFEST
> martian.ins
>etc., where the README tells that the files created by martian.ins
>shall be installed in texmf/tex/latex/contrib/martian/.
This is OK for packages which don't have fonts, but packages with
fonts either have a flat distribution like:
.../martian/martian.dtx
/mart10.mf
/mart10.tfm
/mart10.300pk
or some structure like:
.../martian/doc/martian.dtx
/mf/mart10.mf
/tfm/mart10.tfm
/dpi300/mart10.300pk
with instructions on how to unpack it all and where to put everything.
But this distribution mixes up stuff from the fonts, doc and tex
heirachies, and if you want a directory structure which mimics TDS you
end up with something like David's structure.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 08:43:45 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv3wy-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 14:42 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
On the topic of // syntax, I got this from EM:
HOWEVER, the syntax for pruning isn't unambigous under OS/2 and
MS-DOS: // (or \\) has a special meaning for accessing network
servers by name, therefore I prefer not to implement pruning with
that syntax. (I think Apollo Unix has something similar.)
Fortunately, // (and \\) are handled specially only at the very
beginning of a path name, for instance:
\\server\directory\file
That is, it's technically possible to specify pruning with //, but
it will confuse users.
So I vote for no recommendation for syntax, just semantics...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 09:03:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 15:01:43 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00985D6A.A2A0A11F.14522@linac.ikp.physik.th-darmstadt.de>
Subject: Alternate suggestion for LaTeX directory trees.
David Carlile wrote:
>> What's the feeling on default search paths for formats:
>
>> plain -> tex/plain tex/generic
>> latex -> tex/latex tex/latex209 tex/generic
>> latex209 -> tex/latex209 tex/generic
>> amstex -> tex/amstex tex/plain tex/generic
>
>here I have (more or less)
>
>latex -> tex/latex tex/generic
>latex209 -> tex/latex209 tex/latex tex/generic
>
>That is: all the assorted old style files I put in the standard LaTeX
>path under tex/latex. Most of them work with latex anyway. If someone
>reports a problem, I move that style to tex/latex209 and then either
>get a new one from ctan or update it myself, or tell the user to use
>latex209, depending on how much time I have.
>
>I think this layout is better as it makes the latex209 area much
>smaller (and earmarked for deletion:-)
I want to suggest a more diversivied LaTeX (2e versus 209) directory
structure that I have implemented on my (VMS) system:
tex/latex// : Holds the LaTeX2e distribution files; and contains all
contributions to LaTeX (2e) that do not work with 2.09
(Many contribution styles start with
"\NeedsTeXFormat{LaTeX2e}")
tex/latexgen// : Holds contributions that do explicitely work (have been
designed to work) with both new and old (2.09) LaTeX.
Some examples are ulem.sty and the different "*cite*"
enhancement styles from D. Arsenau.
tex/latex209// : Contains LaTeX 2.09 distribution and obsolete contributions
(that do not work with 2e, or have been superseeded with
a `LaTeX2e-only' replacement.)
tex/ltxunsup// : Contains "the rest" of LaTeX contribution styles.
This directory tree carries all old (unsupported) LaTeX 2.09
styles that may work with LaTeX2e (but compatibility has
not been explicitely prooved). The contents of this
tree will gradually disappear, as more style contributions
are getting updated to comply with LaTeX2e.
An example: ltxunsup is the right location for the old
AMSLaTeX distribution that does not (fully) work with LaTeX2e,
but is needed as amendment to the temporary 2e patches
of AMSLaTeX.
Search paths using this directory setup would be:
LaTeX2e: tex/latex// tex/latexgen// tex/ltxunsup// <other (nonLaTeX) dirs>
LaTeX209: tex/latex209// tex/latexgen// tex/ltxunsup// <other (nonLaTeX) dirs>
The advantage of this arrangement is the clean separation of the huge set
of LaTeX contribution styles into different categories of support for
old and new LaTeX.
The main disadvantage can be seen in that this arrangement partially breaks
the tex/<format>/<package> law.
Regards,
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 09:10:16 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv4M5-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 15:08 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: draft document
Some stuff on the arguments for and against fonts/source.
As may be expected, I'm not too happy about this bit of the
document...
Separating files by typeface is a logical way to organize the tree.
We have organized other parts of the &tds; by high-level concept (typeface
being roughly analagous to format).
This should be `source being roughly analagous to format' since
<source> and <format> are at the same level. At which point the
analogy breaks down of course, because (eg) the AMS's files are
scattered through the tex heirachy, in tex/amstex, tex/latex/amslatex,
tex/latex/fd, etc. etc. But anyway...
In an unoptimized system, yes. But very reliable sources have indicated
that even if you don't search the <filename>PK</>s you won't like the
performance
of an unoptimized system.
Could we please tone this down. I run OzTeX with
TDS-except-fonts/type every day, and performance is fine. It should
at least say something like `on very large systems with thousands of
fonts' (OzTeX is fine with 7M worth of fonts folder containing 1700
files).
And if we're going to cite `very reliable sources' then we should name
names. Citing anonymously is not exactly best practice...
And your DVI driver has to look at all these
files too, so if you don't have some optimization; you're doomed.
Many DVI drivers perform this optimization by performing pruning based
on dpi value, eg only searching for */300/cmr10.pk.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 09:10:35 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
Date: Wed, 12 Oct 1994 15:10:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:084860:941012141037"@cl.cam.ac.uk>
I think Christian's setup is contrary to the spirit of the TDS :-}
Lets not put LaTeX on such a pedestal that it distorts the
concept. Duringg the latex2e/209 mess, maybe in practice people should
break the TDS, but lets not enshrine it in a long term proposal
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 09:14:38 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv4Ps-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 15:12 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Alternate suggestion for LaTeX directory trees.
>I want to suggest a more diversivied LaTeX (2e versus 209) directory
>structure that I have implemented on my (VMS) system:
I disagree. LaTeX 2.09 is obsolete software. The only reason for
having latex209 at all is for large sites where running old documents
is very important. Splitting the directories like this makes it looks
like 2.09 is still supported. It isn't.
Perhaps we should call the latex209 directory
`latex209oldobsoletedontuseit' but that's not 9660 compliant...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 09:16:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 15:16:41 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121416.AA29948@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Alternate suggestion for LaTeX directory trees.
> I want to suggest a more diversivied LaTeX (2e versus 209) directory
This is an example of what I meant in my last message about (not)
giving 209 prominence in the TDS draft.
Christian's layout looks perfectly sensible for a site that intends
running 209 and 2e with more or less equal status, my layout is
simpler for a site where essentially no one uses 209 unless there is a
particular problem. (It is not that they are all converted to `The
Way' they just all use which ever version is called `latex', which
since last month has been 2e:-)
How a site deals with issues of maintaining old software should be
left to that site. I think that virtually all reference to 209 should
be deleted, and instead a suggestion that `format' may include
older versions of formats, or (perhaps also as Christian suggests,
`composite-formats' for files that may be run under a pair of
formats). In this one section latex209 could be given as an important
example of such an old format.
David
PS
should Christian be in the footnote of page 1 ?
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 10:37:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 16:36:02 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00985D77.CF68F0FF.14588@linac.ikp.physik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
David Carlisle (sorry for my mis-spelling of your name the first time)
answered:
>This is an example of what I meant in my last message about (not)
>giving 209 prominence in the TDS draft.
>
> [...]
>
>How a site deals with issues of maintaining old software should be
>left to that site. I think that virtually all reference to 209 should
>be deleted, and instead a suggestion that `format' may include
>older versions of formats, or (perhaps also as Christian suggests,
>`composite-formats' for files that may be run under a pair of
>formats). In this one section latex209 could be given as an important
>example of such an old format.
>
>David
Ok, I do agree with this opinion. The TDS-standard document is not
the right platform to discuss such specific items like how to set up
coexisting versions of LaTeX.
But a general remark should remain there. One of the goals of TDS is
that it allows to hold obsolete TeX macro packages in a consistent
manner.
>PS
>
>should Christian be in the footnote of page 1 ?
No!
I did not really contribute to the committee.
And, more important, I do not agree with all of their decisions.
I will definitely NOT propagate the /fonts/sources/... setup for TeX
on VMS, but rather use something like the /fonts/type/... alternative.
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:00:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121600.RAA18613@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 17:00:02 +0100 (MEZ)
Content-Type: text
> I will definitely NOT propagate the /fonts/sources/... setup for TeX
> on VMS, but rather use something like the /fonts/type/... alternative.
>
> Christian Spieler
Remember what I wrote about acceptance of the TDS paper...
Christian, where do you put the Computer Modern test files in your
distribution? They are (a) part of the Computer Modern fonts, (b)
not part of the MF sources, (c) not part of the documentation, and
(d) neither TFM nor PK or any other common <type>. Do you invent a
new <type> named "test"? A rather strange font type name, isn't it?
Joachim
PS: If really everybody (up to now the LaTeX team and Christian) says
that they won't use or recommend fonts/sources in their distribution,
we can state the facts in the TDS document: That TDS will most
likely be fonts/type for tradition reasons and that the Unix freaks
and font junkies will use fonts/sources because it suits their needs
better and is supported by their TeX port.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:02:04 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121601.RAA18626@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 17:01:58 +0100 (MEZ)
Content-Type: text
David wrote:
>
> I do not think that you can
> actually take a literal reading of
>
> > We encourage package authors to build their distribution archives in
> > a structure that parallels the &tds;.
>
> to mean this, can you?
You're right, this sentence should be discarded. (I haven't yet read
the new draft in detail; I'm about to leave for the DANTE meeting in
five minutes...)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:04:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121604.RAA22473@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 17:04:19 +0100 (MEZ)
Content-Type: text
You wrote:
>
> This is OK for packages which don't have fonts, but packages with
> fonts either have a flat distribution like:
>
> .../martian/martian.dtx
> /mart10.mf
> /mart10.tfm
> /mart10.300pk
>
> or some structure like:
>
> .../martian/doc/martian.dtx
> /mf/mart10.mf
> /tfm/mart10.tfm
> /dpi300/mart10.300pk
>
> with instructions on how to unpack it all and where to put everything.
> But this distribution mixes up stuff from the fonts, doc and tex
> heirachies,
I don't find this a problem as long as the installation instructions
clearly tell where to put the different parts. IMO the organisation
of a distribution is something along the transition path between a
development organisation and an end-user organisation.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:19:23 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv6N0-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 17:17 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
>PS: If really everybody (up to now the LaTeX team and Christian) says
And Bob.
>that they won't use or recommend fonts/sources in their distribution,
>we can state the facts in the TDS document: That TDS will most
>likely be fonts/type for tradition reasons and that the Unix freaks
>and font junkies will use fonts/sources because it suits their needs
>better and is supported by their TeX port.
So we'll end up with no standard at all. Even fonts/source is better
than having both.
Let's just wait to see what the implementors say.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:23:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 17:23:53 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121623.AA00313@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> > or some structure like:
> >
> > .../martian/doc/martian.dtx
> > /mf/mart10.mf
> > /tfm/mart10.tfm
> > /dpi300/mart10.300pk
> >
> > with instructions on how to unpack it all and where to put everything.
> > But this distribution mixes up stuff from the fonts, doc and tex
> > heirachies,
>
> I don't find this a problem as long as the installation instructions
> clearly tell where to put the different parts.
Working on the reliable principle that ctan can do anything, one could
imagine that the ctan interface could allow
cd macros/latex/contrib
get martian-tds.zip
where the -tds.zip suffix means make me a zip file that will unpack
into an existing tds tree.
Or perhaps not?
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:45:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121645.RAA18463@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 17:45:05 +0100 (MEZ)
Content-Type: text
Alan wrote:
>
> >PS: If really everybody (up to now the LaTeX team and Christian) says
>
> And Bob.
> [...]
> Let's just wait to see what the implementors say.
I wrote it in a private mail and repeat it in public: I don't expect
that any implementor will react positively to these questions. They
are much too demanding, no implementor likes this. (I understand
this, I wouldn't react positively either without the background of
this discussion. If somebody just asks me to implement something and
doesn't give me any convincing reason why, I typically say ``well,
I'll put it on the TODO list and do it in my copious spare time...'')
That was the reason why I begged to add the question if they would
use an existing POSIX.1 based implementation (which then was not
incorporated).
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:47:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 17:46:23 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00985D81.A363365F.14662@linac.ikp.physik.th-darmstadt.de>
Subject: Sample TDS installation at Darmstadt FTP server
Joachim asked if he should supply a "ls-R" file, recently.
I would like to have something like that in addition to the "map" file
of the directory layout.
This way I could study his decisions on where to locate specific files,
without having to fetch the tar archives. In some cases, there are
different possible solutions, and I would like to have some guidance in
these cases.
Thank you
Christian
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 11:58:46 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qv6yL-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 12 Oct 94 17:56 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
>> Let's just wait to see what the implementors say.
>That was the reason why I begged to add the question if they would
>use an existing POSIX.1 based implementation (which then was not
>incorporated).
I tried phrasing a question which said this, but any way I typed it,
the thing was horribly clumsy and complicated. I asked the simplest
questions I thought would get the information we needed.
Although if Joachim's response is anything to go by I may as well not
have bothered, since it looks like he's all set to ignore whatever the
implementors have to say...
Alan.
PS: And I was actually meaning `what the implementors have to say
after we've sent them the TDS draft'.
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 12:03:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 18:03:12 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121703.AA00392@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Latest draft
5.1 Is There a Better way
=========================
The first paragragraph, modulo the typeface/typeface typo, and the
present tense clause mentioned last message is a reasonable summary of
the situation.
The structure of the rest of the section, two enumerated lists of
arguments, suggests that it is designed to give the two sides of the
argument that led to the disagreement mentioned in the first
paragraph. It does not do this. The arguments for fonts/type are
parodied, then ridiculed: `this argument ... doesn't hold water'.
I would suggest that either the whole section be re-written, or
perhaps more simply just be removed if a suitable wording can not be
agreed.
In case we decide to go for a re-wording here are some comments on the
existing draft.
>
> <para>The arguments
> in favor of <emphasis>fonts/source</> go something like this:
> </para>
>
> <orderedlist>
> <listitem><para>
> <emphasis>fonts/source</> wins on modularity and maintainability
> </para></listitem>
Modularity yes, maintainability dubious, but I'd let that pass.
> <listitem><para>
> <emphasis>fonts/source</> is more logical
> </para>
> <para>
> Separating files by typeface is a logical way to organize the tree.
> We have organized other parts of the &tds; by high-level concept (typeface
> being roughly analagous to format).
> </para></listitem>
How anyone can see typeface ~ format is beyond me.
Also in the section Macros, the first benefit of having a top level
format directory is given as:
By providing a format directory, subdirectory searching can be
limited to only those directories that contain relevant files.
Which would indicate that format is analagous to *type* as, for fonts
it is on *type* that you want to base any searching.
> <listitem><para>
> <emphasis>fonts/source</> requires searching all the PK files
> </para>
> <para>
> In an unoptimized system, yes. But very reliable sources have indicated
> that even if you don't search the <filename>PK</>s you won't like the
> performance
> of an unoptimized system. And your DVI driver has to look at all these
> files too, so if you don't have some optimization; you're doomed.
> (yes, you TeX more often than you use a driver---but not much more often).
> </para>
As these `very reliable sources' are Karl and Joachim that phrase
should just be deleted. It is not that they are not reliable, but in a
public document you can not refer to members of the committee in this
way.
The second comment about the relative number of times you use a driver
as opposed to using TeX is just irrelevant. fonts/source causes more
searching for both the driver and TeX thus slowing down both (or
neither in this yet-to-be-seen optimised system)
> <para>
> This argument against <emphasis>fonts/source</> doesn't hold water.
> </para></listitem>
This phrase should be deleted from a public document.
> </orderedlist>
>
> <para>
> The arguments
> in favor of <emphasis>fonts/source</> go something like this:
> </para>
I assume a typo for fonts/type ?
> <orderedlist>
> <listitem><para>
> Most platforms can use fonts/type
> </para>
> <para>
> There are only four implementations that can
> do subdirectory searching <emphasis>at all</> so the reality is most
> implementations can't use the TDS without some modifications.
> </para>
Saying `only four' makes this sound like a tiny minority. Probably it
could be `only two' and still cover a majority of TeX users. The only
machine architecture for which there is a large TeX userbase but no
such implementation is VMS I think?
> <para>
> Of those four systems, one includes optimizations that make the TDS
> practical for large numbers of fonts, two don't, and one only works
> with fonts/type. Hardly a strong case for any particular organization.
> </para></listitem>
As Alan has said many times this is only true if you have hundreds of
font families. He uses oztex with fonts/type all the time. Many
thousands of people have used TeX's with this kind of searching.
Just because kpathsea now has a database system you can not argue that
previous versions of Tex were not useable.
> <listitem><para>
> <emphasis>fonts/type</> allows the user to specify different search paths
> for different
> sorts of files (search the /tfm directory for tfms, the /vf directory for
> vfs, etc.)
> </para></listitem>
>
> <listitem><para>
> <emphasis>fonts/type</> is more logical
> </para>
> <para>
> Separating files by type is a logical way to organize the tree. We
> have chosen that methodology for some types of files.
> </para></listitem>
> </orderedlist>
>
No objection.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 12:06:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 17:22:57 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Message-ID: <01HI73E2BL9E94EEU6@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I don't see a real problem in the test files coming with the Computer
Modern fonts. They are (for me) rather clearly METAFONT input files,
allthough they don't contain a font description but rather test programmes.
They are closely tied to cmbase and the specific style of coding of the cm
fonts, not generic programmes.
So they are placed under tex_root:[mf.cm.test].
--J"org Knappen
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 12:12:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410121637.RAA22295@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 12 Oct 1994 17:37:33 +0100 (MEZ)
Content-Type: text
David wrote:
>
> Working on the reliable principle that ctan can do anything, one could
> imagine that the ctan interface could allow
>
> cd macros/latex/contrib
> get martian-tds.zip
>
> where the -tds.zip suffix means make me a zip file that will unpack
> into an existing tds tree.
No, if you look at the typical LaTeX2e distribution, it does not have
the file that are installed. They are created during installation.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 12:12:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 17:37:07 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00985D80.57D7B95F.14656@linac.ikp.physik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
>Christian, where do you put the Computer Modern test files in your
>distribution? They are (a) part of the Computer Modern fonts, (b)
>not part of the MF sources, (c) not part of the documentation, and
>(d) neither TFM nor PK or any other common <type>. Do you invent a
>new <type> named "test"? A rather strange font type name, isn't it?
>
> Joachim
>
Just a quick answer:
Currently, all MF input files are rooted under TEX_ROOT:[FONTS.MF...].
The directory tree setup there is in large parts an unchanged copy
of the 1990 DECUS TeX CD. Different font families are in different
subdirectories.
The basic Knuth files (plain.mf, plain.mft, miscellanous fonts
for MF/TeXbook(manfont, logo) and MF developement (gray)), as well
as modes.mf, are in TEX_ROOT:[FONTS.MF.STANDARD].
All CM related files, including the font test macros, are in
TEX_ROOT:[FONTS.MF.CM.STANDARD], as a copy of the Knuth standard
distribution.
But this setup is not fixed...
In fact, the current setup is not TDS compliant, it only uses some
of the basic ideas. But I am gradually changing it to get closer to
the TDS draft ...
A more detailed explanation on the planned future of VMS TeX follows
in a separate message.
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 12:21:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 94 18:21:22 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410121721.AA00441@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> No, if you look at the typical LaTeX2e distribution, it does not have
> the file that are installed. They are created during installation.
True, and this is actually a general problem, where to put the dtx
files. under doc seems the obvious place (so they could be
automatically directed there, but I dont trust automation much:-)
================================================================================
From owner-twg-tds@shsu.edu Wed, 12 Oct 1994 13:47:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 12 Oct 1994 19:15:02 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00985D8E.05A6BC9F.14644@linac.ikp.physik.th-darmstadt.de>
Subject: Future of DECUS TeX (VMS Public Domain TeX) and the TDS
Hello,
I want to give some explanation to my statement that fonts/source/..
will not be recommended(/supported) on VMS, at least not in the
near future.
There is currently some effort to develop a new "standard" TeX distribution
for VMS. For this work, I have a very excited voluntaring contributer,
Ralf Gaertner. The main work is done in improving the documentation and
in creating a standardised installation guide. For this distribution,
we want to use a rooted directory tree for TeX macro packages, and
the font support files should be grouped into subdirectories as well.
To archive this, I have used the ideas of the TDS group as guide.
I plan to support simple multilevel subdirectory searching with the core TeX
and Metafont programs for this release. The implemented syntax will be the
same as used by other VMS utilities that support wildcards, aka:
"TEX_ROOT:[INPUT.LATEX...]"
This approach can be implemented quite easily, there is only a call to
a VMS system service needed to expand the wildcard expression.
But, as this approach uses the VMS built in wildcard support, there is
no way to specify something like "/tex/fonts//tfm/".
Currently, there are no plans to write a private subdir search library
that implements more advanced features. My time resources are limited,
and I do not want to stay with TeX developement all the time.
We do not plan to convert to fonts/sources/type/.. because of the following
reasons:
1.) A logical approach to sort the TeX/MF files is the distinction by
"file format". In this approach, the different "formats" are:
- TeX input files (containing TeX language text)
- TFM files (containing Font metric information)
- VF files (containing virtual fonts information)
- Format files (containing precompiled TeX macros)
- MF input files (containing MF language text)
- Base files (containing precompiled MF macros)
- PK files (containing Font raster informations)
- AFM ...
- etc.
In general, all these formats are stored under their own top
level directory.
This approach is in some aspects inspired by the TeX and MF programs
themselves, since they both use different search paths for the different
"file formats".
2.) The type/source approach allows to use the subdirectory wildcard mechanism
described above. When the tfm path is specified as
"define TEX_FONTS TEX_ROOT:[FONTS.TFM...]",
only .tfm files are searched by the OS system routines.
On VMS, there is the advantage that the search path logical names
can be used with some other VMS program totally unrelated to TeX.
(examples: DIRECTORY, BACKUP) (However, some programs do not support
wildcarded filenames; these do not work with "TEX_ROOT:[FONTS.TFM...]"
and similar specifications.)
For example, I want the DIR command to only find TeX Font Metric files
when applying "DIR TEX_FONTS:".
This does not work with the /fonts/source/... approach.
3.) The DVI-driver problem:
Whereas it is fairly easy to implement the TDS stucture for TFM, MF,
VF and TeX macros, the PK search path is more probematic.
This arises from the fact, that the DVI driver has to add an additional
directory for the font resolution to the search path. At least some
drivers expand the TEX_PKDIR logical name themselves, and check
the replacement string to decide whether the PK font setup is "rooted"
([.<resolution>]font.pk), or "plain" (font.>resolution>pk). This
technique is not compatible with the "subdir searching" syntax, it
does not even allow to use "search lists".
For this reason, the current PK directory setup is not TDS compliant.
I have to use a single root directory for a given Metafont mode.
I do not know, if this problems gets solved in the foreseeable future.
At this stage, more elaborate developement effort is needed...
Since I have to stay with a "non-TDS" PK area for the moment, the
fonts/type setup has a more consistent appearance (the "non-TDS problem"
appears at a deeper level).
4.) Security reasons:
When MAKETEXPK should be used, the PK directories have to be world
writeable.
I do not like to have world writeable directories scattered all over the
whole font tree.
5.) When <type>/<mode> are top level directories, splitting the PK files
(of different mode, for example) between different devices can be
archived more naturally.
Another possible setup is a twofold PK directory tree: A nonwriteable
system tree containing the mostly used fonts, and a writeable
"user" tree that gets searched after the system tree and hold the
automatically MAKETEXPK generated fonts. (The TeX manager can inspect
the "user" tree and decide which fonts should be move into the
system tree.) This setup can be archived on a fonts/sources/../type/
structure as well, but the fonts/type setup lead to a cleaner solution,
IMHO.
Summary:
The /fonts/type/... approach allows me to gradually convert and test a
running TeX system. To implement /fonts/source/..., all components of a
TeX system have to support (a privately written) subdirectory searching
algorithm.
Remark concerning the DVIdrivers:
The two most popular drivers, DVIPS and XDVI, are available in two
differing distributions:
a) The "OEM" distributions by the original authors do not support a
subdirectory searching sufficient for the TDS structure, but
are portable to many different platforms. They work on VMS
(with no/minimal changes: XDVI; modifications to the command line
interface: DVIPS).
b) The "k" distributions, maintained by Karl Berry, have implemented a
more sophisticated font searching library that is the only available
implementations which fully supports TDS.
Sadly, the non-UNIX support has been (partially ?) broken.
I am not willing to open up a third distribution. Until the original authors
and Karl Berry have not been managed to (partially) rejoin their versions,
I will most probably not look into "kpathsea".
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 03:40:46 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
Date: Thu, 13 Oct 1994 09:40:42 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:021180:941013084049"@cl.cam.ac.uk>
> Working on the reliable principle that ctan can do anything, one could
> imagine that the ctan interface could allow
>
> cd macros/latex/contrib
> get martian-tds.zip
>
> where the -tds.zip suffix means make me a zip file that will unpack
> into an existing tds tree.
well, make it get martian.tds-zip to make it easier, and then the ftp
daemon can handle it. IF someone writes the script to convert from one
tree to another. not beyond the bounds of possibility.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 07:04:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 1994 08:01:23 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410131201.IAA22137@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Latest draft
References: <9410121703.AA00392@r8h.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 12 October 1994 at 18:03:12, David Carlisle wrote:
> The first paragragraph, modulo the typeface/typeface typo, and the
> present tense clause mentioned last message is a reasonable summary of
> the situation.
>
> The structure of the rest of the section, two enumerated lists of
> arguments, suggests that it is designed to give the two sides of the
> argument that led to the disagreement mentioned in the first
> paragraph. It does not do this. The arguments for fonts/type are
> parodied, then ridiculed: `this argument ... doesn't hold water'.
Lest anyone imagine that that was my intent, let me say plainly:
I did not intend it that way. I am still trying to get ideas down
on paper, I may have failed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 07:10:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 1994 08:07:25 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410131207.IAA22167@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <"swan.cl.cam.:021180:941013084049"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 13 October 1994 at 09:40:42, Sebastian Rahtz wrote:
> > Working on the reliable principle that ctan can do anything, one could
> > imagine that the ctan interface could allow
> >
> > cd macros/latex/contrib
> > get martian-tds.zip
> >
> > where the -tds.zip suffix means make me a zip file that will unpack
> > into an existing tds tree.
> well, make it get martian.tds-zip to make it easier, and then the ftp
> daemon can handle it. IF someone writes the script to convert from one
> tree to another. not beyond the bounds of possibility.
As I recall, it's a script that builds the ZIP files so I think
that martian-tds.zip is equally doable (and it doesn't violate the
8.3 rule so dramatically (if n.3 is less evil than n.m, I dunno)).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 08:39:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 1994 09:36:36 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410131336.JAA22502@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Robertson's Rules of Order (or something like that)
Reply-To: TWG-TDS@SHSU.edu
Dear members,
In my heart of hearts, I wish to reopen the can 'o worms regarding
fonts/source versus fonts/type. Since it was closed, I've learned
several things (I should have learned them before I closed it, I
suppose, but c'est la vie):
- The VMS folks aren't going to support fonts/source but plan to use
something like fonts/type. One down.
- The LaTeX team is unwilling to (enthusiastically) endorse it.
Two down.
- Eberhard doesn't seem anxious to support it either (based upon
Alan's posting---though maybe it was only a comment about
syntax). Three down?
- I've tried to use fonts/source on a (slower) system w/o Web2C's
advanced features. It's too painful, even for the patient user.
- It's hard to implement. I'm well aware that kpathsea exists as
an example that it can be done, but that's not going to be enough
for developers; especially under the GPL or LGPL since we have
to think about commercial developers as well.
I thought I'd provide an example of subdir searching (along the
lines of Joachim's suggestion; although I didn't examine it for
POSIX compliance) so I implemented it. It took me about 40 minutes to
implement simple recursive searching. It may not be as robust
enough for "real" use, but it definitely wasn't hard to do. Then I
began to think about implementing restricted recursive searching
and caching and the problem got much harder. I could do it, but I
have to ask what the motivation is. Wearing a developer's hat,
I can easily say "my setup works now, my customers get what I distribute
and it works, so why should I do all this work for the TDS?"
The argument that a cache is required for efficient performance
is compelling, but my experience with a slow PC has made me
re-evaluate my position on this issue. With a fonts/type tree
(and the simple step of only looking for 999dpi/font.pk) I think
that many users would find recursive subdirectory searching performance
acceptable without a cache. I have more than the normal number of
fonts (but not a huge number) and recursive searching over fonts/source
is just a little too slow. It'd probably be ok over fonts/type.
- The arguments in favor of fonts/source on the basis of "logical
organization" are compelling to font hackers but to the average
person, the arguments in favor of fonts/type are probably equally
compelling.
I guess what I'm really saying is that I'm inclined to flip-flop on
the issue of fonts/source vs. fonts/type. My perception of the
situation has changed and I now think that the TDS is unlikely to
succeed if it endorses fonts/source [three unwilling communities
before we even ask the developers isn't a good sign]. Since our real
goal is to create a proposal that will be accepted universally, I
think we have to reevaluate our position.
However, while I felt it was within my prerogative to close an
apparently dead-ended discussion with a decisive statement, I'm less
confident that I have a special power to arbitrarily change that
decision.
I need help. Setting aside your personal feelings about the particular
issue in question, is there a way to approach this situation which is
acceptable to everyone? I think there are a three possibilities:
a) The decision has been made, the issue is closed.
b) The decision has been made, but the chairman can overturn it.
c) The question can be reopened, but it needs to be discussed again.
Hopefully there will now be a consensus.
Sincerely,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 09:09:34 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
Date: Thu, 13 Oct 1994 15:09:25 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:185730:941013140933"@cl.cam.ac.uk>
Poor Norm; all this worry and heartache.
I think the chairman of a volunter group like this can do what the
hell he likes, either to restart the discussion or reverse a
decision.
I say we should vote again, without huge more quantities of
discussion, and see what falls out. I for one promise not to complain.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 09:10:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 94 15:10:12 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410131410.AA04283@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
> a) The decision has been made, the issue is closed.
> b) The decision has been made, but the chairman can overturn it.
> c) The question can be reopened, but it needs to be discussed again.
> Hopefully there will now be a consensus.
As no decision like this is ever final a) seems to be out.
I think b) is probably false.
That leaves c)
I think you might have guessed my personal preference for fonts/type
but I dont feel that I can suggest re-opening this now.
If Karl/Pierre/Joachim feel that they could support a TDS document
proposing fonts/type then that would be ideal.
If not then perhaps we should finish the current draft proposing
fonts/source and send it to the implementers.
The main problem with the latter course of action is that if, as
seems quite probable, it is clear from the implementers response to
the document that fonts/source is a non-starter, that we will lose
a certain amount of good-will towards the whole TDS idea. If we end up
in the end recomending fonts/type anyway, this good-will will have
been lost for no good reason.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 09:47:02 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvRNO-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 13 Oct 94 15:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
I agree with David. Golly jeepers now that is a surprise.
I also agree with Sebastian that Norm can do what he likes (within
reason, where reason is determined by majority vote and lots of
argument :-). If Norm wants the backing of the discussion group, then
we can go for some sort of vote.
I'll append the results of the tex-implementors survey so far. 8
responses, which isn't great. Hey ho.
Alan.
--- cut here for summary ---
CvT W2C OzT TuT AmT SbT Y&Y emT
implemented now: 2 6 3 2 2 2 4 4?
by 1995: 5 6 3 2 * 4 4 4?
if asked by us: 5 6 4 2 6 4 4 5
KEY:
1 = one flat directory
2 = path of flat directories
3 = path with 1-level subdir searching (minimum for fonts/type)
4 = path with n-level subdir searching
5 = ditto with pruning (minimum for fonts/source or big fonts/type)
6 = ditto with cache
* = whatever we ask Tom to do
? = EM's message is rather ambiguous
CvT = Convergent TeX (VMS)
W2C = Web2C (Unix)
OzT = OzTeX (Mac)
TuT = TurboTeX (PC)
AmT = AmigaTeX (Amiga)
SbT = SBTeX (PC)
Y&Y = Y&Y TeX (PC)
emT = emTeX (PC)
Executive summary:
7/8 can support fonts/type by next year
3/8 can support fonts/source by next year
4/8 can support fonts/source if we ask nicely :-)
--- cut here for raw data ---
>From uunet.uu.net!nls!nls.com!davek Fri Oct 7 21:27:27 1994
Date: Fri, 7 Oct 94 13:27:11 PST
From: "David Kellerman" <davek@nls.com>
Subject: RE: TeX directory structures
To: uunet!cogs.susx.ac.uk!alanje@uunet.uu.net
X-VMS-Mail-To: UUCP%"uunet!cogs.susx.ac.uk!alanje"
X-VMS-Mail-CC: DAVEK
NAME: David Kellerman
Northlake Software
EMAIL: kellerman@nls.com
TEX IMPLEMENTATION: Convergent TeX for VMS
This version of TeX currently supports (delete ones which don't apply):
* only one directory for each sort of file (for example, all tfm
files have to be in fonts/tfm)
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
If the TUG technical working group ask us to, we will implement:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
Any other comments:
Please choose a solution that maps cleanly to user environments
I think you ought to make sure whatever structure you choose
maps cleanly onto the user interface already in place in
each of the environments where people will be using it.
I think you get into trouble when you try to reinvent
familiar portions of the user interface -- you end up
working at cross-purposes with what users are already
comfortable with. Every time you educate a new user, you
start with "this is different from what you'd expect," and
every time the user uses the feature, they ask "now how did
that work, it was different from what I'm used to?"
VMS, in particular, has basically two constructions that let
you search multiple directories:
Wildcards
for entire directory names:
[fonts.tfm.*] matches [fonts.tfm.adobe],
[fonts.tfm.monotype], etc.
[fonts.*.times] matches [fonts.tfm_adobe.times],
[fonts.tfm_monotype.times], etc.
for parts of directory names:
[fonts.tfm_*] matches [fonts.tfm_adobe],
[fonts.tfm_monotype], etc.
Ellipses
for an arbitrary sequence of zero or more directory names:
[fonts...times] matches [fonts.times],
[fonts.tfm.times], etc.
So, with VMS, there IS a "natural" notation for one-level
subdirectory searching, and multi-level subdirectory
searching, including pruning. But is there a natural way of
doing these things in all the other systems that might
implement these features?
Problems with cached indexes
I hope you don't end up with a solution that requires
caching for reasonable performance. It seems to me that,
unless one does a really good job of making the cache fully
automatic and utterly reliable, you've introduced a new
hard-to-diagnose source of problems.
This may be off the subject, but I do think there is a good
argument to be made for a different sort of auxiliary index
-- one to map font names to filenames on brain-damaged
systems (read MS-DOS) that only support short file names.
That would free the rest of the world from dealing with
encrypted names.
Please mail this to alanje@cogs.susx.ac.uk.
>From pppl.gov!karney Fri Oct 7 21:18:27 1994
From: Charles Karney <karney@pppl.gov>
Date: Fri, 7 Oct 1994 16:14:57 -0400
To: alanje@cogs.susx.ac.uk
In-reply-to: <m0qtHzO-00007eC@csrj.crn.cogs.susx.ac.uk> (alanje@cogs.susx.ac.uk)
Subject: Re: TeX directory structures
Reply-to: karney@princeton.edu
NAME: Charles Karney
EMAIL: karney@princeton.edu
TEX IMPLEMENTATION: Unix web2c from Karl Berry
This version of TeX currently supports (delete ones which don't apply):
* many-level subdirectory searching with pruning (for example you can
specify fonts//tfm and it will find
fonts/adobe/times/tfm/ptmr7t.tfm)
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* many-level subdirectory searching with a cache
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching with a cache
Any other comments:
(1) I think the directory structure proposed in the HIER file in kpathsea
for PK files is overly complicated. I would like to see ALL the PK files
for a particular printer in a single directory (with the MF mode name stuck
somewhere). This would allow the directory to be cleaned periodically
(with maketexpk used to regenerate the PK files as needed).
(2) However, more importantly I find myself worrying about the directory
structure too much. I would much prefer installation with a command such
as
make install
Then, I really don't mind what the directory structure is as long as it's
well documented. (See for instance the X11R6 installation. The
configuration of this massive software package is very simple.)
(3) The default configuration (for Unix) should be
executables in /usr/local/bin
man pages in /usr/local/man
macros, etc in /usr/local/lib/tex (or mf or texmf)
(4) Noone seems to know where to put the miscellaneous documentation files.
This is becoming more important with the use of docstrip. Perhaps
/usr/local/doc/???
--
Charles Karney
Plasma Physics Laboratory E-mail: Karney@Princeton.EDU
Princeton University Phone: +1 609 243 2607
Princeton, NJ 08543-0451 FAX: +1 609 243 2662
>From spam.maths.adelaide.edu.au!atrevorr Sat Oct 8 03:52:28 1994
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 8 Oct 1994 12:23:10 +0900
To: alanje@cogs.susx.ac.uk (Alan Jeffrey)
From: atrevorr@spam.maths.adelaide.edu.au (Andrew Trevorrow)
Subject: Re: TeX directory structures
>NAME: Andrew Trevorrow
>
>EMAIL: atrevorr@spam.maths.adelaide.edu.au
>
>TEX IMPLEMENTATION: OzTeX (runs on Macs)
>
>This version of TeX currently supports (delete ones which don't apply):
>
> * a list of directories for each sort of file (for example, you can
> specify fonts/tfm/adobe and fonts/tfm/monotype)
>
> * one level of subdirectory searching (for example, you can
> speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm)
In the latter case, OzTeX requires you to specify ":fonts:tfm:*".
>By this time next year, this version of TeX should (don't worry, we
>won't hold you to this one!) support:
Nothing more than the above options. I'm a devotee of KISS!
>If the TUG technical working group ask us to, we will implement:
> * many-level subdirectory searching
This is the only extra option I'd (very reluctantly) consider.
>Any other comments:
As I've indicated, I prefer as simple a directory structure as possible,
but one that is practical when it comes to storing lots of files.
In my view that means a small number of directories (possibly just one)
that must be explicitly listed. These directories can contain at most
one level of subdirectories. Anything more and my brain starts to hurt.
>--- end of form ---
>From cs.umb.edu!kb Mon Oct 10 11:22:31 1994
Date: Mon, 10 Oct 1994 06:20:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
To: alanje@cogs.susx.ac.uk
Subject: Re: TeX directory structures
EMAIL:
kb@cs.umb.edu
TEX IMPLEMENTATION:
web2c
This version of TeX currently supports (delete ones which don't apply):
[I didn't delete anything.]
* only one directory for each sort of file (for example, all tfm
files have to be in fonts/tfm)
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
* many-level subdirectory searching with pruning (for example you can
specify fonts//tfm and it will find
fonts/adobe/times/tfm/ptmr7t.tfm)
* many-level subdirectory searching with a cache to avoid
searching the whole directory structure for every file (for
example, the ls-R file in kpathsea).
* something else (please specify!)
>From holonet.net!kinch Mon Oct 10 09:39:28 1994
Subject: Re: TeX directory structures
To: alanje@cogs.susx.ac.uk
Date: Sat, 8 Oct 94 10:56:39 PDT
From: Richard Kinch <kinch@holonet.net>
NAME: Richard Kinch
EMAIL: kinch@holonet.net
TEX IMPLEMENTATION: TurboTeX 3.1, TrueTeX 4.0
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* a list of directories for each sort of file
If the TUG technical working group ask us to, we will implement:
* a list of directories for each sort of file
Any other comments:
Hey, how about standardizing environment variable names and syntax,
e.g., TEXINPUTS is where TeX files are to be found.
Please mail this to alanje@cogs.susx.ac.uk.
--- end of form ---
>From CS.Stanford.EDU!rokicki Mon Oct 10 18:28:46 1994
Date: Mon, 10 Oct 94 10:27:00 -0700
From: Tomas G. Rokicki <rokicki@CS.Stanford.EDU>
To: alanje@cogs.susx.ac.uk
In-Reply-To: Alan Jeffrey's message of 07 Oct 1994 17:17 -0300 (BST) <m0qtHzO-00007eC@csrj.crn.cogs.susx.ac.uk>
Subject: TeX directory structures
NAME: Tom Rokicki
EMAIL: rokicki@cs.stanford.edu
TEX IMPLEMENTATION: AmigaTeX
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* a list of directories for each sort of file
* Whatever else TWG decides.
If the TUG technical working group ask us to, we will implement:
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
* many-level subdirectory searching with a cache
>From earn-relay.ac.uk!IRLEARN.UCD.IE!WSULIVAN Tue Oct 11 15:57:22 1994
Date: Tue, 11 Oct 94 15:26:45 +0100 (WET)
From: "Wayne G. Sullivan" <WSULIVAN@IRLEARN.UCD.IE>
Subject: Re: TeX directory structures
To: Alan Jeffrey <alanje@cogs.sussex.ac.uk>
In-Reply-To: Your message of 07 Oct 1994 17:17 -0300 (BST)
I have worked with the implementation of
sbTeX for msdos
web2pc (gjgpp dos version of web2c programs)
Both these are limited by the (lack of) operating system msdos. sbTeX
currently searches single directories: inputs, fonttfms (formats should
not be a problem) but multiple directories can be searched by means of
setting environmentals. If ever a future version of sbTeX becomes advisable,
such a version will search all subdirectories of the inputs and tfm
directories. The 640K limitation of 16 bit dos does not justify any more
subtle searches.
The web2pc version is 32bit and includes Karl Berry's kpathsearch. However,
dos still has the 8.3 filename limitation and does not distinguish case in
file names. Any future implementations should, I believe, honour the 8.3
structure unless there are very good reasons for doing otherwise. DOS is
still very widely used. That LL could not have seen fit to shorten the
name of lcircle10 by one letter has caused a lot of extra work. If the
TeX file structure does not break the dos file name limits, the web2pc
version should be able to match the path search capabilities of the web2c
version, though with limited efficiency.
Wayne Sullivan
>From earn-relay.ac.uk!IRLEARN.UCD.IE!WSULIVAN Tue Oct 11 15:57:22 1994
Date: Tue, 11 Oct 94 15:26:45 +0100 (WET)
From: "Wayne G. Sullivan" <WSULIVAN@IRLEARN.UCD.IE>
Subject: Re: TeX directory structures
To: Alan Jeffrey <alanje@cogs.sussex.ac.uk>
In-Reply-To: Your message of 07 Oct 1994 17:17 -0300 (BST)
I have worked with the implementation of
sbTeX for msdos
web2pc (gjgpp dos version of web2c programs)
Both these are limited by the (lack of) operating system msdos. sbTeX
currently searches single directories: inputs, fonttfms (formats should
not be a problem) but multiple directories can be searched by means of
setting environmentals. If ever a future version of sbTeX becomes advisable,
such a version will search all subdirectories of the inputs and tfm
directories. The 640K limitation of 16 bit dos does not justify any more
subtle searches.
The web2pc version is 32bit and includes Karl Berry's kpathsearch. However,
dos still has the 8.3 filename limitation and does not distinguish case in
file names. Any future implementations should, I believe, honour the 8.3
structure unless there are very good reasons for doing otherwise. DOS is
still very widely used. That LL could not have seen fit to shorten the
name of lcircle10 by one letter has caused a lot of extra work. If the
TeX file structure does not break the dos file name limits, the web2pc
version should be able to match the path search capabilities of the web2c
version, though with limited efficiency.
Wayne Sullivan
>From compuserve.com!71172.524 Tue Oct 11 21:31:01 1994
Date: 11 Oct 94 16:24:27 EDT
From: Louis Vosloo <71172.524@compuserve.com>
To: "INTERNET:alanje@cogs.susx.ac.uk" <alanje@cogs.susx.ac.uk>
Subject: TeX directory structures
NAME: Berthold K.P. Horn
EMAIL: 71172.524@compuserve.com
TEX IMPLEMENTATION: Y&YTeX
This version of TeX currently supports (delete ones which don't apply):
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
> By this time next year, this version of TeX should (don't worry, we
> won't hold you to this one!) support:
* as above.
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching
Any other comments:
Yes, but not uniformly. When you say `TeX implementation' Are you
talking strictly about TeX itself or all of the associated stuff such as
previewer, printer drivers, utilities etc...
Automatic sub-directory searching was put in mostly for people
migrating from Unix. Most people don't use it much. It seems most
useful for figthing with those huge trees of PK files that bitmapped
implementations have to content with - which we don't have.
Regards, Berthold
>From azu.informatik.uni-stuttgart.d400.de!mattes Wed Oct 12 14:29:09 1994
From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.d400.de>
Date: Wed, 12 Oct 94 14:27:44 +0100
To: alanje@cogs.susx.ac.uk
Subject: TeX directory structures
NAME: Eberhard Mattes
EMAIL: mattes@azu.informatik.uni-stuttgart.de
TEX IMPLEMENTATION: emTeX
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
* many-level subdirectory searching with a cache to avoid
searching the whole directory structure for every file (for
example, the ls-R file in kpathsea).
* something else (please specify!)
One-level subdirectory searching is enabled by appending a single !
to the end of the path, many-level subdirectory searching is
enabled by appending !! to the end of the path, for instance:
c:\emtex\tfm!!;d:\fonts\tfm!
The paths are expanded at program start and all directory names
(but not the file names) are kept in memory.
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching with pruning
Any other comments:
HOWEVER, the syntax for pruning isn't unambigous under OS/2 and
MS-DOS: // (or \\) has a special meaning for accessing network
servers by name, therefore I prefer not to implement pruning with
that syntax. (I think Apollo Unix has something similar.)
Fortunately, // (and \\) are handled specially only at the very
beginning of a path name, for instance:
\\server\directory\file
That is, it's technically possible to specify pruning with //, but
it will confuse users.
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 09:53:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvROs-00007IC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 13 Oct 94 15:44 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
> - Eberhard doesn't seem anxious to support it either (based upon
> Alan's posting---though maybe it was only a comment about
> syntax). Three down?
One back up again. EM was just commenting on the syntax.
But otherwise (unsurprisingly) I agree.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 10:47:54 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
Date: Thu, 13 Oct 1994 16:47:31 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:242940:941013154742"@cl.cam.ac.uk>
Alan's chart so far is interesting. at least people seem to have
understood what he was asking. on the basis so far, I'm becoming a
fonts/type convert, simply cos i want to see this TDS succeed. and i
find Christian's argument that non-pruneed directories is trivial
under VMS, but pruned requires work, quite convincing. I know JS says
he will offer a POSIX library kit, but thats just not going to cut ice
with people for one reason or another.
if i can second guess peoples views, JS thinks that fonts/type is an
abortion and not needed, but also wants to see this thing off the
ground; Pierre thinks its philosophically *BAD*; Karl thinks its
inefficient because a cache will always be needed on real
systems. Thene there are the vaguer group, lke me, who think
fonts/type is untidy.
Strikes me that fewer people will scream if we reverse the decision...
Given that fonts/type doesnt preclude caching, can Karl live with
this? otherwise, do JS and PM now have apopplexy?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 13 Oct 1994 11:36:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 1994 11:36:32 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00985E17.22FA2FA0.165@SHSU.edu>
Subject: Re: draft document
On Thu, 13 Oct 1994 08:07:25 -0400, norm@ora.com (Norman Walsh), posted:
> As I recall, it's a script that builds the ZIP files so I think that
> martian-tds.zip is equally doable (and it doesn't violate the 8.3 rule so
> dramatically (if n.3 is less evil than n.m, I dunno)).
Will have to think further about how to get the .tds-zip (needs to be an
extension to toggle into special handling, but that's a trifle) to get the
proper hierarchical scheme (may require some linking, which might be
easier, but again, that's a mechanical trifle at the moment). As far as
the 8.3 (or whatever), that's one of the absolute beauties of the ZIP
utility which I don't want to get into changing. It uses whatever the
"proper" filename syntax is upon unpacking based on the operating system it
is UNZIPping on even though it used whatever restrictions were required on
the system doing the ZIPping. If it's an 8.3 system, the names magically
become 8.3; if it's a one-dot-only system, the names magically come out
with one dot; if it's a mono-case system,the naes magically....... In
other words, that is already taken care of for us, more of less.
--George
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 06:39:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141139.MAA15583@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:39:15 +0100 (MEZ)
Content-Type: text
Joerg wrote:
>
> I don't see a real problem in the test files coming with the Computer
> Modern fonts.
Of course.
> So they are placed under tex_root:[mf.cm.test].
Actually, tex_root:[mf.public.cm.test]
I.e., fonts/<source>/<type>
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 06:41:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141141.MAA16880@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:41:52 +0100 (MEZ)
Content-Type: text
Alan wrote:
>
> Although if Joachim's response is anything to go by I may as well not
> have bothered, since it looks like he's all set to ignore whatever the
> implementors have to say...
In contrary. I will reside with the implementors and with you and
will agree to fonts/<type>/ in the future. More on this in later mail,
when I've looked at my backlog completely.
Of course, I will not use this in my own installation. After all, I'm
using Unix.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 06:48:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141148.MAA19714@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:48:05 +0100 (MEZ)
Content-Type: text
David wrote:
>
> > No, if you look at the typical LaTeX2e distribution, it does not have
> > the file that are installed. They are created during installation.
>
> True, and this is actually a general problem, where to put the dtx
> files. under doc seems the obvious place
Hmm, for me the `obvious place' is the source tree. (Which we don't
say anything upon by intent.) doc/ was explicitely marked as `for
_user_ documentation'. I don't consider program source as user
documentation. Currently, my doc/latex/ holds
-rw-rw-r-- 1 tex software 55237 Oct 11 00:38 clsguide.tex
-rw-rw-r-- 1 tex software 51600 Oct 11 00:38 fntguide.tex
-rw-rw-r-- 1 tex software 5472 Oct 11 00:38 ltnews01.tex
-rw-rw-r-- 1 tex software 7247 Oct 11 00:38 sample2e.tex
-rw-rw-r-- 1 tex software 1700 Oct 11 00:38 small2e.tex
-rw-rw-r-- 1 tex software 48703 Oct 11 00:38 usrguide.tex
Perhaps one should add DVI or PS versions for some of these
documents, too. There might be more in the future, like lkurz.tex,
etc. I'd have to sort out the CTAN stuff for that.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 06:53:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 12:52:12 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141152.AA01530@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
> Actually, tex_root:[mf.public.cm.test]
> I.e., fonts/<source>/<type>
> Joachim
Er, no type here is `mf' isn't it? The VMS path looks like
fonts/mf/public/cm/tex
fonts/type/source/typeface/test
??
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 06:59:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 12:59:58 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141159.AA01537@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
>
> David wrote:
> >
> > > No, if you look at the typical LaTeX2e distribution, it does not have
> > > the file that are installed. They are created during installation.
> >
> > True, and this is actually a general problem, where to put the dtx
> > files. under doc seems the obvious place
>
> Hmm, for me the `obvious place' is the source tree. (Which we don't
> say anything upon by intent.) doc/ was explicitely marked as `for
> _user_ documentation'. I don't consider program source as user
> documentation. Currently, my doc/latex/ holds
>
> -rw-rw-r-- 1 tex software 55237 Oct 11 00:38 clsguide.tex
> -rw-rw-r-- 1 tex software 51600 Oct 11 00:38 fntguide.tex
> -rw-rw-r-- 1 tex software 5472 Oct 11 00:38 ltnews01.tex
> -rw-rw-r-- 1 tex software 7247 Oct 11 00:38 sample2e.tex
> -rw-rw-r-- 1 tex software 1700 Oct 11 00:38 small2e.tex
> -rw-rw-r-- 1 tex software 48703 Oct 11 00:38 usrguide.tex
>
> Perhaps one should add DVI or PS versions for some of these
> documents, too. There might be more in the future, like lkurz.tex,
> etc. I'd have to sort out the CTAN stuff for that.
>
> Joachim
This is in fact a problem, I have the site wide setup at Manchester
something similar to you have. Although I was planning to move some
more dtx files into the doc area once I get time. While it is true
that lterror.dtx might be viewed a source that you never want to
bother the users with, something like array.dtx or longtable.dtx (or
at least the dvi files produced from them with \OnlyDescription set)
*are* user documentation.
I do keep dvi and (html if the translation looks reasonable)
forms in (the equivalent of) the texmf/doc area.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 07:11:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141211.NAA14533@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 13:11:02 +0100 (MEZ)
Content-Type: text
You wrote:
>
>
> > Actually, tex_root:[mf.public.cm.test]
> > I.e., fonts/<source>/<type>
> > Joachim
>
> Er, no type here is `mf' isn't it?
Yeah, you're right. I misinterpretet that.
> fonts/mf/public/cm/tex
>
> fonts/type/source/typeface/test
>
> ??
Not nice. That would mean we keep in fonts/type/source/typeface both
lots of files and one directory. I have to say I don't like that.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 07:13:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 08:09:57 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141209.IAA26179@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
References: <199410141211.NAA14533@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 13:11:02, Joachim Schrod wrote:
> > fonts/mf/public/cm/tex
> >
> > fonts/type/source/typeface/test
> >
> > ??
>
> Not nice. That would mean we keep in fonts/type/source/typeface both
> lots of files and one directory. I have to say I don't like that.
I suppose the obvious answer is
fonts/test/source/typeface
since 'test' files are just a 'type' of file. Not in exactly the same
sense, unfortunately, but...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 07:13:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141213.NAA16845@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 13:13:29 +0100 (MEZ)
Content-Type: text
David wrote:
>
> Although I was planning to move some
> more dtx files into the doc area once I get time. While it is true
> that lterror.dtx might be viewed a source that you never want to
> bother the users with, something like array.dtx or longtable.dtx (or
> at least the dvi files produced from them with \OnlyDescription set)
> *are* user documentation.
Actually, that's what I do. I use a perl script to add
\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
and store them in doc/latex-styles/.
Now, that directory name is another problem I'd like to address in
another mail that is a direct critic on the current draft.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 08:17:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141317.OAA19738@spice.iti.informatik.th-darmstadt.de>
Subject: Report on the DANTE Meeting
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Fri, 14 Oct 1994 14:17:42 +0100 (MEZ)
Content-Type: text
At the DANTE meeting I had the opportunity to speak with some
developers of TeX software; in particular with Peter Breitenlohner
(PublicTeX) and Lutz Birkhahn (Atari TeX). A few driver developers
were there as well.
There was a general overall-agreement with the TDS proposal. I
learned that the DANTE DOS distribution -- with PublicTeX -- uses a
subdirectory organization for TeX input files already. Actually,
PublicTeX supports subdirectory searching and uses doubled directory
separators to mark the places where this should happen. I.e., the
example on p.3 of the draft is actually the method used by PublicTeX.
In case it is not well known enough: PublicTeX was the first
freely distributable port of TeX to DOS, done by Klaus-Peter Thull
and now supported by Peter Breitenlohner (who has abandoned his
involvement in sbTeX). It's distributed under the GPL. I.e., it's
the *only* pure-DOS port where source is available. (With pure-DOS I
mean: it runs on any 80x86 class machines.)
Both persons were reluctant in adapting fonts/<source>, they prefered
fonts/<type>. I think it's not uncorrelated to the fact that they
use _only_ CM fonts and none else. The driver developers were not as
reluctant as long as they get a well-tested module they can plug in
their systems.
I did a straw poll (about 70 attendees, 25 responded) about the usage
of fonts. All but three use at maximum two font families. 17 people
use only CM. The rest use CM and one of standard Adobe fonts. IMO
care must be taken to interpret this data point; 25 people are too
few to make factual statements -- and we must look at the
installations of the future, not only at today. Nevertheless, one
has to take into account that these attendees are not of the
clueless-newbie type but are very engaged in TeX. So I don't think
any more that the critical mass of `font junkies' has been
accumulated. It seems to be too early for full-fledged systems,
(too) many people are still very satisfied with the things they have
today. (As one can also show by other examples.)
So I decided to withdraw my objection against fonts/<type>.
I abstain. (Not my opinion, I won't shut up... :-)
The `abstain' is for the sake of a straw poll.
I would like to see a reflexion on this topic in the TDS, 'though.
My proposal is to use similar wordings as in the package/format
discussion. From the top of my head: ``fonts/<type>/<source>/ does
reflect current usage more and is more likely to be adopted by both
the developers and the users community. But there was a strongly
voiced opinion in favor of fonts/<source>/<type>. The proponents of
that alternative are Unix users with large installations; in
particular, Karl Berry, Pierre MacKay, and Joachim Schrod. They argue
that large font sets will be a common case for future TeX
installations, due to performance reasons one will need a directory
cache for the subdirectory search implementation anyhow, and with
that cache the directory layout can be more oriented towards the need
of the installation maintainer and not towards the need of the TeX
software developer.''
I would like to have my name appended to such a statement instead of
writing about some anonymous knowledgable-experienced-or-whatever
people. While I don't expect that happen here in this TWG, I have
experienced enough gossip, spread of false information, and
behind-ones-back imputations in the past. (From suits of TeX users
groups, both TUG and local ones.) Therefore I would like to attach
my name to my opinion, I stand by it...
Sorry, that this gets so long, but I'm still not finished. :-) :-)
DANTE has agreed to obey (dare one say support? ;-) TDS in all future
TeX distributions they prepare and that are maintained or recommended
to people. (As a background: Due to political reasons -- the suits
I'm writing above -- it's not so easy to get such a statement. But
after three hours discussion it was agreed upon. Perhaps they got too
tired then. :-)
Btw, in the light of the current discussions and information, I start
to withdraw my statement on the to-be-expected non-acceptence of TDS.
(George, are that enough hyphens?)
I was asked if it is really necessary to give the root of the TDS tree
a fixed name. Peter and others prefered some kind of abstract notion
like <texmf> or $TEXMF or similar. He talked about syntactic
placeholder, not a fixed name. As a DOS person, he's reluctant to
add one directory level if one might use a complete partition for TeX
anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
and still conform to the TDS.
That's the report from the meeting. I'll send my comments on the
current draft tonight.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 08:39:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 14:37:23 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141337.AA01613@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: cd lowercase 8+3 filenames
I said:
> > <para>
> > The most troubling limitation is monocase names because &LaTeX;
> > uses mixed case names for font descriptor files. However, this
> > problem is surmountable.
>
> Half a dozen lines inserted in texsys.cfg would remove this problem
> .....
>
> [ I havent actually got these `half dozen lines' to hand, but I
> could commission Alan Jeffrey to produce them if required:-]
I couldn't afford to commission A.J. so I have produced the following
muself:-) Norm, have you actually got one of these cd thingies hooked
on to unix box to see whether this actually works:-)
If you run the test file, it the \input{} should input the file
lowercase 8+3, and similarly the \selectfont should find the lowercase
0t1foo.fd file.
David
PS That was much more fun than thinking about where fonts should go..
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% An example that truncates all filenames to 8+3 lowercase.
%%% if they are not found with their natural name.
\makeatletter
\def\input@path{{}}
\def\LowercaseFile#1 {%
\edef\@tempa{#1}%
\expandafter\lowercase\expandafter
{\expandafter\EightPlusThree\@tempa..\\}}
\def\EightPlusThree#1.#2.#3\\{%
\edef\@filef@und{%
\TruncateEight#1%
\@empty\@empty\@empty\@empty\@empty\@empty\@empty\@empty\\%
.\TruncateThree#2\@empty\@empty\@empty\\ }}
\def\TruncateEight#1#2#3#4#5#6#7#8#9\\{#1#2#3#4#5#6#7#8}
\def\TruncateThree#1#2#3#4\\{#1#2#3}
\def\@file@name@handler#1{\LowercaseFile#1 }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Currently the internal command \@iffileonpath
% does not call \@file@name@handler, so patch it so that it does.
\let\@@iffileonpath\@iffileonpath
\def\@iffileonpath#1{%
\@file@name@handler{#1}%
\expandafter\@@iffileonpath\expandafter{\@filef@und}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% just to show it works:
%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{filecontents}{abcdefgh.xyz}
\typeout{^^J***I love MSDOS!^^J}
\end{filecontents}
\makeatletter
\begin{filecontents}{ot1foo.fd}
\typeout{^^J***lowercase_fd_file_for_cd!^^J}
\DeclareFontFamily{OT1}{foo}{}
\DeclareFontShape{OT1}{foo}{m}{n}{<->ssub * cmtt/m/n}{}
\end{filecontents}
\input{aBcDeFgHiJkLm.xYzW}
\fontfamily{foo}\selectfont
\stop
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 08:54:41 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Date: Fri, 14 Oct 1994 14:54:17 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:181090:941014135430"@cl.cam.ac.uk>
Joachim's attitude seems very reasonable to me. I am extremely glad
indeed that he has got a public support from DANTE, thats really good
work. I can promise UKTUG will do the same, co si make up theire disk
sets :-}
lets be clear that using fonts/type doesnt preclude the use of a cache
for very large installations; its just that in that case the setup is
inelegant
s
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 09:28:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 15:18:01 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Message-ID: <01HI9RH8IOPU96VRI4@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Actually, I'm maintaining a traditional VMS installation where
tex_root:[fonts] contained only the tfm files (there was no
directory named tfm.dir anywhere).
So tex_root:[mf.cm.test] reads
^ ^
| typeface, with subdirectories
type of the font (METAFONT).
It is easy to migrate to tex_root:[fonts.mf.cm.test] and to introduce a
directory tex_root:[fonts.tfm], if the TDS stabilises this way, I'll surely
do it. For practical reasons, I probably merge several TDS directories into
one (e.g. just having one directory for the famous 35 built-in PostScript
fonts of the laserjet). However, for compatibility reasons with LaTeX2.09,
there are two sets of tfms for those, one I have termed ``afmtotfm'' and
one ``fontinst'' by the method of generation. Fortunately there is no name
clash between the tfm files in those two directoies, but if there were any
I can easily configure the tfm searching path differently for LaTeX and
LaTeX2.09.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 10:20:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 10:20:04 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00985ED5.9EA9E8C0.405@SHSU.edu>
Subject: Re: Report on the DANTE Meeting
On Fri, 14 Oct 1994 14:54:17 +0100, Sebastian Rahtz
<Sebastian.Rahtz@cl.cam.ac.uk> posted:
> Joachim's attitude seems very reasonable to me. I am extremely glad indeed
> that he has got a public support from DANTE, thats really good work. I can
> promise UKTUG will do the same, co si make up theire disk sets :-}
Good work, indeed! On both your parts!! Definitely, whatever is finally
proposed will face a (at least initially) tough road as it means that some
people do have to change. Having two groups supporting it as a default
will definitely be a feather in the cap of this TWG. Thanks, gentlemen.
> lets be clear that using fonts/type doesnt preclude the use of a cache for
> very large installations; its just that in that case the setup is inelegant
While I agree with this sentiment to a large extent, this is also an area
where existing critical mass simply has to be listened to. Not that it's
necessarily the "right" approach nor the most elegant, but that it may be
the hardest single sell of the entire project in the event that it is not
followed initially. However, it might be worthwhile to include parts of
the debate in the document as providing fertile grounds for extensibility.
As a side (and probably immaterial if not ignorant) question, based on VMS
only, I don't see caching as a problem nor design of structure (except as
in the criticla mass issues which Christian has already provided). When
discussing caching (here's the truly ignorant part), how would that differ
from, say, VMS concepts of dynamically defined RMS indexing of directory
(*.DIR) files? I'm openly admitting ignorance on the concepts of caching
being discussed, but I thought that was one of the kinda implicit ideas
behind RMS concepts. If so, might a semi-port of the RMS concepts be all
that is required to get the performance issues under control?
--George
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 10:55:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141555.QAA21363@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Report on the DANTE Meeting
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 16:55:04 +0100 (MEZ)
Content-Type: text
George wrote:
>
> As a side (and probably immaterial if not ignorant) question, based on VMS
> only, I don't see caching as a problem nor design of structure (except as
> in the criticla mass issues which Christian has already provided). When
> discussing caching (here's the truly ignorant part), how would that differ
> from, say, VMS concepts of dynamically defined RMS indexing of directory
> (*.DIR) files?
It wouldn't. One can add some heuristics, but most probably this
will win only a few percent.
> If so, might a semi-port of the RMS concepts be all
> that is required to get the performance issues under control?
Sigh. ``be all that is required''. Yes, you got it. Please explain
this to the others, I tried and failed.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 11:31:00 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvlzK-0006WSC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 13:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
>Actually, that's what I do. I use a perl script to add
>\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
>and store them in doc/latex-styles/.
Meep meep meep. Please don't do this! This sort of site-wide
configuration is what the .cfg file is for. Editing the source is
specifically not allowed in the distribution conditions.
And as far as I'm concerned, doc/latex is the right place for the .dtx
files. Either that or doc/latex for the user documentation and
doc/ltxsrc (or ltxkernel or ltxbase or something) for the source.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 11:31:14 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvm2X-0006WTC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 13:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
>> Although if Joachim's response is anything to go by I may as well not
>> have bothered, since it looks like he's all set to ignore whatever the
>> implementors have to say...
>In contrary.
I think I owe you an apology for that message---I wrote it as an
immediate reaction without engaging brain too much.
>Of course, I will not use this in my own installation. After all, I'm
>using Unix.
What people get up to in the privacy of their own installations is
their own business :-)
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 11:46:57 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvoEA-0006WtC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 16:07 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: cd lowercase 8+3 filenames
>I couldn't afford to commission A.J. so I have produced the following
>muself:-)
I appear to have priced myself out of this particular market...
Serves me right for insisting on my right to a minimum wage...
Alan.
PS: If you're not British, that's probably not funny.
PPS: Even if you are British, it's more sad than funny.
PPPS: That's enough PSs, ed.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 11:47:29 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvoK3-0006WkC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 16:13 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Report on the DANTE Meeting
>There was a general overall-agreement with the TDS proposal.
This is good news!
Most of the comments I've had from developers seem to be reasonably
TDS-friendly as well. So I'm reasonably optimistic about uptake of
TDS.
>I would like to see a reflexion on this topic in the TDS, 'though.
Agreed. The form of words you suggested looked good to me.
>I was asked if it is really necessary to give the root of the TDS tree
>a fixed name. Peter and others prefered some kind of abstract notion
>like <texmf> or $TEXMF or similar. He talked about syntactic
>placeholder, not a fixed name. As a DOS person, he's reluctant to
>add one directory level if one might use a complete partition for TeX
>anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
>and still conform to the TDS.
I'd also like to back this. I'd *much* prefer to call our TeX area
/local/tex, since this is what it's been called for years and years
and years (OK, it used to be /usr/local/tex).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 12:39:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 13:36:24 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141736.NAA27465@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
References: <m0qvoK3-0006WkC@rsuna.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 16:13, Alan Jeffrey wrote:
> >I was asked if it is really necessary to give the root of the TDS tree
> >a fixed name. Peter and others prefered some kind of abstract notion
> >like <texmf> or $TEXMF or similar. He talked about syntactic
> >placeholder, not a fixed name. As a DOS person, he's reluctant to
> >add one directory level if one might use a complete partition for TeX
> >anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
> >and still conform to the TDS.
>
> I'd also like to back this. I'd *much* prefer to call our TeX area
> /local/tex, since this is what it's been called for years and years
> and years (OK, it used to be /usr/local/tex).
Fine by me. But what's it to be called in the document. I find
<texmf>/<format>/<package>
and the like a little daunting. $TEXMF is a bit unix-specific, but is
that what we'd all like?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 12:46:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 18:46:02 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141746.AA01836@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
> Fine by me. But what's it to be called in the document. I find
> <texmf>/<format>/<package>
> and the like a little daunting. $TEXMF is a bit unix-specific, but is
> that what we'd all like?
There is anyway a difference: <format> is a variable within the tree
but in any given tree <texmf> is constant. why not just keep texmf
throughout the document, but in the section `rooting the tree'
say that the document, for concreteness, will use the texmf as the
root (and that this is a suggested name in practice) but that the root
can be anything (eg a DOS partition t:)
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 12:48:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 13:45:01 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141745.NAA27551@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
References: <9410141746.AA01836@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 18:46:02, David Carlisle wrote:
> There is anyway a difference: <format> is a variable within the tree
> but in any given tree <texmf> is constant. why not just keep texmf
> throughout the document, but in the section `rooting the tree'
> say that the document, for concreteness, will use the texmf as the
> root (and that this is a suggested name in practice) but that the root
> can be anything (eg a DOS partition t:)
Sounds good to me.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 12:50:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 10:47:55 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141747.AA08684@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: tree placement
PLEASE do not build in a fixed location for the TDS tree. Each site
administrator will have reasons for putting the tree in some location
or another, and should not be forced to mess with symbolic links, etc.
Norm and I will also get hung up by it, because our CD-ROMs will not
necessarily be able to be mounted in the designated location.
If you feel compelled to tie things down, pick a default location, but
allow it to be overridden by an environment variable or somesuch. In
fact, it should really be possible to specify multiple parallel trees
(e.g., local, network, CD-ROM, project, ...) so this capability should
already be present.
-r
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 13:20:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 18:55:04 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141755.AA01851@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
I said:
> but that the root can be anything (eg a DOS partition t:)
It ought to stress though that the root should *only* consist of TDS
material.
using c: (or /usr/local/lib on unix) and mixing everything up with
other system files isnt quite the idea...
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 13:38:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:38:15 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141838.LAA11514@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
> If Karl/Pierre/Joachim feel that they could support a TDS document
> proposing fonts/type then that would be ideal.
It depends what is meant by support. I could probably rearrange the
UnixTeX distribution (which goes out to about one site a month, so it still
has some marginal value) to do fonts/type, but that would create
such a wall between the way I more or less have to work with my font
library and the distribution archive, that I think it would have the
effect of freezing things at the present level---which since I have lost
the support from Elizabeth Tachikawa is a risk anyway.
One subversive suggestion occurs to me. The pressure for fonts/type
comes often associated with the suggestion that fd and font-related
sty files should somehow be stuck into the font tree. Since this seems
to be associated almost exclusively with the use of LaTeX, and with
an assumption (which I continue to regard as dubious) that LaTeX users
will never want to go beyond CM and Times, maybe the LaTeX tfm set
should be given honorary status as macros and stuck into the texmf/tex/latex
tree. Then there is no problem of files required for the source->dvi
stage of production residing in different trees.
The fonts tree seems to be falling into complete chaos, which is odd,
because when Karl, Elizabeth and I started thinking about a more systematic
handling of directory trees, it was fonts more than anything else that
made us feel it was necessary.
Among the assumptions behind fonts/type, explicitly stated in some of the
past discussion, is that hardly anyone gives a damn about typefaces, which
may very well be true even for TeX users, and seems, to judge by the
past three months of comments to most definitely true of the vast
majority of LaTeX users.
This being the case, I wonder whether we are really trying to set
the net too wide. It appears more and more as if we are looking
exclusively at the Latex Directory Standard, not at the TeX Directory
Standard. LaTeX involves the notion of standard layouts, formats, etc.
and is an obvious candidate for association with a Directory standard.
I don't think any outside reader of the TWG-TDS correspondence could
miss the implication that except for Joachim, the people who cause
all the trouble are the TeX anarchists.
Leave the anarchists out, and it looks as if a TWG-LDS could be put
together with very little trouble. I think that if LaTeX users ever
develop a taste for fonts, the fonts side of such a LDS will become a
real nightmare to manage, but for the present there seems to be no
indication that that taste will ever develop.
So I would be perfectly prepared to set up a LDS tree for shipment
to outside sources. But I would assume that the font resources in such
a tree would always remain severely limited. Perhaps it should be limited
to fonts that have no licensing problems, either because they
are public domain, or because the license goes with the printer
so that only metrics appear in the tree.
That would be manageable.
I hope the structure stabilizes fairly soon. I have a couple of
half-baked packages and upgrades I would like to send out, and
I don't want to put them out until the preferred organization is clear.
(The horror stories of increases in typesetting time by factors of
800% when kpathsea is used keep flowing in. I don't understand it at
all. I have to do most of my work on a Sun 3-50 with only 4MB of
memory, a notoriously slow configuration these days, and while I am
quite aware of head-motion and thrashing at the startup of dvipsk (the only
program where the problem is really serious) it is never enough of a
problem to overcome the obvious advantages.) On a "real" machine, the
problem just isn't there.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 13:50:42 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:50:45 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141850.LAA14021@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Joachim's very useful message from DANTE includes one point that
we should certainly make clear. The root of the $TEXMF tree
is whatever is convenient on any given system. The explicit
existence of a "texmf" directory was not, to be best of my
recollection, ever required. For a DOS environment it seems
entirely reasonable that $TEXMF -> T:\
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 13:58:09 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:58:11 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141858.LAA15491@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Agreement again. If a DOS installation uses T: for $TEXMF
I guess we have to specify that T: contains *only* $TEXMF directories
and files.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Oct 1994 14:24:36 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvsGD-0006PXC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 20:25 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
>This being the case, I wonder whether we are really trying to set
>the net too wide. It appears more and more as if we are looking
>exclusively at the Latex Directory Standard, not at the TeX Directory
>Standard.
Well, we're looking for the people-who-are-too-busy-doing-their-real-
jobs-to-worry-about-such-things directory standard, which a lot of the
time == LaTeX directory standard.
As far as fonts go, the LaTeX Way seems to be `all fonts welcome, as
long as they're drop-in replacements for CM' at the moment. So it's
not so much an issue of font families as font encodings, and I think
we can all agree that a font directory structure partitioned by
encoding is not on :-)
Does it seem reasonable to agree that font/type is currently the
easiest way to go for users who don't want to think very much, and
that other directory structures are open for powerusers such as
Pierre?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Oct 1994 15:01:40 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152001.VAA14246@spock.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:01:44 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >Actually, that's what I do. I use a perl script to add
> >\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
> >and store them in doc/latex-styles/.
>
> Meep meep meep. Please don't do this!
I hope you understood me correct. The `them' in the last line you
cited are DVI files, not sources.
> This sort of site-wide configuration is what the .cfg file is for.
Not practicable as it is not usable for all kinds of distributions.
Some of them (not by the LaTeX team) don't use ltxdoc.
> Editing the source is
> specifically not allowed in the distribution conditions.
Sorry, but I don't care for that. In my source (working) directory I
do what I want. Of course, I won't distribute changed copies.
> And as far as I'm concerned, doc/latex is the right place for the .dtx
> files. Either that or doc/latex for the user documentation and
> doc/ltxsrc (or ltxkernel or ltxbase or something) for the source.
With the TDS example distribution, I'll go for the latter strategy;
separating user documentation and source. (But since web2c & TeX
sources are not in the texmf tree until now, I won't place the LaTeX
source there as well.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Oct 1994 15:14:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152011.VAA14292@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Robertson's Rules of Order (or something like that)
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:11:11 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> I don't think any outside reader of the TWG-TDS correspondence could
> miss the implication that except for Joachim, the people who cause
> all the trouble are the TeX anarchists.
I don't think I like that statement.
Joachim, TeX Anarchist
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Oct 1994 15:16:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152016.VAA14064@spock.iti.informatik.th-darmstadt.de>
Subject: Re: tree placement
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:16:59 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> PLEASE do not build in a fixed location for the TDS tree.
I think there's some communication problem here, most of us would
oppose such a step. The question at hand was ``Has the last
directory element of the TDS' location a fixed name (up to now
`texmf') or not?'' There seems to be agreement that such a fixed
name is not necessary, as long as only `TeX & friends' related files
are placed in this location.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Oct 1994 10:41:06 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwVrc-0006PiC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 16 Oct 94 14:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
>> >Actually, that's what I do. I use a perl script to add
>> >\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
>> >and store them in doc/latex-styles/.
>>
>> Meep meep meep. Please don't do this!
>I hope you understood me correct. The `them' in the last line you
>cited are DVI files, not sources.
Oh okay, fine. As long as the modified sources are thrown away and
it's just the dvi files that are stored, I guess this is reasonable.
Better of course would be for authors to allow the .cfg file, hey ho.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 07:44:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171243.NAA16919@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Sample TDS installation at Darmstadt FTP server
To: TWG-TDS@SHSU.edu
Date: Mon, 17 Oct 1994 13:43:58 +0100 (MEZ)
Content-Type: text
Christian wrote:
>
> Joachim asked if he should supply a "ls-R" file, recently.
>
> I would like to have something like that in addition to the "map" file
> of the directory layout.
The file map.lst has been replaced by two files, map.dirs and
map.files.
> This way I could study his decisions on where to locate specific files,
It's quite important that these are really *my* decisions, as I still
struggle to fit a distribution into TDS; often it's quite a vague
notion where some files do belong.
Note also that the update frequence is roughly weekly, as I typically
work on the weekend at this stuff. I have added a new category, btw;
web2c-specific archives. The directories & files from these archives
are listed in map.{dirs,files}, actually.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 08:46:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwsPX-0006QCC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 17 Oct 94 14:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: [mark@ei.ele.tue.nl: TeX implementors directory questionnaire]
Another questionnaire returned... again, can support fonts/type but
not fonts/source. Mainly entertaining for the stuff on how brain-dead
the ARM directory structure evidently is...
Alan.
--- cut here ---
From: mark@ei.ele.tue.nl (Mark Sinke)
Subject: TeX implementors directory questionnaire
To: alanje@cogs.susx.ac.uk
Date: Mon, 17 Oct 94 13:55:28 MET
Mailer: Elm [revision: 70.85]
Return-Path: alanje@cogs.susx.ac.uk
NAME: Mark J. Sinke
EMAIL: marks@stack.urc.tue.nl (or preferrably, when replied within 2 months:
mark@ei0.ele.tue.nl
TEX IMPLEMENTATION: ArmTeX 3.14 (Acorn RISC machines)
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* something else (please specify!):
files with .sty added are also searched without .sty. Acorn systems
don't allow extensions, so a file latex.tex is in fact a directory
`latex' containing a file `tex'. Files without extension are stored
in the directory proper.
The 1-level search is a true search, i.e., the mechanism detailed above
for storing files with extensions is not part of the search.
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* a list of directories for each sort of file
* one level of subdirectory searching
* something else -> detailed above
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching
* something else
Any other comments:
Please mail this to alanje@cogs.susx.ac.uk.
--- end of form ---
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 10:10:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171510.QAA22640@spice.iti.informatik.th-darmstadt.de>
Subject: problems in current version of TDS
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:10:18 +0100 (MEZ)
Content-Type: text
Hi, some comments on the current draft that might need discussion.
<sect1><title>Subdirectory Searching</>
[...]
<para>
To avoid different implementations having different syntaxes for
specifying recursive subdirectory searching, the TWG recommends
that subdirectory searching be specified by a doubled
directory separator. For example, the Unix-style pathname
<filename role=dir>/a/b//</>
would recursively search all directories under
<filename role=dir>/a/b</>; likewise for
<filename role=dir>c:\a\b\\</> under MS-DOS.
</para>
This should be formulated more vague, with the notation as an example.
In VMS, such a notation makes no sense at all, directory trees are
written as [...] there. As for DOS/PublicTeX, this notation is
already used, while Eberhard wrote he is not going to support this
notation in emTeX because \\ in DOS already has a different meaning,
and he thinks the users will be confused.
<para>
Implementations may also choose to implement single-level subdirectory
searching (i.e., all the subdirectories of a given directory, but not
subsubdirectories or any deeper level). Since this is not useful for the
&tds; we leave the syntax for this unspecified.
</para>
I suggest to omit this paragraph. As you write: This is not useful
for the TDS.
The implementation must do a breadth-first search of the subdirectories:
^^^^^^^^^^^^^
Really? Why did we decide on this (if we did?) We should consider that
a DFS is *much* easier to implement.
distribution for MS-DOS and OS/2 (although em&TeX; uses a slightly different
syntax for specifying recursive subdirectory searching).
</para>
<para>
This TWG recognizes that subdirectory searching places an extra burden
If we decide to recommend pruning, we should talk about it between
these two paragraphs. Btw, there are more implemenations with
subdirectory searching than you listed above.
<para>
It should be clear that subdirectory searching does not prevent
a site from having multiple different versions of a file with the same
name (for example, during testing or debugging). By specifying
subdirectory trees in the <systemitem class=environvar>TEXINPUTS</>
environment variable, the user can control the order in which &TeX;
will search for the file and consequently the version of the file
that it will find.
</para>
Not well understandable. Actually it *does* prevent multiple versions
in a tree that's searched at one time. In addition, the term
environment variable does not exist on many platforms.
How about:
As an immediate consequence of the search strategy outlined above one
cannot place variants of a file with the same name in a tree, it is
undefined which file would be found. If one wants to use different
versions, one has to specify a <systemitem
class=environvar>TEXINPUTS</> search path that lists the respective
subtrees in the search order as needed. Then the file must be only
unique in each subtree.
<sect1><title>Constraints</>
[...]
In addition, UNIX file systems
support symbolic links, which allows a CD-ROM to be accessed
through a ``link farm'' with little space overhead on a local disk.
I still think that people won't understand this. (This gripe was
already in my last comments.) A proposal:
Unix platforms can use symbolic links (that most of them support
nowadays) to overcome these restrictions. At installation time, a
script may produce a whole TDS tree with long, case-sensitive names
that consists only of symbolic links to the CD file system. The space
overhead produced by this ``link farm'' is neglectable.
<chapter><title>Rooting the Tree</>
[...]
many systems, this may be at the root of the filesystem; however,
on UNIX systems, this would traditionally be located in <filename
role=dir>/usr/local</>.
</para>
We should give more reasons here, and also mention that this root may
(should?) be used for network mounts. Peter Breitenlohner didn't
understand what was meant at first reading.
<para>
The <replaceable>system</replaceable> directories allow multiple
implementations to share the common directory structure. For example,
the binaries for em&TeX; might be installed in <filename
role=dir>/texmf/bin/emtex</>.
</para>
I suggest not to use a DOS example, but instead the placement of FMT &
Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
name is not ISO-conform, I know...)
<chapter><title>Macros</>
[...]
<listitem><para>
The alternative arrangement spreads out the files needed by the system.
The files that must be found using subdirectory searching may be spread
out in a wide, shallow tree. Fonts are no longer in a directory of
their own (since they must be under the package). This spreading effect
could have a profound impact on the efficiency of subdirectory searching.
</para></listitem>
This para is a problem! We argue here quite in favor of the fonts/type
approach. If this is going to be the looser, we might want to change
this paragraph.
<chapter><title>Fonts</title>
[...]
<sect2><title>Valid Font Bitmaps</title>
<para>
There was considerable discussion about how the disadvantages of this
scheme could be minimized. One result of that discussion was the
decision to allow extensions to the basic naming scheme (such as
<filename>cmr10.300pk</>) provided that the basic scheme is also
supported. The following statement is the other:
^^^
I suggest to insert here:
But still multiple files with the same name would exist (for different
devices).
<chapter><title>Package Distribution</>
[...]
martian-1.0/fonts/martian/tfm/mart10.tfm
Two points:
First, the naming is not ISO 9660 conform -- do we regard this as
relevant? I won't, since it's a section for a package distributor,
who will most likely *not* distribute on CD. And such brave persons
should not be hindered too much.
Second, a structure like this will make CTAN unusable, cf. past mails
from David & me.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 10:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171521.QAA17790@spice.iti.informatik.th-darmstadt.de>
Subject: hyphen, still problems
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:21:18 +0100 (MEZ)
Content-Type: text
Thanks to sebastian, we now have proper names for the hyphenation
files. But still, I have my problems with the respective TDS draft
item.
-- On second reading, I would recommend to discard all comments about
the names of hyphenation files. We do not fix any file name for
any other part of the TDS, why should we do that here? I think
the whole discussion I brought up muddied the water, sorry for
that. Specific file names should be outside the realm of this WG.
-- We discussed about introducing hyphen/ subdirectories for each
language. Actually, I did so for the TDS example distr. But
there I have the problem that I don't know how to restrict the
directory names to 8 chars. Truncating? Or shall I flatten the
tree?
Any comments on this topic would still be appreciated. (And it
will remain on my open problem list...)
-- I would prefer to rename tex/hyphen/ to tex/initex/hyphen, as I
have some INITEX-specific macro files that I don't know where I
should place them. If we introduce tex/initex/ I can create a
subdirectory there.
-- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
etc. He thinks that the usage intent is much clearer then. (Note
that currently LaTeX's *.ltx are *not* installed by default.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 10:40:31 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171540.QAA17805@spice.iti.informatik.th-darmstadt.de>
Subject: documentation
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:40:32 +0100 (MEZ)
Content-Type: text
Chapter 6 (`Documentation') lists
texmf/doc/<package>/<files>
as the basic structure there. The usage of the term <package> is
problematic, as this is a different <package> than the one used in
chapter 3 (`macros'). I would recommend to substitute it by <system>
and explain that <system> encompasses both utilities, macro formats
and major packages. Another possibility might be <entity>.
Actually, IMO the name should be rather vague. One cannot really make
an abstract decision what would be a good directory structure for the
documentation area, this needs more experiments and usability tests,
of course.
I discussed it with some users that were around this morning (approx.
10). They prefer to have doc/ subdirectories that denote task
categories. They need docs for BibTeX and other bibliographic tools,
docs on available styles (aka LaTeX modules), on available plain
macros, etc. They did *not* prefer to have a directory for each
style, as most styles come with only one documentation file. They did
also not like the idea of lumping all single-file documentations in
one directory misc/, they complained that they won't find it then
easily enough.
As a result of this discussion (and others I had before), I've
started to use a directory doc/latex-styles/ for documentation on
LaTeX modules. I would like to get recommendations for an ISO 9660
conformant name that is still indicative (? evidential?). Did I tell
you that I hate DOS?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 10:55:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 17 Oct 94 16:55:14 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410171555.AA03884@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: documentation
> As a result of this discussion (and others I had before), I've
> started to use a directory doc/latex-styles/ for documentation on
drwxrwsr-x 9 graham 512 Aug 26 14:04 LaTeX-doc-files/
Hmm seems like our name wouldnt quite fit in DOS either.
> I would like to get recommendations for an ISO 9660
> conformant name that is still indicative (? evidential?). Did I tell
> you that I hate DOS?
latexdoc/ ???
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 11:20:50 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Mon, 17 Oct 1994 16:52:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:069330:941017155324"@cl.cam.ac.uk>
>
> -- We discussed about introducing hyphen/ subdirectories for each
> language. Actually, I did so for the TDS example distr. But
> there I have the problem that I don't know how to restrict the
> directory names to 8 chars. Truncating? Or shall I flatten the
> tree?
lets change them permaenently on CTAN, with the cooperation of
authors. which ones bother you still?
> -- I would prefer to rename tex/hyphen/ to tex/initex/hyphen, as I
> have some INITEX-specific macro files that I don't know where I
> should place them. If we introduce tex/initex/ I can create a
> subdirectory there.
sounds plausible to me
> -- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
> files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
> etc. He thinks that the usage intent is much clearer then. (Note
> that currently LaTeX's *.ltx are *not* installed by default.)
as in tex/initex/latex/latex.ltx? i must say i cant see anything
against that.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 11:27:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171627.RAA23328@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Mon, 17 Oct 1994 17:27:30 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > -- We discussed about introducing hyphen/ subdirectories for each
> > language. Actually, I did so for the TDS example distr. But
> > there I have the problem that I don't know how to restrict the
> > directory names to 8 chars. Truncating? Or shall I flatten the
> > tree?
> lets change them permaenently on CTAN, with the cooperation of
> authors. which ones bother you still?
No, on CTAN you don't have subdirectories. I.e., all hyphen files are
in one directory on CTAN, but are distributed over many directories in
the TDS (named english, portuguese, icelandic, german, etc.) The
rationale for these directory was (once) that now administrators might
easier recognize for which languages they have patterns.
I'm happy to use just the hyphen/ directory as it is on CTAN, without
any subdirectories.
If the subdirectories remain, I must change names like `portuguese'
since they are too long.
> > -- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
> > files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
> > etc. He thinks that the usage intent is much clearer then. (Note
> > that currently LaTeX's *.ltx are *not* installed by default.)
> as in tex/initex/latex/latex.ltx?
Exactly.
> i must say i cant see anything against that.
I think it's a neat idea, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 17 Oct 1994 12:12:52 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwvdN-0006QBC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 17 Oct 94 18:14 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
>> as in tex/initex/latex/latex.ltx?
>> i must say i cant see anything against that.
Seems OK to me. Does this give us something like:
tex/initex/latex/* (latex.ltx, fontdef.cfg, etc.)
plain/* (plain.tex, er... eplain.tex?)
hyphen/* (hyphen.tex etc.)
amstex/* (etc)
fontinst belongs in tex/fontinst/* on sites which bother with it.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 18 Oct 1994 03:50:26 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Tue, 18 Oct 1994 09:49:54 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:135330:941018085011"@cl.cam.ac.uk>
> No, on CTAN you don't have subdirectories. I.e., all hyphen files are
> in one directory on CTAN, but are distributed over many directories in
not quite. the intention is to populate hyphenation with links from
language subdirectories.
> the TDS (named english, portuguese, icelandic, german, etc.) The
> rationale for these directory was (once) that now administrators might
> easier recognize for which languages they have patterns.
>
> I'm happy to use just the hyphen/ directory as it is on CTAN, without
> any subdirectories.
>
> If the subdirectories remain, I must change names like `portuguese'
> since they are too long.
i am happy to wield my unilateral axe again and rename all language
directories to their babel names, how would that be?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 18 Oct 1994 05:24:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410181024.LAA16658@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Tue, 18 Oct 1994 11:24:04 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >> as in tex/initex/latex/latex.ltx?
> >> i must say i cant see anything against that.
>
> Seems OK to me. Does this give us something like:
>
> tex/initex/latex/* (latex.ltx, fontdef.cfg, etc.)
> plain/* (plain.tex, er... eplain.tex?)
> hyphen/* (hyphen.tex etc.)
> amstex/* (etc)
Yes, I like this. I'll do it.
But I would still put texinfo.tex in tex/plain/texinfo or
tex/texinfo/. (texinfo.tex is somewhat a chamaeleon; it's used by
most people as a macro file, but can be used to create a format,
too.) I.e., in tex/initex/ should only go files whose *sole* purpose
is to be processed by initex with the intent to produce an FMT file.
> fontinst belongs in tex/fontinst/* on sites which bother with it.
Fine -- the author decides. :-) I'd already started to think about
texmf/fontinst/, as it is more a kind of utility, like BibTeX or
Makeindex, that happens to be written in TeX. It's not really a TeX
macro file in the sense that it provides markup for documents, as far
as I understood it.
That brings me to the point that we need a definition section where
we define the terms used in the document. Do we mean with `macro
file' all files that have TeX code or do we mean only those that
deliver markup (be it procedural or generic) for documents?
The same goes for other terms like `search path', etc. (We should
use the term `environment variable' only in examples and in notes.
That's an unportable term, as there are many OSes where it's not
used.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 18 Oct 1994 07:30:07 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qxDhF-0006QUC@rsuna.crn.cogs.susx.ac.uk>
Date: Tue, 18 Oct 94 13:31 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
>I.e., in tex/initex/ should only go files whose *sole* purpose
>is to be processed by initex with the intent to produce an FMT file.
This sounds like a good rule of thumb.
>Fine -- the author decides. :-) I'd already started to think about
>texmf/fontinst/, as it is more a kind of utility, like BibTeX or
>Makeindex, that happens to be written in TeX. It's not really a TeX
>macro file in the sense that it provides markup for documents, as far
>as I understood it.
I'd rather have it under tex/ so that if lazy people wish they can
just set TEXINPUTS to be everything under $TEXMF/tex.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Oct 1994 05:19:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 19 Oct 1994 06:19:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191019.AA28619@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
musictex and texinfo are often (usually?) not actually built as
formats. Especially musictex, which works, just about, with LaTeX.
Here you are only trying to give helpful examples, perhaps best just
to delete such marginal cases here
IMO, it is precisely the role of a document like this to define the
marginal cases. The easy cases are easy.
In this case, I sort of think Texinfo and MusicTeX should be treated as
separate formats, but don't have strong feelings about it. But I do
think the document should say where they go.
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Oct 1994 05:19:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 19 Oct 1994 06:19:28 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191019.AA28779@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: problems in current version of TDS
The implementation must do a breadth-first search of the subdirectories:
^^^^^^^^^^^^^
Really? Why did we decide on this (if we did?) We should consider that
a DFS is *much* easier to implement.
There should be no specification of either breadth-first or depth-first.
We've already discussed this ad nauseum. What you want is for it to find
the files that it *should* find (i.e., the fonts for the right mode),
and neither breadth- nor depth-first meets that criterion.
At least, it would be extremely difficult for me to implement any such
specification, and I see no advantage to doing so.
Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
name is not ISO-conform, I know...)
I see no reason to recommend a version number here. We are avoiding the
whole issue of different versions everywhere else.
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Oct 1994 06:20:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191119.MAA14801@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 19 Oct 1994 12:19:43 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> In this case, I sort of think Texinfo and MusicTeX should be treated as
> separate formats,
Me, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Oct 1994 06:21:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191121.MAA20185@spice.iti.informatik.th-darmstadt.de>
Subject: Re: problems in current version of TDS
To: TWG-TDS@SHSU.edu
Date: Wed, 19 Oct 1994 12:21:26 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
> name is not ISO-conform, I know...)
>
> I see no reason to recommend a version number here. We are avoiding the
> whole issue of different versions everywhere else.
As usual, he's completely right. Nevertheless, I would like that
example more than the binaries. Where binaries are put is a highly
site-dependent decision. That FMT & Base files are stored in the texmf
tree, is much more likely. (Or is this opinion just because it's the
way we're doing it? :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 04:10:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 94 10:09:54 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410200909.AA05830@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> musictex and texinfo are often (usually?) not actually built as
> formats. Especially musictex, which works, just about, with LaTeX.
> Here you are only trying to give helpful examples, perhaps best just
> to delete such marginal cases here
>
> IMO, it is precisely the role of a document like this to define the
> marginal cases. The easy cases are easy.
>
> In this case, I sort of think Texinfo and MusicTeX should be treated as
> separate formats, but don't have strong feelings about it. But I do
> think the document should say where they go.
>
Hmm good point. OK, I think the TDS document should have a section
saying where these (and other difficult cases) should go. Hoewver I
dont think this shoould be `slipped in' in the sentence introducing
the notion of <format> as at present. The examples there should stick to
plain latex etc, so that people understand what <format> is. A later
section might discuss the positioning of certain specific items?
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 05:06:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qxuNG-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 20 Oct 94 11:05 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: [vojta@math.berkeley.edu: Re: TeX directory structures]
Another reply, interesting for Paul's comments on subdirectory
searching and efficiency. Don't think he's going to be too pleased
with TDS. Hey ho.
Alan.
--- cut here ---
From: vojta@math.berkeley.edu (Paul Vojta)
Date: Wed, 19 Oct 1994 17:58:53 -0700
To: alanje@cogs.susx.ac.uk
Subject: Re: TeX directory structures
NAME: Paul Vojta
EMAIL: vojta@math.berkeley.edu
TEX IMPLEMENTATION: xdvi
This version of TeX ^H^H^H^H xdvi currently supports:
* only one directory for each sort of file (for example, all tfm
files have to be in fonts/tfm)
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm)
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
By this time next year, this version of TeX ^H^H^H^H xdvi should support:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
somewhat reluctantly (see below)
* many-level subdirectory searching with a cache
somewhat reluctantly, again
* something else
.fli files, maybe
If the TUG technical working group ask us to, we will implement:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
* many-level subdirectory searching with a cache
* something else
Any other comments:
Yes. As noted above, I'm not entirely sold on the idea of putting files
into subdirectories _on end-user systems_. Certainly it's a good idea
for organizing the directories on CTAN, but beyond that point I disagree.
Let me elaborate.
First, I recall several people pointing out the necessity for run-time
efficiency. That is my primary concern.
Now some timings. These were done on a Linux 486-33 with IDE drive.
I was using ntex01 at the time, running amstex on a short (3-page) file.
1. Without ls-R:
1.870u 1.370s 14.39
2. With ls-R:
2.010u 0.430s 5.45
3. Without ls-R, but after doing the following:
cd /usr/lib/texmf
mkdir pv_tfm
mkdir pv_macros
find fonts -name \*.tfm -exec ln \{\} pv_tfm \;
find tex -type f -exec ln \{\} pv_macros \;
setenv TEXFONTS .:/usr/lib/texmf/pv_tfm
setenv TEXINPUTS .:/usr/lib/texmf/pv_macros
1.660u 0.570s 5.10
All timings were done immediately after rebooting (except for the setenv's
in 3). All reboots skipped fsck.
Note that the last number, elapsed time in seconds, is better with all files
in one directory. I've heard mention of some systems on which this would
be worse, but I'd like to hear specifics: names of systems, and timings
as above.
Of course, on a system where somebody is installing TeX from scratch
but expects only occasional use, then certainly pulling the CTAN directory
structure would be appropriate, and for that reason I plan to implement
subdirectory searching and (some form of) ls-R. But on the opposite extreme,
if somebody is assembling, e.g., a TeX distribution for linux, then they
should spare no effort in making it as efficient as possible. In that
case they should do as in #3, possibly with mv in place of ln. As for
the maintainability question, what people usually do with distributions
of TeX is they usually just replace the whole thing when they upgrade.
Perhaps it is instructive to compare this situation with the situation
for Unix as a whole. We don't have subdirectory searching for
/usr/man/man<n> or for /bin, yet they are big directories:
_tashkent% ls /usr/man/man1 | wc -l
497
_tashkent% ls /usr/man/man3 | wc -l
1169
_tashkent% ls /bin | wc -l
234
The way to manage this is to have a package installation tool; Unix
vendors actually, therefore, do have a "directory structure" as in TDS,
which no doubt exists on their development systems, but on user systems
it is represented implicitly in the installation procedure rather than
explicitly on disk.
--------------------
As a second comment (which also has a lot to do with my stated reluctance
to implement directory pruning and ls-R) is that I have already put quite
a bit of time into font searching in xdvi. Early on I implemented a search
strategy which allows you to put in printf-style descriptors %f, %d, and %p
(font, dpi, and pk/gf/pxl format, respectively) and which allowed you to
specify your own search path in addition to the default. I thought that
this would be sufficient until the end of time (and in fact it suffices
for #3 above). Then Karl asked me to put in subdirectory searching
(as indicated above), which I did with some reluctance. Now there's ls-R
and directory pruning. What next?
If TDS-II requires any changes to xdvi, it'll take quite a bit of convincing
to get me to make those changes. Time spent on font searching in xdvi
is time taken away from implementing the rotation and color specials for
LaTeX-2e, switching dvi files on-the-fly, etc.
--------------------
Please mail this to alanje@cogs.susx.ac.uk.
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 05:20:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 06:17:19 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410201017.GAA21068@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <9410200909.AA05830@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 20 October 1994 at 10:09:54, David Carlisle wrote:
> > musictex and texinfo are often (usually?) not actually built as
> > formats. Especially musictex, which works, just about, with LaTeX.
> > Here you are only trying to give helpful examples, perhaps best just
> > to delete such marginal cases here
> >
> > IMO, it is precisely the role of a document like this to define the
> > marginal cases. The easy cases are easy.
> >
> > In this case, I sort of think Texinfo and MusicTeX should be treated as
> > separate formats, but don't have strong feelings about it. But I do
> > think the document should say where they go.
>
> Hmm good point. OK, I think the TDS document should have a section
> saying where these (and other difficult cases) should go. Hoewver I
> dont think this shoould be `slipped in' in the sentence introducing
> the notion of <format> as at present. The examples there should stick to
> plain latex etc, so that people understand what <format> is. A later
> section might discuss the positioning of certain specific items?
Sounds good.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 05:25:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
Date: Thu, 20 Oct 1994 11:20:15 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:181060:941020102520"@cl.cam.ac.uk>
i dont think Paul Vojta is entirely out of court. i think we would all
regard it ias acceptable to locally configure TeX to be efficient in
whatever ways seemed right, so long as
a) we talk TDS language in public
b) we provides tools to help our users uses the system as if it were
TDS.
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 14:05:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 15:04:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410201904.AA25973@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
If the TDS is to be used only on CTAN and for interchange, and not for
installations, then the whole thing is pointless, as far as I can see.
We got into this so that package/implementation maintainers could all
have one directory standard for the default installation. If many sites
feel the need to flatten the tree, then we've failed.
I think there are very ``end user'' systems as Paul V. describes them,
and very few people putting together (or using) monolithic TeX
packages. For better or worse, the TeX software is a distributed entity,
maintained by many many different people, used by even more people, all
with their own circumstances. Our task is to find a directory structure
that can both be used *and* be maintainable. No subdirs wins on
usability, but not maintainability.
As I and others said long ago, the crucial turning point is not between
subdirectory searching with/without pruning, or with/without caching or
with/without anything else. It's whether there is subdirectories
*at all*. The only thing which is supported by all implementations, and
the only thing with no performance loss (except on VMS) is no subdir
searching.
Most texadmins certainly do not, so far as I know, replace the entire
tex tree when they upgrade; they have their own local packages and
fonts, their own favorite outside macro packages, etc. When they (I
should say `we') upgrade a macro package, we don't change the TeX
binary.
Then Karl asked me to put in subdirectory searching
(as indicated above), which I did with some reluctance.
Just as a point of fact, so far as I know I didn't just ask you to put
in that feature, I gave you the code to do it, integrated into the
then-current xdvi.
Now there's ls-R and directory pruning. What next?
Runtime configuration files :-)
Believe me, I would like nothing better than to stop working on file
searching. But I feel compelled to do it right.
Anyway, I have yet to be convinced that directory pruning is necessary,
given ls-R. My experience with ls-R is different from your times --
namely, that it is *far far* more necessary. Perhaps your document
didn't load many fonts/macros, or maybe your trees don't have all the
PostScript+LJ fonts subdir-ized. There are too many variables.
I've heard mention of some systems on which [all files in one dir] would
be worse, but I'd like to hear specifics: names of systems, and timings
as above.
George et al. said VMS was in this category.
However, I can personally vouch for the fact that it takes a noticeably
long time to search for a file in a directory with 30,000 files
... fortunately, TeX isn't quite there yet!
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 14:49:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 14:49:14 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Message-ID: <009863B2.3761BB20.183@SHSU.edu>
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
On Thu, 20 Oct 1994 15:04:35 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> I've heard mention of some systems on which [all files in one dir] would
> be worse, but I'd like to hear specifics: names of systems, and timings
> as above.
>
> George et al. said VMS was in this category.
VMS has a problem in handling directory files (*.DIR) which are in excess
of 128 512-byte blocks. The length of file names, as well as the number of
files, held in a directory impact directly the size of the *.DIR file.
Hence, there's no magic number of files in the directory which cause the
problem; instead, it's the number of characters in the filenames which are
of major concern. So long as the directory stays below 128 blocks, it is
effectively cached; once it hits the magic number of 128 or exceeds it,
each time a file in a directory is accessed, it requires a read of the
*.dir file. In other words, system performance takes a major whammy and
benchmarking is nearly out of the question as disk access is a function of
so many factors that replicating anything once you have to deal with disk
access issues, you're effectively hosed.
I'm sure that Christian, Phil, or others can say all of this much more
proficiently (and professionally!) than I can, but that is the effect.
--George
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 19:15:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 20 Oct 1994 17:15:57 -0700
Message-ID: <199410210015.RAA12040@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
Karl Berry writes:
> I think there are very [many?] ``end user'' systems as Paul V. describes them,
> and very few people putting together (or using) monolithic TeX
> packages. For better or worse, the TeX software is a distributed entity,
> maintained by many many different people, used by even more people, all
> with their own circumstances. Our task is to find a directory structure
> that can both be used *and* be maintainable. No subdirs wins on
> usability, but not maintainability.
Well, I doubt that most users of TeX under linux compile their own TeX.
> Most texadmins certainly do not, so far as I know, replace the entire
> tex tree when they upgrade; they have their own local packages and
> fonts, their own favorite outside macro packages, etc. When they (I
> should say `we') upgrade a macro package, we don't change the TeX
> binary.
When you do install the TeX binary, do you put it into /bin or /usr/bin
and then complain that Unix is not maintainable? No, you put it in
/usr/local/bin (assuming you don't give TeX its own place on the standard
search path) and then you preserve /usr/local between O/S upgrades.
Likewise, one could (should?) put the standard TeX distribution in
/usr/lib/texmf/ and local stuff in /usr/local/lib/texmf/.
> Then Karl asked me to put in subdirectory searching
> (as indicated above), which I did with some reluctance.
>
> Just as a point of fact, so far as I know I didn't just ask you to put
> in that feature, I gave you the code to do it, integrated into the
> then-current xdvi.
Correct.
...
> Anyway, I have yet to be convinced that directory pruning is necessary,
> given ls-R. My experience with ls-R is different from your times --
> namely, that it is *far far* more necessary. Perhaps your document
> didn't load many fonts/macros, or maybe your trees don't have all the
> PostScript+LJ fonts subdir-ized. There are too many variables.
Have any numbers?
One way to look at what I'm saying is: why should TeX, etc. do its own
caching, when it can be done with existing mechanisms in the O/S (at
least under Unix)?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Thu, 20 Oct 1994 19:37:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 20 Oct 1994 17:38:05 -0700
Message-ID: <199410210038.RAA12073@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
George D. Greenwade <bed_gdg@SHSU.edu> writes:
> On Thu, 20 Oct 1994 15:04:35 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> > I've heard mention of some systems on which [all files in one dir] would
> > be worse, but I'd like to hear specifics: names of systems, and timings
> > as above.
> >
> > George et al. said VMS was in this category.
>
> VMS has a problem in handling directory files (*.DIR) which are in excess
> of 128 512-byte blocks. The length of file names, as well as the number of
> files, held in a directory impact directly the size of the *.DIR file.
> Hence, there's no magic number of files in the directory which cause the
> problem; instead, it's the number of characters in the filenames which are
> of major concern. So long as the directory stays below 128 blocks, it is
> effectively cached; once it hits the magic number of 128 or exceeds it,
> each time a file in a directory is accessed, it requires a read of the
> *.dir file.
Well, at our site, the tfm directory contains 671 fonts in a directory
that is 14848 bytes long. This suggests that the max. number of fonts
is about 65536 * 671 / 14848 or 2900 fonts. Of course VMS uses different
data structures no doubt, but I'm using the only figures that I can get
my hands on.
How quickly are TeX fonts proliferating?
> In other words, system performance takes a major whammy and
> benchmarking is nearly out of the question as disk access is a function of
> so many factors that replicating anything once you have to deal with disk
> access issues, you're effectively hosed.
I don't follow. If system performance takes a major whammy, then it would
seem to me that a benchmark would catch it :-). It's minor whammies that
get lost in the noise.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Oct 1994 07:53:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 21 Oct 1994 08:51:57 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
To: TWG-TDS@SHSU.edu
Message-ID: <782743918.15927.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
regarding how many fonts (files) can be held in a single vms
directory, george greenwade has said that as long as the size of
the directory file "stays below 128 blocks, it is effectively
cached". there is also, though i don't remember the exact number,
an absolute maximum on the number of files that can be contained
in one directory -- we've hit it, and everything comes to a
screeching halt. i remember that this happened in a data, not
a font, directory, but getting things into shape to continue
operating was generally unpleasant and time-consuming, especially
since it wasn't expected, we were under a deadline, etc., etc.
i don't actually expect the number of fonts will go this high,
but the possibility is something that shouldn't be omitted
entirely from consideration. we have also, on one of our unix
systems, run out of what our unix guru called (i believe) "file
handles", i.e., named files. another case of lost time.
paul vojts has also questioned george's explanation of why
benchmarking is difficult, if not impossible:
> In other words, system performance takes a major whammy and
> benchmarking is nearly out of the question as disk access is a function of
> so many factors that replicating anything once you have to deal with disk
> access issues, you're effectively hosed.
I don't follow. If system performance takes a major whammy, then it would
seem to me that a benchmark would catch it :-). It's minor whammies that
get lost in the noise.
the problem is, as i see it, that vms systems are usually shared.
if a hundred other people are doing things on the system at the
same time, disk access is going to be entirely demand-fed, and
swapping and paging will affect the cpu time measured, never mind
the randomness of the elapsed time because of other unpredictable
activity. so although it may be obvious that kicking the font
directory over the 128-block boundary takes longer, as george says,
it will be essentially impossible to replicate the actual numbers.
(i don't think i've ever had one of our vms systems all to myself,
even at 3:00 in the morning. there's always something else going on.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Oct 1994 10:35:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 21 Oct 94 16:34:17 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410211534.AA07000@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: public discussion
How come our fonts/source/type discussion is being discussed on c.t.t
before we get the draft to the implementors?
David
=====================================================================
Newsgroups: comp.text.tex
From: pdc@comlab.ox.ac.uk (Damian Cugley)
Subject: Re: what ever happened to the TeX directory structure committee?
Originator: pdc@msc13.comlab
Organization: Computing Laboratory, Oxford University, UK
Date: Fri, 21 Oct 1994 14:10:13 GMT
In article <37tllj$13t0@rs18.hrz.th-darmstadt.de>
schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) writes:
> In article <1994Oct13.153440.16546@msc13.comlab.ox.ac.uk>, pdc@comlab.ox.ac.uk (Damian Cugley) writes:
>> Seriously, how am I supposed to write a document on how to install
>> Malvern fonts when I just do not know what the names of directories
>> are supposed to be yet?
>
> I'll tell you what would have happened: You would have followed a
> draft where the particular issue of font directory layout is under
> discussion again.
In effect I *have* followed a "draft" (in the form of a TeX system I
installed) that was invalidated a week after I announced Malvern 1.2.
The TeX system I installed has "big-endian" font directories, meaning
that "big" entities like foundries are at the top of the tree. The
current status of the TDS discussion (according to my sources) is
little-endian, with the name of the type of file at the top.
(I read the draft -- it still specifies big-endian. don't use
big-endian and littl-endian in the draft, so here's a diagram saying
what I mean:
BIG-ENDIAN LITTLE-ENDIAN
fonts/ fonts/
adobe/ afm/
times/ adobe/
afm/ bitstream/
tfm/ ...
... tfm/
... adobe/
bitstream/ bitstream/
... malvern/
public/ ...
malvern/ mf/
tfm/ malvern/
src/ ...
...
I've used "malvern" as the family name in this example; it would be nice
to be able to include the version ID but then we run out of characters
in the file name.)
I agree that there is no point getting people to use a standard before
it is fully sorted out -- and I said so in part of my original message
deleted above... It's not that I don't appreciate the difficulty of
thrashing out these standards (since I've been peripherally involved in
discussion of 8-character font file names). It's just inconvenient if
this means I have to keep Malvern in limbo for ages. Malvern 1.1 was
delayed for months because I tried to wait for font names to be sorted
out.
"TWG-TDS"... Is there an on-line list of these TWGs and other TLAs?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Oct 1994 12:31:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qyNEP-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 21 Oct 94 17:54 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: public discussion
>How come our fonts/source/type discussion is being discussed on c.t.t
>before we get the draft to the implementors?
Arrrggghh, sorry about that. I'm the leak. I didn't think Damian
would send the contents of my natter on the phone with him to the
whole of c.t.t...
I'll mail him and point out that this is a slightly touchy subject...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Oct 1994 12:44:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410211742.SAA19255@spice.iti.informatik.th-darmstadt.de>
Subject: Re: public discussion
To: TWG-TDS@SHSU.edu
Date: Fri, 21 Oct 1994 18:42:58 +0100 (MEZ)
Content-Type: text
David wrote:
>
> How come our fonts/source/type discussion is being discussed on c.t.t
> before we get the draft to the implementors?
I don't think it's discussed, just mentioned. If you read c.t.t, you
can skip the rest.
As I am cited below, some background: A person asked on c.t.t about
the TDS, I answered in email. Damian made a followup article where he
complained that nothing happens. I don't think that potential users
shouldn't know what happens in the TeX arena before it's finished and
released. (That view might be a bit different from the one the LaTeX
team holds [sorry, could not resist... ;-)].) But being an HCI guy, I
am a True Believer (tm) in a user-centered, iterative, open design
process. Well, I answered in a public f'up that there is still
discussion over that particular point (font dirs) and pointed out
where one can get more information. (This is not secret anyhow as the
mailing list backlog is available over George's gopher server.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Oct 1994 12:53:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410211753.SAA19286@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Fri, 21 Oct 1994 18:53:22 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > If the subdirectories remain, I must change names like `portuguese'
> > since they are too long.
>
> i am happy to wield my unilateral axe again and rename all language
> directories to their babel names, how would that be?
Seems nobody is interested except you and me. :-( I asked Christine
(my partner) and she said that from a user's point she would prefer a
directory with a README that lists all files over a lot of
subdirectories that have only one file.
As Christine is always right, I think we should mention in the TDS
draft that no subdirs are to be expected below tex/initex/hyphen/. (I
assume that the introduction of tex/initex/ is OK as no contrary
opinions were raised.)
Then sebastian doesn't have to run around with an axe, too. Perhaps
that would frighten his two women, and we won't get guilty for that,
do we?
Joachim
[Think I should stop posting in the mood I am today. ;-)]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Oct 1994 04:35:32 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Mon, 24 Oct 1994 09:35:05 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:266920:941024093519"@cl.cam.ac.uk>
initex/hyphen? sounds ok. but Christina isnt quite right - the *users*
dont see this rubbish anyway, do they?
i still prefer to see separate direcories on CTAN, with the files
linking to a single directory for people buidling a Tedious.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Oct 1994 12:00:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410241659.RAA20276@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Mon, 24 Oct 1994 17:59:52 +0100 (MEZ)
Content-Type: text
You wrote:
>
> initex/hyphen? sounds ok. but Christina isnt quite right - the *users*
> dont see this rubbish anyway, do they?
Currently, Christine earns her money being sysadmin over a
heterogenous net of 40 Unix workstations. She is my first test person
when I want to see how new ideas arrive at this class of persons. So
`user' should be read as `admin person', actually.
Nevertheless I think that users will see this particular part of
rubbish. A sysadmin will install (and support) FMT files with a
certain set of hyphenation patterns. If some user wants more, she
may like to create her own FMT file and then she has to look what
pattern files are available in that installation.
> i still prefer to see separate direcories on CTAN, with the files
> linking to a single directory for people buidling a Tedious.
No. Either you want the thing you have now (all files in one
directory) or you want seperate directories. Let's ignore the point
that the files may originate from a complete other CTAN part for the
moment.
We have either:
hyphen/ukhyphen.tex
hyphen/README.ghyphen
hyphen/eshyph.tex
hyphen/f8hyph.tex
hyphen/fhyph.mac
hyphen/fhyph.tex
hyphen/fihyph.tex
hyphen/fr8hyph.dc
hyphen/ghyph31.tex
hyphen/czhyph.tex
hyphen/dkhyph.tex
hyphen/ithyph.tex
hyphen/nehyph1.tex
hyphen/nehyph2.tex
hyphen/nehyph3.tex
hyphen/ishyph.tex
hyphen/lahyph.tex
hyphen/nohyph.tex
hyphen/sehypha.tex
hyphen/pohyph.tex
hyphen/tkhyphart.tex
hyphen/turk_hyf.c
hyphen/ushyph1.tex
hyphen/ushyph2.tex
hyphen/pthyph.tex
hyphen/suhyph.tex
hyphen/tkhyph.tex
hyphen/ukhyph.tex
hyphen/ushyph.tex
or
hyphen/turkish/turk_hyf.c
hyphen/turkish/tkhyphart.tex
hyphen/turkish/tkhypha.tex
hyphen/swedish/sehypha.tex
hyphen/spanish/eshyph.tex
hyphen/portuguese/porthyph.tex
hyphen/polish/hyphen.pol
hyphen/norwegian/norhyph.tex
hyphen/norwegian/nohyphen.tex
hyphen/italian/ithyph.tex
hyphen/icelandic/ihyphen.tex
hyphen/german/ghyph31.tex
hyphen/german/README.ghyphen
hyphen/french/fr8hyph.dc
hyphen/french/fhyph.tex
hyphen/french/f8hyph.tex
hyphen/finnish/fihyph.tex
hyphen/english/ushyphen.tex
hyphen/english/ushyph2.tex
hyphen/english/ushyph1.tex
hyphen/english/ukhyphen.tex
hyphen/dutch/nehyph3.tex
hyphen/dutch/nehyph2.tex
hyphen/dutch/nehyph1.tex
hyphen/danish/dkhyphen.tex
hyphen/czech/czhyphen.tex
(The set of files is not necessarily identical, as I have not updated
the respective archive.) If you want to use the second layout,
shorten some directory names and install it on CTAN. Then we'll use
it for the TDS. ;-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Oct 1994 18:35:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 24 Oct 1994 16:34:53 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410242334.QAA28189@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
I find Paul Vojta's third option fascinating because it is so familiar.
Linking, on systems that allow it, works wonders.
I work on some systems which are so fast that directory searching is no
problem at all. But on others, it is a real pain in the neck. So, every
morning at 4:00 + an arbitrary number of minutes, a crontab kicks in with
a whole series of linke such as
17 4 * * * ( cd /usr/local/lib/texmf/fonts ; /usr/local/bin/link-fonts ./public cx pk 00PK > /tmp/linkings 2>&1 )
00PK 00TFM 00VF and 00XDVI are flat directories full of symbolic links.
link-fonts reads:
#!/bin/sh
#
# This script provides for flat directories organized by function
# as opposed to the organization of fonts by foundry and typeface
# made possible by Karl Berry's kpathsearch. It can also achieve
# a speed-up in the execution of programs like dvips and xdvi
# which depend on kpathsearch. This is often needed with
# old, slow processors or old, slow disk controllers.
#
# A typical directory tree is:
#
# ${TEXFONTS}/
# 00PK/
# 00TFM/
# 00VF/
# 00XDVI/
# adobe/
# utopia/
# afm/
# ps-to-pk/
# src/
# tfm/
# type1/
# vf/
# public/
# cm/
# afm/
# cx/
# ricoh/
# src/
# tfm/
# vf/
#
#
# The 00[TFM,VF,XDVI] directories are flat or "accelerator"
# directories where links to files that are in extremely
# frequent use are placed.
#
# 00PK can also be used as an "accelerator" directory for
# links to frequently used PK files. But don't store write-white
# fonts there unless you are unlucky enough to have a write-white
# printer.
#
# If you want to move the actual font files made
# by MakeTeXPK into the foundry-based tree, select them
# with one or more of the optional predicates in a find command
#
PATH=$1
DIR=$2
FILEXT=$3
WHERE=$4
#
if test "$#" != 4 ;
then
echo " usage: link-fonts <branch> <leaf> <characteristic> <00dir>";
echo " Run this in the common parent TEXFONTS directory";
echo " Where the directories [ 00*] are located ";
echo " <branch> = Relative path to bitmaps. Start with ./";
echo " The closest common path to all desired fonts ";
echo " <leaf> = [ tfm vf type1 cx ricoh ] or similar";
echo " Where the metrics or glyphs are in each branch ";
echo " <characteristic> = [ tfm vf pfa pk ] or similar";
echo " <00dir> = one of [ 00TFM 00VF 00PK 00XDVI ]";
exit 1 ;
fi
#
for i in `/usr/bin/find ${PATH} -name ${DIR} -a -type d -print` ;
do
for j in `/usr/bin/find ${i} -name "*.*${FILEXT}" -print` ;
do
FONT=`/usr/bin/basename $j`
echo $j
(cd ${WHERE} ; /usr/bin/rm -f ${FONT} ; /usr/bin/ln -s .${j} ./${FONT} )
done ;
done
Karl is not enthusiastic about this,because it's messy. That is all
too true, but it is a great way to get performance out of slow messy
machines. On any given day, the full kpathsea is open for any new
addition to the font library, and by the next day the addition is
available in the hurry-up path. ls-R is supposed to do that too, but
PV points out that even ls-R has its price. I much prefer to use
super-fast machines that make pure kpathsea approaches
acceptable---who doesn't---but on a creaky old Sun3-50, this linking
approach gives me the second-best of all possible worlds.
Over and over again we seem to be saying:
"Here is a crummy solution for your hot-shot machine. We realize that it
"is illogical and arbitrary, but se have had to dumb it down to the
"least common capability of the crummiest machines we know about."
What we should be saying is:
"Here is a logical and systematic solution for a more or less ideal
"machine. It may not work on what you have now, but there are ways
"(such as PV's third option) to get around that. As the technology
"improves, you can drop the workarounds and adopt the clean, logical
"solution directly.
Several years ago, Intel had the crummy notion that no one would ever need
to address more than 64K bytes of memory continuously. Motorola
and even that perennial disaster NSC had a better idea, but the
marketing heavyweights put their weight behind the crummy 64K
limitation, and half a dozen other glaring design failures. That
64K nonsense is cast in concrete now, and even when Intel has at last
got past (sort of) the limitation, everyone who uses Intel is still
forced to sacrifice to the 64K god.
The value of PV's option 3 is that it shows how little point there
is in making the same mistake here. Note that the link option gives
the BEST time.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Oct 1994 18:37:41 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 24 Oct 1994 16:37:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410242337.QAA28577@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
Hear, Hear.
I see a certain virtue in suggesting good ways to do this, and even
providing the tools for it.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Oct 1994 18:43:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qzYK9-0006PYC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 24 Oct 94 22:57 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
bcc Damian.Cugley@comlab.oxford.ac.uk
Subject: [Damian.Cugley@comlab.oxford.ac.uk: Comments on TDS 0.49]
Some comments from Damian Cugley on TDS...
--- cut here ---
Chapter 4 says TDS specifies that generic METAFONT files go in
$texmf/tex/mf, whereas in Section 2.1 they are described as going in
$texmf/mf.
The section on subdirectory searching doesn't mention that VMS already
has a syntax for infinite subdirectory searching. It doesn't say if
keeping a database of every file allows for users to add their own
macros directories. (No mention is made anywhere that users might want
to add their own extensions to TeX without having to persuade sysadmins
to do it. There should also be a mechanism for people like me to
prevent the system finding old versions of files in the installed TeX
directory tree when I'm trying to develope new versions.)
The phrase "*user* documentation" is used in the fourth itemized
paragraph in Section 2.1, I guess to distinguish files intended to be
useful to users from those intended to be useful to installers (it was
not obvious from the phrase). But no mention is made of somewhere to
put installation notes (READMEs etc.). Since it is imaginable that more
than one person might be responsible for installing a given TeX system,
it would be a good idea, no?
In the last paragraph of Section 2.1, a "system" name is used to
distinguish directories with binaries for different systems in -- but no
spec is given for "system" names for UNIX TeX compiled for different
platforms; the GNU names (like "sun-sparc-sunos4.1.1") are the only de
facto standard I know of and are not ISO-9660-friendly.
Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
"latex/distrib" and "latex/contrib"; this defeats finite subdirectory
searching and doesn't seem to serve much purpose (unless there are
packages that have both "contrib" and "distrib" versions?). (And using
"latex" instead of "latex2e" raises the issue of whether the "2e" is a
version number or part of the name. Presumably these get renamed
"latex2e" when LaTeX 3 is declared to be the one true LaTeX.)
Chap. 5. How are font family names chosen for existing fonts? The
first par of Section 5.1 has ".../typeface/typeface/...".
Section 5.2, under "dpi" (why isn't that italic?): Which file systems
require that names begin with a letter? (VMS allows zeros, so does
MS-DOS as far as I know. Is it ISO 9660?)
Section 5.2.1 says font files should contain info about resolution and
stuff... what format? How is this info extracted??
Chapter 8 (Packages.) I'm not very happy about being expected to make
subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
have to be copied to under $texmf I can't see that it gains much.
The top-level name for packages, "Malvern-1.3", isn't ISO-9660-friendly;
perhaps the TDS should suggest a way to compress package names into 8
chars (e.g., "malver13"). BTW, it is only this example that we can
infer that package names and font family names do *not* include version
IDs when used as dirnames in TDS (*except* for LaTeX, *except* for the
current version of LaTeX).
I'm not sure I approve of having the "read me" file hidden quite so
thorougly, either. Since packages have to be ISO-9660-friendly and also
workable for MS-DOS/Windows users, perhaps we should settle on
"00readme.txt" as the name for "read me" files? "readme" and "read.me"
will be a pain for Windows File Manager users, whereas ".txt" files can
be read with a double-click... The double-0 prefix is the only way to
put the file at the top of th directory listing. Other installation
files could have single-0 prefix. This assumes at zeros are allowed as
the first character of a file name element.
BTW, the idea of "miscellaneous" is variously expressed as "generic",
"misc", "public" and "general".
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 04:52:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 05:51:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410260951.AA05948@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
Hear, Hear.
I see a certain virtue in suggesting good ways to do this, and even
providing the tools for it.
Pierre, I can't really agree with you here, for a change!
I know why you use your link directories, and of course I think it's
just fine that you've got a working implementation :-) But I would hate
to see such a thing ensconced in a standard.
I see little point in having a TDS at all if it isn't used for
actual file searches. If everyone just creates links in flat
directories, we will have achieved nothing. (In fact, we'll have made
the situation worse, since then there would be another layer of confusion.)
This question is really the crux of the whole TDS issue -- whether there
will be subdirectories. As we started from, long long ago.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 04:52:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 05:51:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410260951.AA05956@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: damian's tds comments
These are good comments.
There should also be a mechanism for people like me to
prevent the system finding old versions of files in the installed TeX
directory tree when I'm trying to develope new versions.)
Put only your directories in the paths?
Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
"latex/distrib" and "latex/contrib"; this defeats finite subdirectory
The latex folks don't want to change. So far as I know.
Chap. 5. How are font family names chosen for existing fonts?
They look at my list? fontname 2.0 will have this in machine-readable form.
Which file systems require that names begin with a letter? (VMS
allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
Someone early on -- Norm, I think -- said ISO-9960 is
beginning-with-a-letter only.
Section 5.2.1 says font files should contain info about resolution and
stuff... what format? How is this info extracted??
For Metafont fonts, you get it automatically if you use modes.mf.
The idea is just to include specials like
mode=cx
dpi=600
in the GF/PK file.
modes.mf has the particulars.
As for how it's extracted, they are just specials like others. They're
not used by any program, so far as I know, but they are sometimes
helpful when you're trying to track down the origin/meaning of a given
PK file that has popped up.
Chapter 8 (Packages.) I'm not very happy about being expected to make
subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
have to be copied to under $texmf I can't see that it gains much.
The idea is that then installation becomes very simple:
cd Malvern-1.3; cp -r fonts tex ... $texmf
If the distribution flattens the tree, an installation script or
something has to expand it again.
Whether or not the subdirectory trees will make it into the final tds, I
don't know, but the basic idea of making the installer's job simple
seems a good one.
The other win of having a TDS structure in the distribution is that
conceivably people could experiment with having *packages* under texmf,
instead of file types. We had a long debate about this. If you're really
interested, it's in the archives.
The top-level name for packages, "Malvern-1.3", isn't ISO-9660-friendly;
Doesn't matter, because Malvern-1.3/ isn't going to be a name on
anyone's CD-ROM or in the tds tree. Keep that name for what your tar
file unpacks into.
perhaps the TDS should suggest a way to compress package names into 8
chars (e.g., "malver13").
I don't think it needs to. Top-level distribution names in tar files can
continue to be meaningful, not DOS-ified. At least I haven't heard any
convincing arguments to the contrary.
BTW, it is only this example that we can
infer that package names and font family names do *not* include version
IDs when used as dirnames in TDS
That should be said, I suppose.
(*except* for LaTeX, *except* for the
current version of LaTeX).
LaTeX is the only case -- isn't it? -- where a significant number of
people, right here and right now, want to support two different versions
simultaneously. Thus it is a special case.
At least that's the claim. I don't know what the reality is. I
personally wouldn't mind if the whole latex2e vs. latex209 thing went
away, and the TDS just had `latex', like everything else.
perhaps we should settle on "00readme.txt" as the name for "read me"
files?
I can buy this argument for monocase filesystems. For distributions like
tar files, I just can't bring myself to mangle filenames that badly.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 06:29:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 11:27:13 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261127.AA02142@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
> Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
> "latex/distrib" and "latex/contrib"; this defeats finite subdirectory
> The latex folks don't want to change. So far as I know.
Actually I think it was mainly `me' rather than `the latex folks'.
Looking at how I've set this up locally I notice that I havent followed
my own suggestion.
Since I made the suggestion for the split we have changed latexbug.tex
to prompt people which `category' (aka ctan directory) the bug report
is for. The list of supported directories is now made explicit by
latexbug, like this:
Several categories of files are supported,
corresponding to directories in the standard LaTeX distribution:
0) base: The format itself, and the main classes such as `article'.
1) tools: Packages supported by the LaTeX3 project team.
2) graphics: The color and graphics packages.
3) mfnfss: Packages for using MetaFont fonts with NFSS (ie LaTeX2e).
4) psnfss: Packages for using PostScript fonts with NFSS (ie LaTeX2e).
5) amslatex: Classes and Packages supported by the AMS.
6) babel: Packages supporting many different languages.
Please select a category 0--6:
So there is now less need to make it clear which directories are
`supported' by us using the TDS tree.
So personally I would remove my objection to
...latex/base % supported by us
...latex/tools % supported by us
...latex/amslatex % supported by us/AMS
...latex/seminar % supported by Tim Van Zant
etc
Alan?
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 07:53:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 12:53:35 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261253.AA02904@boothp1.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu, kb@cs.umb.edu
Subject: Re: damian's tds comments
CC: Damian.Cugley@comlab.oxford.ac.uk
>> Which file systems require that names begin with a letter? (VMS
>> allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
> Someone early on -- Norm, I think -- said ISO-9960 is
> beginning-with-a-letter only.
This would be very unfortunate. Without the "00" prefix there is no way
to make a "read me" file go near the top of the directory listing short
of calling it "aaron.txt" or something...
I haven't got a copy of ISO 9660, but here's what the CD-ROM FAQ says:
# Level one ISO-9660 is similar to an MS-DOS filesystem. Filenames are
# limited to eight single-case characters, a dot, and a three character
# extension. Only single case letters, numbers, and
# underscores. Directory names cannot have the three digit extension,
# just eight single-case characters.
# [...]
This doesn't explicitly state that digits are OK as the first character
but I'd expect it to say if they were not. So I poked around the
ftp.cdrom.com archive, and their CD-ROMs *do* use names like
"00_INDEX.TXT" and "00_CAT_0.TXT".
> LaTeX is the only case -- isn't it? -- where a significant number of
> people, right here and right now, want to support two different versions
> simultaneously. Thus it is a special case.
Yes, this makes sense.
I would have expected to see the LaTeX 2e directories called
"latex2e/*trib", since (I'm told) the "2e" in "LaTeX 2e" is *not* a
version number (!). Also, when LaTeX 3 is installed as, old LaTeX 2e
files would not need renaming.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 09:29:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 13:59:46 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261359.AA02946@boothp1.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu, kb@cs.umb.edu
Subject: Re: damian's tds comments
CC: Damian.Cugley@comlab.oxford.ac.uk
>> Which file systems require that names begin with a letter? (VMS
>> allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
> Someone early on said ISO-9960 is beginning-with-a-letter only.
This would be very unfortunate. Without the "00" prefix there is no way
to make a "read me" file go near the top of the directory listing short
of calling it "aaron.txt" or something...
I haven't got a copy of ISO 9660, but here's some of what the CD-ROM FAQ
says:
# Level one ISO-9660 is similar to an MS-DOS filesystem. Filenames are
# limited to eight single-case characters, a dot, and a three character
# extension. Only single case letters, numbers, and
# underscores. Directory names cannot have the three digit extension,
# just eight single-case characters.
# [...]
This doesn't explicitly state that digits are OK as the first character
but I'd expect it to say if they were not. So I poked around the
ftp.cdrom.com archive, and their CD-ROM file lists include names like
"00_INDEX.TXT" and "00_CAT_0.TXT". So it looks like ISO 9660 does allow
leading digits.
Is there some other modern file system that specifies file name
components must start with a letter?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 09:35:56 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r09NC-00006xC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 26 Oct 94 14:30 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
>So personally I would remove my objection to
>...latex/base % supported by us
>...latex/tools % supported by us
>...latex/amslatex % supported by us/AMS
>...latex/seminar % supported by Tim Van Zant
>etc
>Alan?
Fine by me.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 09:40:09 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r09Up-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 26 Oct 94 14:38 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
> Chapter 8 (Packages.) I'm not very happy about being expected to make
> subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
> tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
> have to be copied to under $texmf I can't see that it gains much.
One of the possibilities is that on CTAN, Malvern will have tfm/
latex/ fd/ etc. directories plus some mechanism for saying where these
live in TDS. Then CTAN provides a new extension (say tds.tar) so
that when I get malvern.tds.tar I get a tar file which I can unpack
with:
cd $TEXMF
tar -xvf malvern.tds.tar
and everything will go in the right place. Of course this may just be
a pipe dream...
>At least that's the claim. I don't know what the reality is.
The reality is that at almost every meeting the L3 team goes to, one
of the first questions to be asked is `can I run 2e and 2.09 in
parallel'.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 11:45:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 09:42:20 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261642.AA17144@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: 0.doc, etc.
> Someone early on -- Norm, I think -- said ISO-9960 is
> beginning-with-a-letter only.
Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
problem we have had with this is that one set of mastering software
could not deal with it. The vendor acknowledged that this was a bug.
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 11:51:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 16:50:29 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261650.AA02487@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: Re: 0.doc, etc.
[Norm, are you around?]
> Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
> problem we have had with this is that one set of mastering software
> could not deal with it. The vendor acknowledged that this was a bug.
Norm's original comment on this was that *Directories* could not begin
with a digit, hence dp1300 but presumably *files* like 00readme.txt
are OK.
Presumably the documentation for this exists somewhere...
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Oct 1994 12:01:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 12:58:09 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410261658.MAA18670@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.doc, etc.
References: <9410261642.AA17144@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 26 October 1994 at 09:42:20, Rich Morin wrote:
>
> > Someone early on -- Norm, I think -- said ISO-9960 is
> > beginning-with-a-letter only.
>
> Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
> problem we have had with this is that one set of mastering software
> could not deal with it. The vendor acknowledged that this was a bug.
My error, I guess. Maybe the guy who masters for us had that version
of the mastering software ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Oct 1994 12:07:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410281706.SAA14341@spice.iti.informatik.th-darmstadt.de>
Subject: More on Damian's TDS comments
To: Damian.Cugley@comlab.ox.ac.uk
Date: Fri, 28 Oct 1994 18:06:28 +0100 (MEZ)
CC: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Content-Type: text
Damian wrote:
>
> BTW, the idea of "miscellaneous" is variously expressed as "generic",
> "misc", "public" and "general".
Actually, it isn't.
generic -- stuff that works with all TeX macro formats
public -- vendor of freely distributable fonts
misc -- directory for single file distributions
general -- documentation that does not concern one specific
system;
I don't want to defend the last one, as I think it's unnecessary;
`misc' is clearly the one you mentioned; but let's look at the first
two items. I consider neither `generic' nor `public' as
``miscellaneous'', but rather as very specific terms. The files
therein are not `the rest where we couldn't find or make a category
for', as it is with files in misc/.
We had already discussions about these two names. Do you have any
idea about other names that convey the information mentioned above?
(Of course, the names have to restricted to 8 letters, due to @$#!%
ISO-9660.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Oct 1994 13:52:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Oct 1994 14:51:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410281851.AA17333@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: fonts/public
public -- vendor of freely distributable fonts
Alan et al. convinced me long ago that this was not a good name, because
the idea behind that directory is really `fonts created/distributed by
people/organizations who only have a few', not `freely distributable'.
Copying conditions should be irrelevant to the directory names; it is
just chance that all the fonts in public/ are also free.
My only argument for having ams/ as a separate source is that the
amsfonts is a well-separated distribution that is being maintained. And
there are half-a-dozen or so typefaces, so ...
Whether Knuth or Yannis or Damian or Texplorators or whoever should get
their own directory is something I don't feel too strongly about. I
don't see much point to proliferating source directories unnecessarily,
but on the other hand it doesn't make any difference to me.
However, much more important than precisely what source directories will
be under fonts/ (at whatever level) is whether
(a) we're going to require subdirectory searching at all; and if so,
(b) whether fonts/type/source/typeface/dpiNNN/*.type got agreed on, or
if the debate is continuing.
There is no point in discussing (b) until (a) is resolved -- and so far
as I can see, saying `no subdirectory searching' is the only way to
guarantee compatibility with existing implementations and reasonable
startup time (except, perhaps, on VMS).
Watch out. I just had an idea.
It's not subdirectory searching per se that matters. It's being able to
find fonts in the tree. What about these wonderful %-specifiers that
some implementations (xdvi, dvips, mctex, emtex?, ...?) already do?
Wouldn't that be a more efficient (not to mention politically
acceptable) way of finding fonts in a deep tree than the horrendous mess
I've gotten myself into with ls-R, etc.? (I'm exaggerating for effect.)
So how about a path specification like this (illustrative purposes only, not
trying to suggest syntax):
PKFONTS = $TEXMF/fonts/%s/%t/dpi%d/%f.pk
Well ... the crux of the matter is the %s to get the source name and the
%t to get the typeface name (cm, etc.). The only way I can see do that
is to use a separate mapping file (which I've already constructed).
(If you're willing to require one-level subdirectory searching, the %s
could become * or whatever.)
I should say I'm not trying to suggest the TDS would specify this (or
any other searching method). We would just specify how the tree looks,
as usual. I'm only bringing this up because people are (entirely
reasonably) objecting to the subdirectories based on current
implementations -- so here's another search method.
Does this help anything?
Karl, making one last try at saving fonts/source ...
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Oct 1994 18:23:44 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r10ch-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 28 Oct 94 23:22 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
> public -- vendor of freely distributable fonts
>Alan et al. convinced me long ago that this was not a good name, because
>the idea behind that directory is really `fonts created/distributed by
>people/organizations who only have a few', not `freely distributable'.
>Copying conditions should be irrelevant to the directory names; it is
>just chance that all the fonts in public/ are also free.
Yes, I'll say it again, organizing fonts by cost is not the most
logical arrangement. Lets have the big font distributors (Adobe,
Linotype, Monotype) plus the big font developers for TeX (AMS, DEK)
and perhaps a few others, and bung everything else under misc.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Oct 1994 19:32:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 28 Oct 1994 17:31:54 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410290031.RAA23679@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
I guess I always tacitly assumed that public was short for
public domain. Which isn't exactly true in the case
of fonts licensed under GNU Copyleft, but near enough.
The practical division is not clean, because you could
argue that adobe, bitstream, IBM and urw have made a selection
of fonts (utopia---part, charter, courier, nimbus/times etc.)
effectively public domain, though they retain licenses in the
comments at the head of the files.
But we have been using p
But we have been using public/ to indicate fonts that it is
always safe to pass on with no explicit concern for licensing,
and even though this can be done for part of adobe courier,
(sorry, I mean Adobe utopia) it remains that most of what
comes under adobe is subject to licensing. Nothing that
I ever consider putting under public/ is subject to
licensing except for a couple of cases where licenses are
required for *commercial* profit-making use.
When does a font developer become a BIG developer. Where
for instance does N. Billawala fit? Where does Tom Ridgeway
fit. Is Klaus Lagally a misc, or a BIG developer?
and if he is a BIG developer, is he "arabtex" or "lagally?"
It isn't cost which drove the development of the present
ad-hoc division, it is the question of licensing restrictions.
THe division isn't ruthlessly logical, but it is sort of
understandable.
Pierre
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Oct 1994 19:42:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Oct 1994 20:41:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410290041.AA20530@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
But we have been using public/ to indicate fonts that it is
always safe to pass on with no explicit concern for licensing,
That's a good point. I hadn't thought about that as an advantage of
`public' :-) That is actually of some value.
It's ok with me to put everything under `public' -- there just aren't
that many freely available typefaces out there that the directory would
get huge.
When does a font developer become a BIG developer. Where
Well, if we do adopt this, something like
more than half a dozen typefaces or so?
I don't think we need to make a hard-and-fast rule.
Just categorize everything on CTAN now, and let it go at that.
What happens in the future will follow along.
for instance does N. Billawala fit?
Since she's only got one, pandora/ will be under misc/ no matter what.
Where does Tom Ridgeway
fit. Is Klaus Lagally a misc, or a BIG developer?
and if he is a BIG developer, is he "arabtex" or "lagally?"
Don't know these ...
Which isn't exactly true in the case
of fonts licensed under GNU Copyleft, but near enough.
I don't think there are any copylefted fonts. Are there?
================================================================================
From owner-twg-tds@shsu.edu Sun, 30 Oct 1994 02:19:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410292018.VAA14820@spock.iti.informatik.th-darmstadt.de>
Subject: Re: fonts/public
To: TWG-TDS@SHSU.edu
Date: Sat, 29 Oct 1994 21:18:49 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> public -- vendor of freely distributable fonts
>
> Alan et al. convinced me long ago that this was not a good name, because
> the idea behind that directory is really `fonts created/distributed by
> people/organizations who only have a few', not `freely distributable'.
> Copying conditions should be irrelevant to the directory names; it is
> just chance that all the fonts in public/ are also free.
Oh yes, I remember. Then Damian was right: it's misc/. Let's give DEK
his own directory, to escape those TPC discussions, and rename public/
to misc/.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sun, 30 Oct 1994 03:19:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410292016.VAA14808@spock.iti.informatik.th-darmstadt.de>
Subject: Re: fonts/public
To: TWG-TDS@SHSU.edu
Date: Sat, 29 Oct 1994 21:16:18 +0100 (MEZ)
Content-Type: text
Karl made
>
> one last try at saving fonts/source ...
that I applaude wholeheartly.
> So how about a path specification like this (illustrative purposes only, not
> trying to suggest syntax):
> PKFONTS = $TEXMF/fonts/%s/%t/dpi%d/%f.pk
If anybody wants C routines that support the specification above, I
will supply it immediately. An excerpt from the header file is below.
The routines are tested, they are actually in use at thousands of
sites that use our software.
Actually, Karl's got a very good point: You do *not* need full
subdirectory searching for the fonts/source layout if you use the TDS
layout, as you know *exactly* where <type> directories could be.
The discussion is open again... :-)
Joachim, TeX anarchist
----------------
FYI, the declarations of the functions mentioned above. The `funny'
names EXTERN_C etc. are introduced to be able to use such
declarations with ANSI C, K&R C, and C++ compilers. Their actual
definition should be obvious to any C programmer...
EXTERN_C C_String xstr_expand PROTO(( Const_string s ));
/*
* Input: s --- string which shall be expanded
* Returns: New string with all expansions done.
* The new string is malloc() compatible.
* This function does not return if not enough memory is available.
* Then an fatal error message is issued via fatal_msg().
* Description: Substrings of 's' which have the form $name or ${name}
* are substituted by the value of the environment
* variable with the respective name. `name' consists of
* letters, digits, and underscores. If it is written in
* the first form (ie, without surrounding braces), the
* first non-letter, non-digit, or non-underscore
* terminates the name.
*/
EXTERN_C C_String xstr_format_expand PROTO((
Const_string format,
Const_string varinfo,
Const_string *param ));
/*
* Input: format -- a printf-like format string
* varinfo -- a string with one expansion character for each
* element in param
* param -- a vector of parameters to substitute
* Returns: a new string with all expansions done.
* The new string is malloc() compatible.
* This function does not return if not enough memory is available.
* Then an fatal error message is issued via fatal_msg().
* Description: Every `%'c sequence in `format' is replaced by the i'th element
* of `param', if `c' is the i'th element in `varinfo' or with a
* single `%' character if `c' equals `%'.
* An error message is issued via err_msg(), if `c' is not
* contained within `varinfo'.
*/
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From owner-twg-tds@shsu.edu Thu, 03 Nov 1994 13:44:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 3 Nov 94 18:00:55 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411031800.AA08367@booth5.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: TDS / Packages (Re: damian's tds comments)
CC: Damian.Cugley@comlab.oxford.ac.uk
(Hope you don't mind my posting to this list again.) In my comments on
TDS draft 0.49 which Alan forwarded to the list, I said
> Chapter 8 (Packages.) I'm not very happy about being expected to make
> subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
> tarfiles instead of just "Malvern-1.3/tfm".
I'm beginning to be persuaded that TDS-styloe subdirs in the package
tarfile makes some sense. one of the packages I was thinking of making
was one called "narrowtt" that would have narrow versions of Computer
Modern TT and Courier; a TDS-like directory structure would make it
easier for installers to select which components of this package to
install.
I don't like deep directory structures because they make it hard to find
files when browsing through them (consider someone using an FTP
front-end or WWW browser, where you can only "move" one directory at a
time). I mention this because it occurs to me that if you put fonts in
a little-endian directory tree *and* use names "mf" and "pl" for
METAFONT and PL sources, then the "fonts" name element becomes
redundant. You could have names like
$texmf/tfm/malvern/ma55a10.tfm
$texmf/mf/malvern/ma55a10.mf
etc.
This is consistent with the "tex" and exiting "mf" directory; the
general rule is that files of type TYPE go in "$texmf/TYPE".
To find all TeX font packages installed, you do "ls $texmf/tfm" (or "DIR
$TEXMF\TFM" etc.).
I was thinking about the "SOURCE/TYPEFACE" directory names for fonts in
the context of these narrowtt fonts. Would a set of "crrrn" (Courier
Narrow) fonts go in "adobe/courier"? What if some other person comes up
with a different "Courier Narrow" of his or her own?
It might make sense to instead talk of "$texmf/tfm/PACKAGE/foo.tfm",
where PACKAGE is a package name (for fonts distributed as a package) or
is "SOURCE/FAMILY" for commerical fonts. Then I might have
(hypothetically)
$texmf/tfm/narrowtt/ct57ah10.tfm
$texmf/tfm/narrowtt/pcrrrn.tfm
etc.
Finally, Malvern and Fontinst both include "contrib" directories, where
files relevant to the package contributed by oither people go. Will TDS
have an official policy on where these "optional" directories get installed?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
From owner-twg-tds@shsu.edu Fri, 04 Nov 1994 12:06:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 4 Nov 1994 13:02:53 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411041802.NAA24025@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Going away...
Reply-To: TWG-TDS@SHSU.edu
Folks,
I'm going away to SGML'94 next week. I have the draft, a portable,
and all the messages since September with me and I *really* hope to
have a new draft done when I return.
Thanks for your patience everyone...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 12:57:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 13:53:52 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411181853.NAA02169@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New draft available...
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/ftp/private/*
You only need twg-tds.*, but I also made the SGML files available again...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | A successful tool is one that was used to do
Production Tools Specialist | something undreamed of by its author. -- S. C.
O'Reilly & Associates, Inc. | Johnson
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 13:23:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 14:19:35 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411181919.OAA02288@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: New draft available...
References: <199411181853.NAA02169@jasper.ora.com>
Reply-To: TWG-TDS@SHSU.edu
On 18 November 1994 at 13:53:52, Norman Walsh wrote:
> ftp://jasper.ora.com/ftp/private/*
I goofed, it's in
ftp://jasper.ora.com/ftp/private/twg-tds/*
^^^^^^^
Sorry for the confusion...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 14:31:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 15:27:45 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411182027.PAA02731@jasper.ora.com>
To: twg-tds@shsu.edu
CC: mackay@cs.washington.edu (Pierre MacKay)
Subject: Re: New draft
References: <199411182025.MAA06026@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 18 November 1994 at 12:25:48, Pierre MacKay wrote:
>
> Is ./texmf/tex/mf really what we have
> decided on for miscellaneous non-font mf files?
> (It doesn't matter all that much, but I wondered whether it was a
> typo)
Looks like a typo to me. I meant /texmf/mf
I should point out: I did all this work on a portable where I couldn't
see the results of what I was doing so there may be similar problems
in other places.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 14:32:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 15:28:46 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411182028.PAA02743@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Joachim's proposal for fonts/source...
Reply-To: TWG-TDS@SHSU.edu
I don't recall anyone commenting on Joachim's proposal that fonts/source
would work because the paths below fonts/source could be easily constructed
by substitution.
Does anyone have any comments?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 14:48:36 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 18 Nov 1994 12:48:40 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411182048.MAA08572@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
I'll have to check back on what Joachim proposed, but I am, as always,
extremely eager to preserve fonts/source if at all possible.
I think we will have to offer rather more on the doc/<caategory>
tree. I am not absolutely sure I understand it as it stands,
and the martian example does not appear to conform unless martian
is both a category and a package.
Shouldn't it be:
martian-1.0/doc/latex/martian/martdoc.tex
/example.tex
with the possible addition of:
martian-1.0/doc/ps/martian/martdoc.ps % for people who want to read it FIRST
Should there be also:
martian-1.0/doc/readme/martian/read.me
or should we assume that read-me files are throwaways?
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 14:48:38 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 18 Nov 1994 12:48:40 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411182048.MAA08572@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
I'll have to check back on what Joachim proposed, but I am, as always,
extremely eager to preserve fonts/source if at all possible.
I think we will have to offer rather more on the doc/<caategory>
tree. I am not absolutely sure I understand it as it stands,
and the martian example does not appear to conform unless martian
is both a category and a package.
Shouldn't it be:
martian-1.0/doc/latex/martian/martdoc.tex
/example.tex
with the possible addition of:
martian-1.0/doc/ps/martian/martdoc.ps % for people who want to read it FIRST
Should there be also:
martian-1.0/doc/readme/martian/read.me
or should we assume that read-me files are throwaways?
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Nov 1994 15:04:42 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r8aPw-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 18 Nov 94 21:00 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
>I don't recall anyone commenting on Joachim's proposal that fonts/source
>would work because the paths below fonts/source could be easily constructed
>by substitution.
Easy if you have a reverse look-up table that tells you that
to find ma55a10.tfm you should look in misc/malvern/tfm. Unless we're
going to mandate that fonts have to be named according to KB's scheme
(which will not win us friends) such a look-up table is effectively a
hash/ls-r/cache/etc.etc.etc.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 21 Nov 1994 06:08:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 21 Nov 94 12:07:55 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411211207.AA10526@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: New draft available...
<title>A Directory Structure for Implementation-Independent
&TeX; Files<?lb>Version 0.50</>
Months of discussion and we are still only half way there....
<para>
To avoid different implementations having different syntaxes for
specifying recursive subdirectory searching, the TWG recommends
that subdirectory searching be specified by a doubled
directory separator. For example, the &unix;-style pathname
There was some debate as to whether this was desirable or possible on
all systems, and in any case I can not see any large advantages in
having this standardised across systems, as the rest of the directory
syntax is not standard across different OS. Perhaps instead say:
<para>
One possible syntax for specification of recursive directory
searching is by a doubled
directory separator. For example, the &unix;-style pathname
In addition, filenames may only contain letters,
digits and underscores and must begin with a letter.
Directory names may not have extensions.
</para>
There was some discussion as to whether this `begin with letter'
constraint is really in ISO 9660. Does anyone have any real
documentation on this?
<para>
The &tds; is rooted at a directory called <filename role=dir>texmf</>.
The location of
this directory within the file system is up to the installer. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>. On PC networks, this could map to a
logical drive specification, for example <filename role=drive>T:</>.
</para>
I am not sure that this captures what I (thought) was decided.
In particular the two cited examples are rather different, I think
that the suggestions are
/usr/local/texmf/
t:/
but I would read the above paragraph as suggesting
/usr/local/texmf/
t:/texmf/
Perhaps something like
<para>
The root of the &tds; should be a directory only containing &TeX;
related material. In this document we shall assume that this directory
is called called <filename role=dir>texmf</>, although the exact name
of the directory is up to the installer. On PC networks, this could
map to a logical drive specification, for example
<filename role=drive>T:</>.
</para>
<para>
Similarly the location of
this directory within the file system is site-dependant. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>.
</para>
... or something...:-)
Fonts Chapter.
There is no `is there a Better Way?' section here, ie all mention of
our discussions over fonts/type fonts/source has been deleted.
I know this is difficult to phrase, and I objected to the last draft which
tried to summarise both sides of the discussion, but I do think it
should say something (not sure what...)
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 21 Nov 1994 12:09:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 21 Nov 94 09:06:45 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411211706.AA12923@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: New draft available...
I'm working on finding a relatively definitive statement on ISO-9660 file
naming. At this point, all I can say is that *I've* used files like 0.doc,
and that when we encountered some pre-mastering software that couldn't
handle them, the vendor fixed it!
I'm a bit confused by the "syntaxes for specifying recursive subdirectory
searching". It appears to me that there are three rough possibilities here:
1. Allow each implementation to go its own way.
This way lies madness!!!
2. Standardize by OS (i.e., one standard syntax for each target OS).
In this scenario, UNIX uses "/a/b//" while MS-DOS uses "c:\a\b\\".
Note that the fact that both OS's use a doubled separator is just
a mnemonic aid here; the UNIX syntax is still incompatible with
the DOS syntax.
3. Standardize across all target OS's.
Pick some syntax that can be translated to every OS now existing.
Hope that all future cases can be handles, as well. Ask the folks
writing the implementations to accept and translate as needed.
My reaction to all this is that (2) is probably OK, and that the use of
a doubled separator is a nicety, but not a necessity. In particular, if
the doubled separator would cause confusion on a given OS, it should be
punted in favor of some other syntax.
Option (3) seems fraught with peril, and I'm not sure how necessary it is.
That is, I don't think these path specification are supposed to go into
TeX files, so it isn't really a portability issue. Is this correct?
The cost of symbolic links in UNIX is not "negligable". Each link takes
up a disk block (typically 1 KB). If we're talking about thousands of
files, this can add up. Also, traversing a symbolic link takes some time.
I don't see either of these points as crippling, but they deserve noting.
BTW, UNIX also allows the use of "hard links" within a given file system
(disk partition, roughly). These ARE essentially free to use.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 21 Nov 1994 15:02:25 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r9fqE-00007DC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 21 Nov 94 21:00 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: New draft available...
> 1. Allow each implementation to go its own way.
> This way lies madness!!!
This way seems the only way to go... I don't think it's our job to say
how implementors should implement configurations. I see no way of
getting OzTeX and Textures (for example) to agree on a way of
specifying directories, the two programs are just too different. I
don't see what the gain is in specifying how configuration should be
done, and I can see problems.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 22 Nov 1994 11:49:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 22 Nov 1994 09:49:28 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411221749.JAA03498@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
In hopes that we can hurry along the development of a usable
basic TEXMF tree, I have run the UnixTeX texmf/ listing through
some scripts to identify 8+3 problems. I have already changed
the files that are directoy under my control, (it is extremely
annoying not to be able to refer to TeX3.1415), and here is the
residuum. I could take arbitrary action, but I don't want to.
I want to have the texmf part of the UnixTeX files as close as
possible to the TDS. (I am not even going to look at the rest
of the UnixTeX files. Only the texmf tree.)
./texmf/tex/latex/packages/babel/babel-new.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/babel/tb-article.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/tools/afterpage.dtx TOOLONG
./texmf/tex/latex/packages/tools/enumerate.dtx TOOLONG
./texmf/tex/latex/packages/tools/indentfirst.dtx TOOLONG
./texmf/tex/latex/packages/tools/longtable.dtx TOOLONG
./texmf/tex/latex/contrib/supported/epsfig/README.unix TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/mflogo/mflogo.readme TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/ssqquote/ssqquote.readme TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/subeqnarray/subeqnarray.dtx TOOLONG DIR&NAME
./texmf/tex/latex/contrib/supported/subeqnarray/subeqnarray.ins TOOLONG DIR&NAME
./texmf/tex/latex/misc/doublespace.sty TOOLONG
./texmf/tex/latex/misc/doublespace2.sty TOOLONG
./texmf/tex/latex/misc/nopagenumbers.sty TOOLONG
./texmf/tex/latex/misc/supertabular.doc TOOLONG
./texmf/tex/latex/misc/supertabular.sty TOOLONG
./texmf/tex/latex/misc/supertabular.tex TOOLONG
./texmf/tex/plain/fontchart.tex TOOLONG
./texmf/tex/tugboat/germanhyph.tex TOOLONG
./texmf/tex/tugboat/landscape.sty TOOLONG
./texmf/fonts/public/pandora/src/panaccent.mf TOOLONG
./texmf/fonts/public/pandora/src/pangreeku.mf TOOLONG
./texmf/fonts/public/pandora/src/panlowers.mf TOOLONG
For pandora, I suggest panacc.mf, pangrk.mf and panlwr.mf (or even panlower.mf)
It should be possible to straighten this out quickly. Maybe some of it
has already been straightened out. I have not yet succumbed to
the /texmf/fonts/function/source arrangement because I still
hope that it can be avoided. It is such a bummer.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Tue, 22 Nov 1994 14:06:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 22 Nov 94 18:13:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411221813.AA11670@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
./texmf/tex/latex/packages/babel/babel-new.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/babel/tb-article.tex HYPHEN,TOOLONG
I'll forward these to Johannes, I expect changing these will not be a
problem.
./texmf/tex/latex/packages/tools/afterpage.dtx TOOLONG
./texmf/tex/latex/packages/tools/enumerate.dtx TOOLONG
./texmf/tex/latex/packages/tools/indentfirst.dtx TOOLONG
./texmf/tex/latex/packages/tools/longtable.dtx TOOLONG
It was decided, after much worrying, *not* to change these names. I
actually did change them before the release of 2e, and all the
internal documentation to match, but we decided to change back, not
least because too many books have been printed with the full names in.
> /contrib/supported
Anyone got any suggestions for a shorter name? Another possibility is
to drop the supported-other distinction, and put everything in
contrib, one level up. (Joachim??)
All the rest are contributed by assorted authors, so changing the
names means contacting them and asking them to change, I think ctan
can not really just change the names of contributed files.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 22 Nov 1994 15:11:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411222111.WAA18186@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Joachim's proposal for fonts/source...
To: TWG-TDS@SHSU.edu
Date: Tue, 22 Nov 1994 22:11:42 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >I don't recall anyone commenting on Joachim's proposal that fonts/source
> >would work because the paths below fonts/source could be easily constructed
> >by substitution.
>
> Easy if you have a reverse look-up table that tells you that
> to find ma55a10.tfm you should look in misc/malvern/tfm.
No.
The point of discussion was
1. developers won't implement pruning
2. developers are willing to implement subdirectory searching.
3. full subdirectory searching is too slow for fonts/source
organization
Why is it said to be so slow? Because it was said that one does not
know where <type> directories could be, one has to search the full
file tree for it. (Under the assumption of no pruning.) It was said,
in the fonts/type mimic we know it.
I mentioned that we *do* know where <type> directories are in TDS, we
don't need full directory searching. In fact, we need only one-level
searching.
As an example, the pattern "texmf/fonts/*/tfm/%f.tfm" names each TFM
file (tagged as `%f') with one level of subdirectory searching
(marked with `*'). The pattern "texmf/fonts/*/%t/%d/dpi%r/%f.%t" names
a font file %f (of type %t, for device %d, resolution %r) with one
level of subdirectory searching (again, marked with `*').
NOTE 1: We don't need full subdirectory searching as long as we use
only TDS structure.
NOTE 2: Only POSIX.2 conformant functions are needed to implement the
pattern above. I.e., it's portable, folks.
NOTE 3: Many drivers already use such patterns, anyhow, to construct
font names. It is not a new concept.
Sorry, Alan, but your arguments don't hold water. If you're against
patterns, you're against subdirectory searching at all.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Nov 1994 09:11:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 NOV 94 15:02:42 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Another idea for e-TeX: \traceingfileio
Message-ID: <2023A84F_002C11B0.00987E6BBA4E0E7A$19_4@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
Having put up the so-called `patch level 4' of LaTeX-2e, I found it expedient
to allow full sub-directory searching... This was a mistake, since LaTeX-2e
proceeded to find LTHyphen.Cfg in some arcane unsupported Cyrillic
sub-directory, but that is by the by...
Rather more importantly, TeX can now appear to take a finite-but-unbounded time
to find a file that it used to find almost instantaneously. So what I propose,
specifically bearing in mind the possible requirements of TWG-TDS, is a new
primitive \tracingfileio: differing positive values would cause greater or
lesser verbosity, but basically it would shew each attempt to open a file,
including the particular path which it is currently traversing. I would
suggest that one use of the granularity be to differentiate between
\input, \openin and \font (have I missed any?).
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 24 Nov 1994 04:49:34 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Date: Thu, 24 Nov 1994 10:49:01 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:076360:941124104936"@cl.cam.ac.uk>
> ./texmf/tex/latex/contrib/supported/epsfig/README.unix TOOLONG DIR&SU
the epsfig package should not be there; please zap it. its now part of
the standrad graphics package
> ./texmf/tex/latex/misc/doublespace.sty TOOLONG
> ./texmf/tex/latex/misc/doublespace2.sty TOOLONG
yuck. who supports these? i think no-one. we can take unilateral
action? but the Companion mentions doublespace
> ./texmf/tex/latex/misc/supertabular.doc TOOLONG
> ./texmf/tex/latex/misc/supertabular.sty TOOLONG
> ./texmf/tex/latex/misc/supertabular.tex TOOLONG
i understand David is doing a supertab emulation, so the package
should go?
> ./texmf/tex/plain/fontchart.tex TOOLONG
blame Don
> ./texmf/tex/tugboat/germanhyph.tex
you should not have this. zap it
> ./texmf/tex/tugboat/landscape.sty TOOLONG
zap it
> ./texmf/fonts/public/pandora/src/panaccent.mf TOOLONG
> ./texmf/fonts/public/pandora/src/pangreeku.mf TOOLONG
> ./texmf/fonts/public/pandora/src/panlowers.mf TOOLONG
bllody Pandora. why doesnt sonme sort out its naming?
> For pandora, I suggest panacc.mf, pangrk.mf and panlwr.mf (or even
> panlower.m
i say just do it, and pass to CTAN for prmulgation
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 24 Nov 1994 05:13:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 24 Nov 1994 06:13:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411241113.AA03279@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
I asked Nina about naming the Pandora files.
No response yet.
I don't know if she's still around.
================================================================================
From owner-twg-tds@shsu.edu Thu, 24 Nov 1994 06:06:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 24 Nov 1994 13:06:57 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
To: TWG-TDS@SHSU.edu
Message-ID: <01HJUX2BEO429JDAYY@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Well, the names of pandora fonts were once shortened (i think by Erik-Jan
Vens) to beginn with pn*. He also made the files internally consitent, so
that pandora compiles smoothly.
I got this version years ago from the famous ymir archives (has someone a
backup of this?).
--J"org Knappen.
Appended: List of pandora files I have:
Directory DISK$USER2:[USE.KNAPPEN.MFSOURCES.PANDORA]
CAPS.MF;1 FLIGS.MF;1 LIGS.MF;1 NAMEN.TXT;1
NUMBER.MF;1 PANACCENT.MF;1 PANDOR.MF;1 PANDOR.TXT;1
PANGREEKU.MF;1 PANLOWERS.MF;1 PANPUNCT.MF;1 PN.TXT;1
PNB10.MF;1 PNR10.MF;1 PNSL10.MF;1 PNSLTT9.MF;1
PNSS10.MF;1 PNSSB10.MF;1 PNSSI10.MF;1 PNTT9.MF;1
PUNCTR.MF;1 PUNCTS.MF;1 PUNCTT.MF;1 ROTEXT.MF;1
TTCHAR.MF;1 TTTEXT.MF;1 WIDTHS.MF;1
Total of 27 files.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 04:50:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 NOV 94 10:33:07 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Message-ID: <2024E2A1_00335B50.00987FD8666B669A$19_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Well, the names of pandora fonts were once shortened (i think by Erik-Jan
>> Vens) to beginn with pn*. He also made the files internally consitent, so
>> that pandora compiles smoothly.
Unfortunately, unless my counting is letting me down, he didn't go far enough:
--------
Directory DISK$USER2:[USE.KNAPPEN.MFSOURCES.PANDORA]
CAPS.MF;1 FLIGS.MF;1 LIGS.MF;1 NAMEN.TXT;1
NUMBER.MF;1 PANACCENT.MF;1 PANDOR.MF;1 PANDOR.TXT;1
^^^^^^^^^9
PANGREEKU.MF;1 PANLOWERS.MF;1 PANPUNCT.MF;1 PN.TXT;1
^^^^^^^^^9 ^^^^^^^^^9
PNB10.MF;1 PNR10.MF;1 PNSL10.MF;1 PNSLTT9.MF;1
PNSS10.MF;1 PNSSB10.MF;1 PNSSI10.MF;1 PNTT9.MF;1
PUNCTR.MF;1 PUNCTS.MF;1 PUNCTT.MF;1 ROTEXT.MF;1
TTCHAR.MF;1 TTTEXT.MF;1 WIDTHS.MF;1
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 07:49:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 1994 08:48:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251348.AA17466@terminus.cs.umb.edu>
To: CHAA006@VAX.RHBNC.AC.UK
CC: twg-tds@SHSU.EDU
Subject: Re: Another idea for e-TeX: \traceingfileio
Rather more importantly, TeX can now appear to take a finite-but-unbounded time
to find a file that it used to find almost instantaneously.
That's behavior that should be considered a bug. In my opinion.
a new primitive \tracingfileio:
I'm not sure a new primitive is necessary, especially since the output
from such a primitive would necessarily be system-dependent. Instead, I
think debugging options should be done in whatever way is most natural
and best for the implementation -- command-line arguments, environment
variables, using strings or numbers as values, or whatever.
(In the case of web2c, the envvar KPATHSEA_DEBUG can/will be able to be
set to various numeric values to get debugging output.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 08:14:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 NOV 94 14:13:48 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Re: Karl's comments on *\tracingfileio
Message-ID: <20253A3A_000DF7E0.00987FF739F921FA$20_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
Karl --
>> Rather more importantly, TeX can now appear to take a finite-but-unbounded time
>> to find a file that it used to find almost instantaneously.
>> That's behavior that should be considered a bug. In my opinion.
I can't see why: if there are are a very large number of files in a very
large number of nested directories, I would expect the time to be
considerably greater than had previously been the case. And on a time-sharing
NFS-served file system (which is how I run TeX here), that time can be
very considerable indeed. I can't see that there is any bug-like
behaviour, although it's distinctly sub-optimal...
>> a new primitive \tracingfileio:
>> I'm not sure a new primitive is necessary, especially since the output
>> from such a primitive would necessarily be system-dependent. Instead, I
>> think debugging options should be done in whatever way is most natural
>> and best for the implementation -- command-line arguments, environment
>> variables, using strings or numbers as values, or whatever.
But is \tracingfileio different from any other (tracing=debugging) option?
None are used for production purposes, all are used for debugging. Why
would you want to treat file-io differently? I can see your point
about the output being system dependent, but that's true of \showbox,
for example, where the `glue set' figures are documented to be system-
dependent.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 09:36:54 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rAkou-0006QqC@rsuna.crn.cogs.susx.ac.uk>
Date: Thu, 24 Nov 94 20:31 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Joachim's proposal for fonts/source...
>As an example, the pattern "texmf/fonts/*/tfm/%f.tfm" names each TFM
>file (tagged as `%f') with one level of subdirectory searching
Oh okay, yes if your TeX supports this sort of patterns, then yes you
can use fonts/source without much overhead. But we're back to the
argument about whether we want something that can be implemented today
or not.
So yes, this is another technical solution which would work if it were
implemented. But it doesn't change the political situation, which is
that TDS will die a death if we propose something that can't be
implemented today on most machines.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 09:55:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251555.QAA18693@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Joachim's proposal for fonts/source...
To: TWG-TDS@SHSU.edu
Date: Fri, 25 Nov 1994 16:55:29 +0100 (MEZ)
Content-Type: text
Alan wrote:
>
> So yes, this is another technical solution which would work if it were
> implemented. But it doesn't change the political situation, which is
> that TDS will die a death if we propose something that can't be
> implemented today on most machines.
It can be implemented. I already sent around the C function prototypes
that does it and repeat that I'm willing to give them to anyone (and
support them).
In fact, I brought this up because you and others said that pruning
is too difficult for many implementors. The proposal that's on the
table now does not demand such `sophisticated' knowledge of an
`esoteric' area like graph algorithms (taught in undergrad CS
courses, aren't they? ;-) -- it's standard C hackery.
Yes, I agree that the political situation is that it should be
implementable easily by every hacker. My proposal is. Please note that
the current TDS proposal cannot be realized on many platforms, so
there is implementation work ahead anyhow.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 11:36:43 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 09:36:51 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251736.JAA28868@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
I haven't been able to get in touch either. I would still like
to have it official that my change to make smode possible is
OK. I send it out as a patch, but it should be part of the main files.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 11:51:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 09:50:31 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251750.JAA29586@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in the pandora files
UnixTeX maintains a fully operational set of pandora files (I have actually
set several things in pandora including a collection of my father's poetry)
These have been modified in accordance with the following notice, although
the originals have been carefully preserved in the distribution. I hope this
time we can get the goahead for all these minor changes, which do not
in any way alter the character design.
Text of 00NOTE in the UnixTeX pandora source directory
00NOTE [Unix TeX distribution; October 1991, April 1993;
modified May 1994]
The standard mf source files for pandora cannot be used
with smode because they assume that the type of mode
is always numeric (smode defines the type of mode as string).
We have made very minor changes that will make smode
work and will in no way alter the actual appearance
of the font. The changes were posted by Pierre MacKay
(mackay@cs.washington.edu) to TeXhax on 22 April 1993, and
the author N. Billawalla notified. The files concerned are
pandor.mf
pnb10.mf
pnr10.mf
pnsl10.mf
pnss10.mf
pnssb10.mf
pnssi10.mf
pntt9.mf
The original files have been retained as *.mf.orig files.
Another change was made to line 12 of rotext.mf and tttext.mf
as a result of Mrs. Klaus Schallhorn's observation that the umlauts
over the slanted upper case letters in a document set by her husband
using the Pandora fonts, appeared to have been blown past the letters
to which they belonged, as though by a draft coming in from the left
side of the page.
All diacritical marks above upper case pnsl10 and pnssi10 manifested
this effect.
The problem was that the tfm slant value had been set to a HUGE
value as an accidental side effect of Neenie Billawala's careful
calculations of slant offsets in character design.
Changing
font_slant oblique;
to
font_slant sind(oblique/cosd oblique);
took care of the problem. The fix was posted to TeXhax by
Pierre A. MacKay (mackay@cs.washington.edu) in October 1991,
and the author notified. The original sources are retained
as *.mf.orig files.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 11:59:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 94 17:57:51 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411251757.AA14088@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Joachim's proposal for fonts/source...
> Please note that
> the current TDS proposal cannot be realized on many platforms, so
> thaere is implementation work ahead anyhow.
I think we have been round this circle a few times already, but...
The current TDS proposal is implementable now on the vast majority of
unix and pc sites (at least web2c and emtex) and (I understand) also
in the upcoming vms TeX release, and for most normal sized setups also
on oztex. This is enough people to get TDS off the ground.
If we come out with a TDS for which everyone must upgrade their TeX
and in all cases except web2c, have to wait for that upgrade to
appear, we may as well not bother recommending anything.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 12:18:54 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 10:16:33 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251816.KAA00959@june.cs.washington.edu>
To: CHAA006@VAX.RHBNC.AC.UK
CC: twg-tds@SHSU.EDU
Subject: Re: Karl's comments on *\tracingfileio
This is essentially the same thing as the earlier observation about
the global nature of \openin. IO is not a typesetting primitive, and
has nothing to do with the way the primitives put the glyphs on the
page. \showbox may produce some system-dependent rounding differences
but boxes are an integral part of the typesetting environment of TeX.
IO is necessarily tied to the architecture of the particular compilation
in all its aspects. One of the virtues of Karl's kpathsea approach is
that it increasingly isolates IO questions from TeX proper. The
handling of IO is an operating system problem, not a typesetting problem.
As such it should be addressed by operating system tools.
I note that in the program listing \openin and its cousins are identified
as primitives in the sense that you can't achieve their functionality with
any sort of manipulation of \def. Perhaps they should have been given
some other name to preempt some aspects of the present discussion. But I
suspect that it just seemed so obvious that IO is a special and wholly
architecture-dependent case the the distinction appeared unnecessary. After
all, the program was written in Pascal, and ur-Pascal was distinguished
by Wirth's evident hope that if he ignored IO as completely as possible
maybe it would go away altogether.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 16:04:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 1994 23:00:24 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
To: TWG-TDS@SHSU.edu
Message-ID: <01HJWW4WI00IHXIT2Q@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Oops, You're right. I think, he did not change these, because clipping of
the last letter did not cause any harm on a PC, however for consistency
they should be also renamed from pan... to pn...
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Fri, 25 Nov 1994 19:53:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 17:53:14 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411260153.RAA22677@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
More on the pandora naming:
If we are going to have pnaccent.mf pnlowers.mf and pngreeku.mf we
might as well go all the way with pnpunct.mf even though it is not
strictly necessary. But I think pandor.mf should probably be left
as is.
================================================================================
From owner-twg-tds@shsu.edu Mon, 28 Nov 1994 15:30:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 28 NOV 94 11:34:37 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Message-ID: <20264EF9_000E3378.0098823C7D0D63BA$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Oops, You're right. I think, he did not change these, because clipping of
>> the last letter did not cause any harm on a PC, however for consistency
>> they should be also renamed from pan... to pn...
Clipping to first-8+3 is fine, and until recently I have been able to rely
on it, as I share files between VAX/VMS and MS/DOS using NFS; unfortunately
I am now testing a new version of TeX which has hard-wired into it a
different algorithm: first-5+last-3.3; this _really_ screws things :-(
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 28 Nov 1994 19:14:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 28 Nov 1994 17:14:51 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411290114.RAA05148@june.cs.washington.edu>
To: TWG-TDS@SHSU.EDU, TWG-TAG@SHSU.EDU
Subject: Redundant files in latex/unpacked
Is it really necessary to include the entire contents of latex/base
as a redundant copy in latex/unpacked. It actually causes trouble,
because if you bring in an upgrade, e.g. ltpatch.ltx and place
it in only one of [base,unpacked] you have an even chance, depending
on where path-searching looks first, of getting the old file.
I did a full unpack.ins into a new unpacked directory and then
trimmed old-unpacked until the listings matched. The redundant
files were
00readme.txt ifthen.dtx lterror.dtx ltpatch.ltx preload.dtx
Makefile.unx ifthen.ins ltfiles.dtx ltpictur.dtx proc.dtx
bugs.txt install.txt ltfinal.dtx ltplain.dtx proc.ins
changes.txt lablst.tex ltfloat.dtx ltsect.dtx sample2e.tex
classes.dtx latex209.dtx ltfntcmd.dtx ltspace.dtx slides.dtx
classes.ins latex209.ins ltfss.dtx lttab.dtx slides.fdd
clsguide.tex latexbug.tex lthyphen.dtx ltthm.dtx slides.ins
cmextra.ins latexsym.dtx ltidxglo.dtx ltvers.dtx small2e.tex
cmfonts.fdd latexsym.ins ltlength.dtx ltxdoc.dtx source2e.tex
cmfonts.ins legal.txt ltlists.dtx ltxguide.cls syntonly.dtx
directex.txt letter.dtx ltlogos.dtx ltxref.dtx syntonly.ins
doc.dtx letter.ins ltmiscen.dtx makeindx.dtx template.txt
docstrip.dtx ltalloc.dtx ltnews.cls makeindx.ins testdist.dtx
docstrip.ins ltbibl.dtx ltnews01.ps manifest.txt testpage.tex
emtex.txt ltboxes.dtx ltnews01.tex manual.err texpert.txt
exscale.dtx ltclass.dtx ltoutenc.dtx newlfont.dtx unpack.ins
exscale.ins ltcntrl.dtx ltoutput.dtx nfssfont.tex unpacked.txt
fntguide.tex ltcounts.dtx ltpage.dtx oldlfont.dtx usrguide.tex
fontdef.dtx ltdefns.dtx ltpageno.dtx oztex.txt web2ctex.txt
idx.tex ltdirchk.dtx ltpar.dtx patches.txt yandytex.txt
None of the above belong in unpacked.
I did the unpack into an empty latex/unpacked directory, with
initex ../base/unpack.ins
to get a clean lot of unpacked files. It works fine.
One file that ought to be included in latex/base, however,
is David Carlisle's template for a texsys.cfg. Otherwise
it is liable to disappear altogether, which would be a pity.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 04:03:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 94 10:03:21 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411291003.AA16529@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.EDU
Subject: Re: Redundant files in latex/unpacked
> s it really necessary to include the entire contents of latex/base
> as a redundant copy in latex/unpacked.
Yes because the instructions are to get *one* or *the other* of these
directories.
The `unpacked' directory is not intended for user installation.
The installation instructions are
1) get base
2) run unpack.ins
3) initex latex.ltx
However if you have an amiga or something step 2 takes about 3 hours
so instead you can
1) get unpacked
3) initex latex.ltx
ie skip the unpack stage at the expense of downloading more files.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 06:56:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 1994 13:57:17 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
To: TWG-TDS@SHSU.edu
Message-ID: <01HK1YAMXT7M9GV76Z@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I think, providing the unpacked distribution is a service of the CTAN
archives and the LaTeX2e team for the convenience of the users of slow
machines. You are not supposed to have the same redundancy in a production
version of TeX.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 08:49:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 NOV 94 14:28:19 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Re: Redundant files in LaTeX/Unpacked
Message-ID: <2026268D_002FD480.0098831DEB12F41A$17_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Yes because the instructions are to get *one* or *the other* of these
>> directories.
That presupposes that the user knows what the instructions are. But many
will do what I did, which is simply to ask Ctan for an on-the-fly ZIPping
of the entire LaTeX hierarchy: once you've done that, you have both packed
and unpacked forms.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 09:43:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411291543.QAA07968@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Redundant files in latex/unpacked
To: TWG-TDS@SHSU.edu
Date: Tue, 29 Nov 1994 16:43:36 +0100 (MEZ)
Content-Type: text
Joerg wrote:
>
> I think, providing the unpacked distribution is a service of the CTAN
> archives and the LaTeX2e team for the convenience of the users of slow
> machines. You are not supposed to have the same redundancy in a production
> version of TeX.
Exactly, and I would like to add that this distribution directory
must be split in a production version, according to our TDS draft. As
the LaTeX2e documentation tells, a whole bunch of files are to be
moved to tex/latex/distrib/base. We added the recommendation to move
*.ltx files to tex/initex/latex.
Once again, I would like to point out that
ftp://ftp.th-darmstadt.de/pub/tex/TDS-compliant/ holds files that
describe a basic TDS compliant installation in more detail. In
particular, map.dirs lists all directories and map.files is an
extensive directory list with files.
(I have to admit, though, that I didn't change tex/hyphen ->
tex/initex yet. That's partly because the draft doesn't tell any more
where the hyphenation patterns shall go...)
And please -- what's the current state to drop the distrib/contrib
special case of tex/latex, now that the LaTeX team says it's
unnecessary?
I ask this for the third time, because I would like to get a
(positive or negative) answer before I reorder a large part of the
whole installation!
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 09:53:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 94 15:53:36 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411291553.AA16785@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
> We added the recommendation to move
> *.ltx files to tex/initex/latex.
It's on the list of things to change once we make the install docs TDS
compliant, after the TDS document is finalised...
> And please -- what's the current state to drop the distrib/contrib
> special case of tex/latex, now that the LaTeX team says it's
> unnecessary?
I assume dropped, although not in the latest draft, since I think I was
the only one pushing for it anyway.
texmf/tex/latex/
base
tools
graphics
amslatex
seminar
foo
bar
...
seems OK to me?
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 11:25:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rCVNu-00006iC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 29 Nov 94 16:26 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
>Exactly, and I would like to add that this distribution directory
>must be split in a production version, according to our TDS draft. As
>the LaTeX2e documentation tells, a whole bunch of files are to be
>moved to tex/latex/distrib/base. We added the recommendation to move
>*.ltx files to tex/initex/latex.
So the final destinations are:
tex/<system>/formats/ latex.fmt
tex/doc/latex *guide.tex ltnews*.tex etc.
tex/doc/latexsrc *.dtx *.txt
tex/latex/base *.tex *.cls *.clo *.sty *.fd *.def *.cfg
tex/initex/latex *.ltx *.ins
makeindex/ist *.ist
? Details may be hazy, but neither Darmstadt nor jasper.ora.com are
talking to me...
This needs instructions that iniTeX needs to be able to read
tex/latex/base when creating latex.fmt. Not sure about the homes for
*.txt or *.ins. There may be other holes.
>And please -- what's the current state to drop the distrib/contrib
>special case of tex/latex, now that the LaTeX team says it's
>unnecessary?
Fine by me to have latex/base, latex/graphics, etc.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Nov 1994 12:15:53 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 29 Nov 1994 10:16:01 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411291816.KAA08013@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
TWG-TAG-SHSU.EDU
In-reply-to: Sebastian Rahtz's message of Thu, 24 Nov 1994 10:49:01 +0000 <"swan.cl.cam.:076360:941124104936"@cl.cam.ac.uk>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Following Sebastian's guidance, I have looked at the files he
condemns, and they are a very odd lot.
The ./texmf/tex/latex/misc seems to be all latex209 stuff, so I have
moved it there, and shrunk the names. It turns out there was some
considerable duplication anyway.
I took a look in contrib/other/misc, and there are some long and
hyphenated names there, but that is so far out on the tree that
it probably doesn't matter.
I am taking local unilateral action to shrink the names in the
pandora directory, but that also means some slight editing in the
driver files. I would still like to be sure that the smode and
slant fixes are incorporated into the archive files. They do not
in any way alter the appearance of any of the characters (except
to get the accents where they were clearly intended to be in the
case of the slant fix) but they make the source files function
properly. Likewise the change from "pan" to "pn". It is trivial,
but it needs to be consistent. I would urge keeping pandor.mf
rather than pndor.mf, but making the pn prefix consistent even
in pnpunct.mf where it isn't strictly needed. I see no reason
to have qualms of conscience about this. It does not affect the
integrity of the design in any way.
At this point, I think the UnixTeX version of the files is 8+3
clean except for the odd file in contrib.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
From owner-twg-tds@shsu.edu Mon, 05 Dec 1994 16:37:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412051911.UAA33142@spice.iti.informatik.th-darmstadt.de>
Subject: Some comments on TDS draft (fwd)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 5 Dec 1994 20:11:16 +0100 (MEZ)
CC: David_Rhead@vme.ccc.nottingham.ac.uk
Content-Type: text
Today I received the following comment on the current draft of TDS.
Of particular interest seems to me that David would prefer even more
subcategories under tex/latex/, while some voices here (mine included ;-)
call for elimination of this special case.
[Please note Cc: to David.]
Joachim
---------------- forwarded message follows:
From: David_Rhead@vme.ccc.nottingham.ac.uk
Date: Mon, 5 Dec 94 17:23:18 GMT
Subject: Some comments on TDS draft
% Following your posting to comp.text.tex, I took up your invitation to
% fetch copies of the material from the TDS-compliant directory at
% Darmstadt.
% I have some comments, which I've appended below. However, I don't
% know who acts as secretary to the TWG, and I can't find a mail address
% for Norm Walsh.
% Could you feed my comments into the TWG's deliberations, please?
% (I'm afraid they've been done in haste. I hope that the gist is clear.)
% David
\documentclass[11pt]{article}
\begin{document}
\title{Some comments on version 0.5 of \\
{\it A directory structure for implementation-independent \TeX\ files}}
\author{David Rhead}
\date{5th December 1994}
\maketitle
\section{Name of \LaTeX\ directory}
Presumably, in due course, \LaTeX3 will appear, and people will have to
make the transition from \LaTeX2e to \LaTeX3. During the 2e-to-3
transition period, systems administrators may need to have \LaTeX2e
material and \LaTeX3 material in their filestores in parallel.
To ease the transition from \LaTeX2e to \LaTeX3, might it be better to have
directories called {\tt latex2e} rather than {\tt latex}? E.g., at the top
of page~8 of version 0.5 of the draft, have\\
{\tt texmf/tex/latex2e/distrib/package/files}\\
rather than \\
{\tt texmf/tex/latex/distrib/package/files}. \\
This would give the option of having \\
{\tt texmf/tex/latex3...} \\
when the time comes to phase \LaTeX3 in.
I would agree that \LaTeX2e is what one should get now from ``the {\tt
latex} command'' at a particular site. If a similar situation recurs with
\LaTeX3 (e.g., if \LaTeX3 has ``a compatibility mode''), ``the {\tt latex}
command'' might give \LaTeX3 from some day to be determined by a site's
systems administrator. But the run-up to the 2e-to-3 changeover may be
easier if it is clear whether a directory holds \LaTeX2e stuff or \LaTeX3
stuff. If the directories are called\\
{\tt texmf/tex/latex2e...} \\
and \\
{\tt texmf/tex/latex3...}, \\
rather than \\
{\tt texmf/tex/latex...}, \\
directory-names can be left alone during the 2e-to-3 transition. Material can
be tested in the\\
{\tt texmf/tex/latex3...}, \\
directory without affecting the \LaTeX2e service. When the material has
been tested, the effect of ``the {\tt latex} command'' for end-users can be
re-defined to point at the \LaTeX3 directory rather than the \LaTeX2e
directory.
\section{Site-specific \LaTeX\ class files, etc.}
An organization may have class files etc., that are locally important
(perhaps locally \emph{extremely} important), but which stay within the
organization. Examples include:
\begin{itemize}
\item
The AMS production software (as distinct from the pre-print styles
that are freely available to potential authors).
\item
The Elsevier production software (as distinct from the pre-print styles
that are freely available to potential authors).
\item
Addison-Wesley's software for books. At a UKTUG meeting on
book-production, Geeti Granger (from Addison-Wesley UK) said that most
of their \LaTeX-ed books are done in one of 6 designs. The {\tt .cls}
files (or whatever) that implement these 6 designs will have to
``live'' somewhere in the Addison-Wesley filestore.
\item
Anything that delivers documents typeset according to ``the
house-style'' of a particular organization.
\item
Anything that is hacked together that is ``good enough'' for use
internally within a particular organization, but isn't ``good enough''
to withstand the scrutiny it would get if placed in a CTAN archive.
\item For a university, software that:
\begin{itemize}
\item produces the sort of memos that are usual on that university campus
\item lays letters out so that they fit the university's headed paper
\item lays a thesis out in a way that is known to satisfy the university's
regulations
\item lays examination papers out as required by examination
officials.
\end{itemize}
(To reduce the scope for student mischief, it may be desirable to keep some
of these {\tt .cls} files in a directory that students cannot read!)
\end{itemize}
As far as I can see, the natural places for such material would be:
\begin{description}
\item[either] directly under {\tt texmf/tex/latex2e}
\item[or] under {\tt texmf/tex/latex2e/contrib}.
\end{description}
Might it be worth the TWG giving some advice about which place is to be
regarded as ``standard'' (and whether there should, or shouldn't, be a
standard name for the directory that holds it)?
Personally, I'd rate the organization-specific stuff as very important.
\begin{itemize}
\item
If people are browsing around the filestore, I'd hope that they find
it easy to locate the files that deliver their organization's
house-style.
\item
If someone is looking for a thesis style/class, it would be tragic if
they came across {\tt utthesis} (which is unlikely to satisfy
requirements outside Texas) before they found the {\tt .cls} file (or
whatever) that is known to meet their own university's requirements.
\item
It seems to me that one should treat ``provision of
organization-specific stuff'' as ``a good, and \emph{usual}, thing''.
I think it is much better for one person in an organization to do the
work and to make it available organization-wide, than to have
individual authors clogging {\tt comp.text.tex} up with queries about
how to satisfy their organization's requirements. E.g., surely it's a
university's computing centre's job to provide thesis software that is
deemed to satisfy the regulations -- it shouldn't be up to every
postgraduate to grope around CTAN and post items to {\tt
comp.text.tex}, etc.
\end{itemize}
Might it be worth saying that, as well as holding {\tt distrib} and {\tt
contrib}, {\tt texmf/tex/latex2e/contrib} will hold a directory (or two, to
allow one that students can't read!) that holds organization-specific
material? The following occured to me as examples of what this directory
(or directories) might be called:
\begin{itemize}
\item
{\tt texmf/tex/latex2e/OurHouse} for software that delivers ``our
house-style''
\item
{\tt texmf/tex/latex2e/in-house} for software that is used ``in
house''
\item
{\tt texmf/tex/latex2e/OurStaff} and {\tt texmf/tex/latex2e/OurOwn}
for ``software for staff-only'' and ``general-purpose'' software
respectively
\item
in the University of Mars,
{\tt texmf/tex/latex2e/UoMstaff} and {\tt texmf/tex/latex2e/UoM}
for ``software for staff-only'' and ``general-purpose'' software
respectively. (Students cannot read stuff in
{\tt texmf/tex/latex2e/UoMstaff}.)
\item
in the Department of Media Studies at the University of Mars,
{\tt texmf/tex/latex2e/CC} and {\tt texmf/tex/latex2e/Media}
for ``software hacked together and maintained by the UoM Computing Centre'' and
``software hacked together and maintained by UoM Media Studies staff''.
\item
What about sites where English is not ``the first language''? Where
would ``the ordinary user'' expect to find material that formats
documents in the way his/her organization requires? Does there need
to be the flexibility to allow a French site to put such material in,
for example, {\tt texmf/tex/latex2e/ChezNous} and a German site to put
it in {\tt texmf/tex/latex2e/bei-uns}?%
\footnote{Please feel free to replace these examples by more authentic ones.}
\end{itemize}
You'll see that I've had difficulty in thinking of one name that will
always be suitable. Maybe the TWG can think of a suitable name. If not,
perhaps it is a matter of finding ``a form of words'' to go in the
standard. For example, the text near the top of the current page 8 might
be replaced by something like:
\begin{quote}
The \LaTeX\ tree contains an extra level between ``format'' and
``package'' which indicates the package's status. Packages that are
supported by the \LaTeX\ project team are stored in\\
{\tt texmf/tex/latex2e/distrib/\dots}, \\
and other public-domain packages that are stored in\\
{\tt texmf/tex/latex2e/contrib/\dots}. \\
Packages peculiar to a particular site (e.g., because they implement
``the house-style'') will be held in one-or-more directories within
{\tt texmf/tex/latex2e/\dots}, \\
e.g., at Mars University Press, \\
{\tt texmf/tex/latex2e/MUPhouse/\dots}. \\
\end{quote}
Or does the TWG feel that such material should go under {\tt
texmf/tex/latex2e/contrib}?
In the analogous situation under {\tt doc}, a \LaTeX\ {\it Local Guide} in
the ``site's own'' directory might be the one tailored for that site,
whereas a {\it Local Guide} in a {\tt distrib} directory would be the raw
version distributed by the \LaTeX\ project team.
I think that it might be useful if the TWG's specification of the
``standard directory structure'' acknowledged that there is likely to be
such material, and suggested where it might live.
\section{Example files}
I'm inclined to think that ``example files'' are different from
``documentation files''. E.g., {\tt small2e.tex} is something that one
copies and plays with, whereas {\tt btxdoc.tex} is something which one
typesets and reads. Locally, I supply quite a lot of \TeX-related example
files (e.g., a ``thesis kit'' containing a root file, skeleton front
matter, 3 skeleton chapters, 2 skeleton appendices, and back matter -- the
idea being that a student can copy the lot and start typing their own text
into the skeleton).
Moreover, a site may have other software that supplies documentation and
example programs. E.g., for numerical methods, we get the Numerical
Algorithms Group Fortran Library, which has associated ``routine summary''
files and ``example program'' files. The site may wish to use links to
make it appear to end-users that all documentation files are in one tree,
and all example files are in another tree. E.g., the Mars Computing Centre
might reasonably want to define a directory {\tt /mcc/examples} that
appears to hold both NAG and \LaTeX\ examples, and a directory {\tt
/mcc/doc} that appears to hold both NAG and \LaTeX\ documentation.
How about having\\
{\tt examples/martian}\\
as well as \\
{\tt doc/martian}?
\end{document}
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 06 Dec 1994 05:32:08 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rEy5e-00006iC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 6 Dec 94 11:29 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, David_Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Some comments on TDS draft (fwd)
David,
>To ease the transition from \LaTeX2e to \LaTeX3, might it be better to have
>directories called {\tt latex2e} rather than {\tt latex}?
This is true, but the benifits of using latex2e will be transitory
(and quite a way in the future!) whereas the benefits of using latex
(eg users look in /local/texmf/tex/latex/ for stuff to do with latex)
are permanent.
For the transition, the best solution (on systems which support such
things) is to have directories latex209 latex2e latex3 etc. with a
symbolic link latex -> whatever... this is how I'll be implementing it
at this end!
>As far as I can see, the natural places for such material would be:
>\begin{description}
>\item[either] directly under {\tt texmf/tex/latex2e}
>\item[or] under {\tt texmf/tex/latex2e/contrib}.
>\end{description}
The current reccomendation (I can't remember if it made it into this
draft---it should have done!) is for a local directory, eg here it's
texmf/tex/latex/sussex/. This directory should *not* be called `local'
or some such in order that files can move (fairly) safely from site to
site.
>Might it be worth saying that, as well as holding {\tt distrib} and {\tt
>contrib}, {\tt texmf/tex/latex2e/contrib} will hold a directory (or two, to
>allow one that students can't read!) that holds organization-specific
>material?
The distrib/ contrib/ distinction is going to disappear, instead
there'll be (eg) texmf/tex/latex/graphics/, texmf/tex/latex/seminar/,
texmf/tex/latex/sussex/ etc.
>You'll see that I've had difficulty in thinking of one name that will
>always be suitable.
I don't think we should try. Sites are better placed to come up with
their own local names than we are.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Dec 1994 08:10:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Dec 94 15:09:35 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9412131409.AA19543@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: system names ?
Since this is my first posting to this group, I start introducing
myself:
I am Thomas Esser, math student at univ. of Hannover, Germany. I have
been doing system adminitration for about 3 years in the institute of
databases and information systems at univ. A month ago, I released a
TeX distribution for linux: teTeX.
My question: how can all those architectures (hardware + OS) be
represented in a 8 character directory-name? (e.g. in texmf/bin/SYSTEM)
I am thinking of sparcs running sunos and solaris, but solaris runs on
intel, too. So, how to name them?
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Dec 1994 12:46:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412131845.TAA16348@spock.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Dec 1994 19:45:37 +0100 (MEZ)
Content-Type: text
Thomas wrote:
>
> A month ago, I released a
> TeX distribution for linux: teTeX.
Nice distribution. :-)
> My question: how can all those architectures (hardware + OS) be
> represented in a 8 character directory-name? (e.g. in texmf/bin/SYSTEM)
> I am thinking of sparcs running sunos and solaris, but solaris runs on
> intel, too. So, how to name them?
Hmmm, ``When in doubt, use brute force''. Was it Kernighan or Ritchie
who said that in their Turing award lecture? ;-)
Just make the names longer. Over NFS, MS-DOS will map the longer
directory names to something cryptic, but you won't access
system-specific directories from there by definition.
Personally, I use a platform specification ($PLATFORM) that is a
combination of an architecture and an OS specifier ("$ARCH-$OS").
Be careful that you'll need different architecture specifiers for
different Sparcs (sun4m & sun4c).
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Dec 1994 14:29:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Dec 94 21:28:35 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9412132028.AA20789@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: system names ?
Joachim wrote:
>Personally, I use a platform specification ($PLATFORM) that is a
>combination of an architecture and an OS specifier ("$ARCH-$OS").
>Be careful that you'll need different architecture specifiers for
>different Sparcs (sun4m & sun4c).
Does sun4m/sun4c really make any difference? We have both
architectures here running the same binaries ...
Thomas
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Dec 1994 11:31:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Dec 1994 07:10:27 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412141210.AA11397@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: system names ?
I don't think we need to standardize system names for anything in TDS.
Do we? What's the point? Not everyone is going to have texmf/bin/SYSTEM,
anyway -- sites deal with multiple architectures differently,
and pretending otherwise is pointless, IMHO.
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Dec 1994 07:06:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412211306.OAA26076@spice.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Wed, 21 Dec 1994 14:06:38 +0100 (MEZ)
Content-Type: text
Hallo, ich bin gerade ueber folgende alte Mail gestolpert:
> >Personally, I use a platform specification ($PLATFORM) that is a
> >combination of an architecture and an OS specifier ("$ARCH-$OS").
> >Be careful that you'll need different architecture specifiers for
> >different Sparcs (sun4m & sun4c).
>
> Does sun4m/sun4c really make any difference? We have both
> architectures here running the same binaries ...
Der Unterschied liegt darin, dass sun4m-Architekturen
sun4c-Executables ohne Probleme ausfuehren koennen, aber nicht
umgekehrt.
Frohe Weihnachten,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Dec 1994 07:10:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412211310.OAA21760@spice.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Wed, 21 Dec 1994 14:10:38 +0100 (MEZ)
Content-Type: text
Sorry, will check my headers better the next time. (The mail was
meant to be sent to Thomas Esser.)
Happy holidays,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From owner-twg-tds@shsu.edu Wed, 04 Jan 1995 07:00:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 4 Jan 1995 07:41:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199501041241.HAA19506@jasper.ora.com>
To: twg-tds@shsu.edu
CC: bob@microprograms.com
Subject: Re: TWG-TDS
References: <9501041201.AA02280@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 3 January 1995 at 08:44:19, bob@microprograms.com wrote:
> Has the work of this committee been completed? I haven't received any
> mail from the list server since 05 Dec 94.
No, the work hasn't been completed yet. But I have a New Year's resolution
about it written down around here somewhere. ;-) I'll try to get a new draft
out this week or next and let's all see if we can wrap this up before
the end of the month.
I know it's taken longer than we expected, but I think we've had to deal
with some fairly thorny issues.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 05:50:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 1995 06:51:26 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502011151.AA26728@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: font hierarchy
We seem to be stalled on the TDS. Can we please either officially
abandon or finish it? Norm, have you made any changes since the 18.Nov
version for ftp on jasper? I would be willing to take over editing it,
if it's a problem for you.
As far as I remember, one of the main outstanding questions is (still)
the fonts directory -- whether we're going to go with
fonts/tfm/adobe/times or fonts/adobe/times/tfm. Yes? Or were there other
serious alternatives on the table?
It's obvious there is substantial resistance to fonts/adobe/times among
the implementors, after reading over the replies to Alan's survey from
October. So, whether or not they or their implementations can be coerced
into trying to support it, it's probably doomed to failure.
So, I suppose I give up. I still think it is the wrong thing, because it
makes maintenance significantly harder, but it's pointless to keep
arguing about it.
P.S. Here's what I wrote before coming to the above conclusion -- I
can't bear to throw it away :-).
The main argument for tfm/adobe, as I recall, was practicality -- it
works reasonably efficiently with (almost?) all implementations now.
The reason I remain unconvinced is the efficiency part; I grant you the
works-with-present-implementations part. The case that is most
interesting, I think, is with CM and the usual Metafonts, the standard
35 PostScript fonts, and the standard LaserJet fonts -- about 200
directories or so in all, and maybe 40 typefaces. This is neither so
small that any kind of searching will be fast, nor so huge that anything
less than a fully-cached implementation will be hopeless. And also it is
a number that probably many implementations are close to.
I looked up Alan's message about emtex (in 1994-08, if anyone cares). In
summary, tfm/adobe/times took about 8 seconds to load 50 fonts, with
about 20 tfm directories. He characterized this as ``reasonable'' -- I
agree so far as it goes, but if it's linear (i.e., 16 seconds with twice
as many TFM directories), I bet many users would become very unhappy,
and so tfm/adobe/times really wouldn't be acceptable.
I seem to remember David C. also reporting some statistics with emtex,
but I can't find that message now. Sigh. In any case, other mail said
that emtex has path specifications (%f/%t/*/ type stuff), so perhaps
it could do searching that way, and avoid the raw subdirectory searching
after all.
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 10:19:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 1995 11:16:24 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502011616.LAA13399@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: font hierarchy
References: <199502011151.AA26728@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 1 February 1995 at 06:51:26, K. Berry wrote:
> We seem to be stalled on the TDS. Can we please either officially
> abandon or finish it? Norm, have you made any changes since the 18.Nov
Thanks for the nudge, Karl. I had hoped to finish it all up by the
end of January. But, in my own defense, the California office was
shut down by the flood (routing all tech support and customer service
calls to Cambridge where we struggled along as best we could), then I
want to CA for a week, got sick (came back early: the redeye with a
fever---that's either the best or the worst way to do it, I'm not sure
which), and then had to catch up on everything I hadn't done for two
weeks.
So, *finally* there's a new draft on jasper (/private/twg-tds). It's
not much changed, but I did a little work.
Let's try to pull together and finish this up before Valentine's day,
what do you say? I think it's all in the details now.
> version for ftp on jasper? I would be willing to take over editing it,
> if it's a problem for you.
Thanks, Karl. If it gets hectic here again, I'll pass it along to you
rather than let it all get stalled again.
> As far as I remember, one of the main outstanding questions is (still)
> the fonts directory -- whether we're going to go with
> fonts/tfm/adobe/times or fonts/adobe/times/tfm. Yes? Or were there other
> serious alternatives on the table?
>
> It's obvious there is substantial resistance to fonts/adobe/times among
> the implementors, after reading over the replies to Alan's survey from
> October. So, whether or not they or their implementations can be coerced
> into trying to support it, it's probably doomed to failure.
>
> So, I suppose I give up. I still think it is the wrong thing, because it
> makes maintenance significantly harder, but it's pointless to keep
> arguing about it.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 12:22:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 10:15:18 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011815.AA11517@cfcl.com>
To: TWG-TDS@SHSU.edu, bed_gdg@shsu.edu, rdm@cfcl.com
Subject: implementation
Guise-
I realize that several of you have played with implementing the proposed
structures, but I don't know of any organized plan for generating a "real"
(and definitive) implementation. I would like to suggest that we do this,
preferably as part of the CTAN. I'm not sure how much help PTF can be in
this, but we might be able to supply George with a disk drive, or so...
Yours, Rich
rdm@cfcl.com
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 12:39:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502011840.TAA17959@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Wed, 1 Feb 1995 19:40:34 +0100 (MEZ)
Content-Type: text
You wrote:
>
> I realize that several of you have played with implementing the proposed
> structures, but I don't know of any organized plan for generating a "real"
> (and definitive) implementation.
IMNSHO the problem is not _generating_ a definitive TDS
implementation, but _maintaining_ it. It's almost a full time job to
track all the new stuff and incorporate it into *the* `One-And-Only'
TDS-compliant TeX (source?) distribution.
The `TDS example' distribution I prepared (location in .sig, below)
is not definitive, but rather minimal. That's because it shall be an
_example_ about the packages that make up the kernel of a full
installation. But it is "real"; i.e., it's made up of packages that
are in use without any alteration on half a dozen platforms I
maintain. (I even provide the scripts to install them on Unix
systems.)
> I would like to suggest that we do this,
> preferably as part of the CTAN.
I don't think we should rearrange CTAN to fit TDS. (I don't know if
you want this, but I'd like to emphasize it. :-)
CTAN organization is oriented towards the purpose of archiving and
retrieving TeX software packages. TDS is oriented towards the purpose
of installing and using these packages. Two different goals that
conflict often enough, and that need two different views anyhow.
(Norm, how about putting that summary in the TDS document? ;-) ;-)
That's one of our past discussion points that are not reflected in
it.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
TeX Users Group
TWG TeX Directory Structure, member
ftp.th-darmstadt.de:/pub/tex/TDS-compliant/ has more information.
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 12:56:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 18:57:16 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011857.AA06386@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> I don't think we should rearrange CTAN to fit TDS. (I don't know if
> you want this, but I'd like to emphasize it. :-)
I'd like to strongly agree with Joachim on this point, also some care
has to be made in even making a sample TDS generally available in
addition to the ctan archives. Which was what I think Rich meant, as
he talked of `extra disks'.
Many packages have distribution conditions saying that all files,
including documentation, should be distributed together. This is fine
for a distribution/archiving structure like ctan.
However it is not what is wanted in the `working' TDS structure.
What this means essentially, is that if you are trying to maintain a TDS
structure that is publically distributed you have to gain permission
from the authors of each individual package to re-arrange their files.
LaTeX is one example of a package that states that all files must be
kept together, but it is not the only one. In the case of LaTeX we do
allow the redistribution in TDS style under certain conditions,
eg Karl's present lib.tar distribution, but as Karl could testify, it
took us a long time to come up with a wording for a document that
allowed this kind of distribution.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 13:07:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 19:07:52 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011907.AA06389@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: latest draft
<para>
The &LaTeX; tree contains an extra level between <replaceable>format</>
and <replaceable>package</> which indicates whether or not the package
is supported by the &LaTeX; development team.
I thought we'd agreed to flatten out that level again, ie
texmf/tex/latex/base/*
texmf/tex/latex/tools/*
texmf/tex/latex/babel/*
texmf/tex/latex/psnfss/*
texmf/tex/latex/seminar/*
texmf/tex/latex/hyperref/*
So this also affects the example at the end:
<programlisting>
texmf/tex/plain
texmf/tex/plain/amstex
texmf/tex/latex/distrib/amslatex
texmf/tex/latex/distrib/babel
texmf/tex/latex/contrib/float
texmf/tex/latex/contrib/psnfss
ie delete distrib and contrib (even as it stands it's wrong as psnfss
counts as distrib under the present arrangements)
<para>
We encourage package authors to build their distribution archives in
a structure that parallels the &tds;. This will make package installation
much easier for the installer and much more regular across packages.
For example, a package for Martian language typesetting might include
the following files:
</para>
Last time this came up, I thought we agreed that doing this would make
ctan unworkably deep. i think that this whole section ought rather say
something along the lines of Joachim's post as to why a ctan archive
is different from tds, and then encourage authors to document (and
possibly automate) how the files should be installed from an archive
into an existing tds tree.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Feb 1995 13:56:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 11:50:48 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011950.AA11808@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
In case anyone is still wondering, I most certainly did *not* intend that
the current structure of the CTAN be changed to support the TDS. I *do*
wonder, however, whether it might not be useful to make up Info-Zip sets
of files, on a font-by-font basis, that could load cleanly into a TDS-
compliant set of directories. Is this possible in a portable fashion?
Getting back to the original point, however, I am a bit disturbed to find
out about the restrictions on distribution format. It would certainly be
possible to thrash our permissions for at least some of the more common
fonts and such, and perhaps those of us who are interested should get on
with it. If O'Reilly and/or PTF are to publish mountable TDS trees on
CD-ROM, *we* certainly have motivation to do this. And, more generally, I
think the users would benefit from being able to grab pre-built sets of
common fonts. In fact, I kinda thought that was the main point of this
exercise, along with assisting managers of huge TeX systems.
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 04:45:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502021044.LAA13739@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Thu, 2 Feb 1995 11:44:58 +0100 (MEZ)
Content-Type: text
You wrote:
>
> In case anyone is still wondering, I most certainly did *not* intend that
> the current structure of the CTAN be changed to support the TDS. I *do*
> wonder, however, whether it might not be useful to make up Info-Zip sets
> of files, on a font-by-font basis, that could load cleanly into a TDS-
> compliant set of directories. Is this possible in a portable fashion?
I'd say yes. We ``only'' need (a) volunteer(s) to maintain it.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 05:06:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 11:04:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021104.AA06883@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> Getting back to the original point, however, I am a bit disturbed to find
> out about the restrictions on distribution format.
This may not be a problem in practice, as I say, for LaTeX we interpret
`must be distributed together' in a sufficiently loose way that a CD
could have the files distributed along TDS lines, as long as they are
all on the CD somewhere. It may be that other authors may take a
similar view, but things may need to be checked.
Personally I can not see much use for maintaining a rapidly changing
public TDS directory. Once the TDS has been finalised, It may be
useful for a basic `TDS-starter kit' ie an expanded version of web2c's
lib.tar, along the lines of Joachim's archive.
However `publishers of `ready installed' CD's will probably want to
have access to a large `sample TDS' and so perhaps it would not do
much harm if that was made publically available.
However I do not see that trying to keep a public TDS archive updated
with whatever stuff has just been contributed to ctan makes much
sense. Most people are never going to need *all* the files in the
contrib areas of ctan, the idea is to pick and choose, so I would be
against making an ever larger tar/zip file, and the only other
alternative appears to be a different zip file for each package, each
unpacking itself into a TDS tree, but as discussed here before, there
is a possibility of the ctan ftp program producing those on the fly
anyway.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 05:54:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 03:49:42 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021149.AA15627@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
JS> I'd say yes. We ``only'' need (a) volunteer(s) to maintain it.
Well, I see it almost falling out of a reasonable strategy to build a
"complete" TDS tree, as OR and/or PTF needs to do already. As I see it,
the process should be quite possible to automate, presuming that the
input archives don't go wonky on us.
It might also be that some of the maintainers of fonts and such would be
interested in releasing them in a TDS-compliant archive. In other cases,
where the materials are useful but static, a single conversion might do
the trick for quite a while. I'm not discounting the effort involved,
but I *do* think it is manageable, and that some cooperation could keep
the TeX community from duplicating a great deal of effort.
DC> Personally I can not see much use for maintaining a rapidly changing
DC> public TDS directory. ...
I agree. A definitive TDS tree on the CTAN might be useful as a check
on proper installation of local files, but I don't imagine that it would
be a very convenient place to go for files. That's why I like the idea
of TDS-compliant archives that can be poured into an existing TDS tree.
A "starter" TDS tree fits *very* well into this plan.
In order to make a definitive, mountable CD-ROM, of course, the publisher
would have to load in the starter plus all the add-ins. Fully realizing
that any given user will never need most of ther materials, the publisher
can still be content with the fact that the user will be able to find any
materials s/he needs. (Dictionaries contains lots more words than anyone
typically looks up. :-)
DS also hints at the "possibility of the ctan ftp program producing [zip
files in TDS format] on the fly". First time I've heard of this; but it
sounds like it might have possibilities. SPQR, what do you have in mind?
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 06:01:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 12:00:14 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021200.AA06923@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Name of the TDS Root
The following snippet was part of the mail I sent about the November
draft, but it applies to the latest draft as well:-)
David
<para>
The &tds; is rooted at a directory called <filename role=dir>texmf</>.
The location of
this directory within the file system is up to the installer. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>. On PC networks, this could map to a
logical drive specification, for example <filename role=drive>T:</>.
</para>
I am not sure that this captures what I (thought) was decided.
In particular the two cited examples are rather different, I think
that the suggestions are
/usr/local/texmf/
t:/
but I would read the above paragraph as suggesting
/usr/local/texmf/
t:/texmf/
Perhaps something like
<para>
The root of the &tds; should be a directory only containing &TeX;
related material. In this document we shall assume that this directory
is called called <filename role=dir>texmf</>, although the exact name
of the directory is up to the installer. On PC networks, this could
map to a logical drive specification, for example
<filename role=drive>T:</>.
</para>
<para>
Similarly the location of
this directory within the file system is site-dependant. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>.
</para>
... or something...:-)
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 12:56:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:51:33 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021851.NAA06798@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021149.AA15627@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 03:49:42, Rich Morin wrote:
> DS also hints at the "possibility of the ctan ftp program producing [zip
> files in TDS format] on the fly". First time I've heard of this; but it
> sounds like it might have possibilities. SPQR, what do you have in mind?
If package authors were amenable to providing a file that mapped from
their archive arrangement to TDS, it would be possible to write a
wuftpd filter to "do the right thing".
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 12:58:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:53:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021853.NAA06856@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Name of the TDS Root
References: <9502021200.AA06923@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 12:00:14, David Carlisle wrote:
>
> The following snippet was part of the mail I sent about the November
> draft, but it applies to the latest draft as well:-)
Just me, lousing up again ;-)
> Perhaps something like
>
> <para>
> The root of the &tds; should be a directory only containing &TeX;
> related material. In this document we shall assume that this directory
> is called called <filename role=dir>texmf</>, although the exact name
> of the directory is up to the installer. On PC networks, this could
> map to a logical drive specification, for example
> <filename role=drive>T:</>.
> </para>
> <para>
> Similarly the location of
> this directory within the file system is site-dependant. On
> many systems, this may be at the root of the filesystem; however, on
> &unix; systems, this would traditionally be located in
> <filename role=dir>/usr/local</>.
> </para>
>
> ... or something...:-)
Suits me. Sorta ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 12:59:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:48:51 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021848.NAA06729@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: latest draft
References: <9502011907.AA06389@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 1 February 1995 at 19:07:52, David Carlisle wrote:
>
>
> <para>
> The &LaTeX; tree contains an extra level between <replaceable>format</>
> and <replaceable>package</> which indicates whether or not the package
> is supported by the &LaTeX; development team.
>
> I thought we'd agreed to flatten out that level again, ie
Happy to oblige.
> <para>
> We encourage package authors to build their distribution archives in
> a structure that parallels the &tds;. This will make package installation
> much easier for the installer and much more regular across packages.
> For example, a package for Martian language typesetting might include
> the following files:
> </para>
>
> Last time this came up, I thought we agreed that doing this would make
> ctan unworkably deep. i think that this whole section ought rather say
> something along the lines of Joachim's post as to why a ctan archive
> is different from tds, and then encourage authors to document (and
> possibly automate) how the files should be installed from an archive
> into an existing tds tree.
done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 13:02:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 19:01:39 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021901.AA07217@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> If package authors were amenable to providing a file that mapped from
> their archive arrangement to TDS, it would be possible to write a
> wuftpd filter to "do the right thing".
If this could be set up, I am sure LaTeX could put such a file in it's
`unpacked' directory so that this could serve as a model to authors of
other packages.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 13:20:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 14:15:27 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021915.OAA07086@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021901.AA07217@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:01:39, David Carlisle wrote:
>
> > If package authors were amenable to providing a file that mapped from
> > their archive arrangement to TDS, it would be possible to write a
> > wuftpd filter to "do the right thing".
>
> If this could be set up, I am sure LaTeX could put such a file in it's
> `unpacked' directory so that this could serve as a model to authors of
> other packages.
LaTeX is *really* hard, though, because all the files in the unpacked
directory are still "packed" in dtx format, correct?
Don't get me wrong, I understand why it's done this way, but it does
mean that the installer needs to get the files, run latex, etc. etc. etc.
and that's more than a wuftpd packaging script could do (and given the
sort of configuration that you get to do at latex-time, you wouldn't
want it to anyway, right?).
A case like the (now modified) example of martian in the TDS doc is
a more tractable problem.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 13:23:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 14:18:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021918.OAA07129@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New draft online...
Reply-To: TWG-TDS@SHSU.edu
With the changes recently discussed. But I haven't really proofed it... ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Feb 1995 17:53:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 19:28:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021928.AA07256@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> LaTeX is *really* hard, though, because all the files in the unpacked
> directory are still "packed" in dtx format, correct?
> Don't get me wrong, I understand why it's done this way, but it does
> mean that the installer needs to get the files, run latex,
> etc. etc. etc.
The dtx files in the `unpacked' dir are only there for show, they
could be moved straight to a ... (documentation or source:-) directory
> A case like the (now modified) example of martian in the TDS doc is
> a more tractable problem.
Certainly in terms of documenting *how* one should wrte such a file,
what I meant was if the system was there, and we managed to get it
working for the core latex distribution, it would encourage a lot of
other authors to follow suit.
On the other hand it might be best to get the draft finished, without
being sidetracked into writing nifty ftpd scripts....
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 05:15:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 06:10:53 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031110.GAA18745@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021928.AA07256@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:28:49, David Carlisle wrote:
> > LaTeX is *really* hard, though, because all the files in the unpacked
> > directory are still "packed" in dtx format, correct?
>
> > Don't get me wrong, I understand why it's done this way, but it does
> > mean that the installer needs to get the files, run latex,
> > etc. etc. etc.
>
> The dtx files in the `unpacked' dir are only there for show, they
> could be moved straight to a ... (documentation or source:-) directory
I guess I've never paid that much attention. You mean that I could
really run the files in the 'unpacked' directory without any pre-processing?
Cool...
> > A case like the (now modified) example of martian in the TDS doc is
> > a more tractable problem.
> Certainly in terms of documenting *how* one should wrte such a file,
> what I meant was if the system was there, and we managed to get it
> working for the core latex distribution, it would encourage a lot of
> other authors to follow suit.
>
> On the other hand it might be best to get the draft finished, without
> being sidetracked into writing nifty ftpd scripts....
David! How could you think such a thing! ;-)
Tell ya what, since you know files so well ;-), how about providing a TDS
mapping for me?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 05:18:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 06:13:56 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031113.GAA18754@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021928.AA07256@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:28:49, David Carlisle wrote:
>
> The dtx files in the `unpacked' dir are only there for show, they
> could be moved straight to a ... (documentation or source:-) directory
Actually, given Joachim's recent statement about seperation of
archiving and TDS operations (widely agreed upon), doesn't it make
*less* sense to put a source tree in the TDS? I mean, that's not
needed to *run* TeX and that's a nice pragmatic way of deciding what
goes in and what doesn't, right?
I agree that for CD distribution, the source has to be there, but there's
nothing that says it has to be in TDS format. On the other hand, if we
need the TDS to start in the root of the CD, we'll need an escape hatch...
Maybe "texmf/source"?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 05:33:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 95 11:32:15 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502031132.AA07719@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> > The dtx files in the `unpacked' dir are only there for show, they
> > could be moved straight to a ... (documentation or source:-) directory
> Actually, given Joachim's recent statement about seperation of
> archiving and TDS operations (widely agreed upon), doesn't it make
> *less* sense to put a source tree in the TDS?
Yes this is a problem, and why I did not fill in the dots above.
On one hand, I agree with Joachim that the TDS should not really say
anything about sources, and that one might want to consider most of
the latex/base dtx files as source rather than documentation.
However if we really are contemplating automatic scripts to move stuff
from a ctan style setup to a TDS, these scripts have to move *.dtx
somewhere (NOT /dev/null:-). Whatever `somewhere' is in the script,
is likely to become a defacto extension of the TDS tree even if we try
and document that it is only a `suggestion' and that sources can be put
anywhere. (If the scripts work, nobody will read our documentation...)
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 05:58:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502031155.MAA13902@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Feb 1995 12:55:43 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> Actually, given Joachim's recent statement about seperation of
> archiving and TDS operations (widely agreed upon), doesn't it make
> *less* sense to put a source tree in the TDS? I mean, that's not
> needed to *run* TeX and that's a nice pragmatic way of deciding what
> goes in and what doesn't, right?
>
> I agree that for CD distribution, the source has to be there, but there's
> nothing that says it has to be in TDS format. On the other hand, if we
> need the TDS to start in the root of the CD, we'll need an escape hatch...
> Maybe "texmf/source"?
Hasn't texmf/src/<system>/<package> already been discussed in the
past? More missing points will be mentioned in a further mail (I have
to read the current draft first, to check them again...)
I'm all in favor for specifying a directory for sources. It should be
listed as one element in the set of ``additional directories [to] be
used for other standard purposes'', like bin/, ini/, etc.
"src/web2c/, src/latex/base, etc." are IMO a good example list for
that item. (Btw, I don't care for the name `src', I would use
`source', too. It's just my Unix-oriented attitude that shows off. :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 07:04:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 08:00:03 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031300.IAA20052@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Three new directories...
Reply-To: TWG-TDS@SHSU.edu
Going back through recent discussions and a paper posted (or emailed to me?)
by David Rhead, I have three suggestions:
1) As Joachim suggested, a standard "acceptable other" place for sources:
/texmf/source/<format>/...
/texmf/source/<whatever>/...
2) A place for local packages and styles:
/texmf/local/<format>/...
3) A place for local fonts:
/texmf/fonts/<type>/local/<typeface>/...
Here, texmf/local is for local TeX stuff and texmf/fonts/.../local is
for local fonts. Since the "source" of a font could arguably be
"local" for the font tree, that seems better than trying to go with
"/texmf/lcltex" and "texmf/lclfont" or some such. Or do you disagree?
My gosh, are we actually getting close to the end? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 07:20:18 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502031319.OAA16518@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Three new directories...
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Feb 1995 14:19:47 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> 2) A place for local packages and styles:
>
> /texmf/local/<format>/...
>
> 3) A place for local fonts:
>
> /texmf/fonts/<type>/local/<typeface>/...
I don't like this.
If one needs to add local stuff in a single place (I can see the
reason why), one can set up *another* texmf tree, and add both trees
to the search paths (the local one first, usually). I.e.,
/usr/lib/texmf and /usr/local/lib/texmf, so to speak.
IMO, the other solution (texmf/local/) leads to problems with file
searches: Typically such a local (sub-)tree is not only used for
enhancements, but also for local replacements. The `system part' is
then assumed to be on a read-only network file system, or a CD, or
similar. Search paths like `$TEXMF//cm//' cannot be used any more,
while they are currently non-amiguous. But
`$LOCAL_TEXMF//cm//:$TEXMF//cm//' is still workable.
Bottom line: Let me make a counter proposal:
2+3) Add an explicit hint that more than one texmf tree may be
available and should be usable in an installation. In particular, the
constellation of one texmf tree that is an (unchanged) distribution
and another texmf tree for local adaptions/enhancements/replacements
is not uncommon.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 10:56:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 95 16:18:16 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502031618.AA07821@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
> Bottom line: Let me make a counter proposal:
This looks like a good idea to me, especially if people are going to
be using a TDS tree directly off a CD, they are going to have to do
this anyway, so formalising this as a general method for keeping
local things separate from a distributed setup sounds interesting.
Probably having `local' further down the tree is more like current
practice, but ... .
Wherever `local' goes there was also Alan's proposal that we suggest
using a `site name' eg `sussex' rather than `local' to aid merging
style collections from different sites.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 11:59:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 11:38:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031638.LAA24416@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
References: <199502031319.OAA16518@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 14:19:47, Joachim Schrod wrote:
> Bottom line: Let me make a counter proposal:
>
> 2+3) Add an explicit hint that more than one texmf tree may be
> available and should be usable in an installation. In particular, the
> constellation of one texmf tree that is an (unchanged) distribution
> and another texmf tree for local adaptions/enhancements/replacements
> is not uncommon.
Sounds good to me! Solves a lot of ugliness.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Feb 1995 13:59:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 13:44:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031844.NAA27471@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
References: <9502031618.AA07821@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 16:18:16, David Carlisle wrote:
>
> Wherever `local' goes there was also Alan's proposal that we suggest
> using a `site name' eg `sussex' rather than `local' to aid merging
> style collections from different sites.
>
True, but seperate trees just fixes the whole mess. A user can have
/cdrom/texmf:/usr/local/sussex/texmf:/usr/local/mainze/texmf
etc. Or even just
/cdrom/texmf:/usr/local/sussex:/usr/local/mainze
the extra texmf layer isn't really necessary on local disks. Although
I *really* want to see it on the CD-ROM.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Feb 1995 07:32:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Feb 1995 08:27:36 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502081327.IAA01710@jasper.ora.com>
To: vojta@math.berkeley.edu (Paul Vojta)
CC: twg-tds@shsu.edu
Subject: Re: comments on twg-tds draft
References: <199502022328.PAA12698@tashkent.berkeley.edu>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 15:28:48, Paul Vojta wrote:
> Norm:
>
> Here are some comments I have about the draft twg-tds standard:
Thanks. Spelling and gramatical errors corrected.
> 4. A question:
>
> Will .ps files (e.g., .ps header files for dvips)
> need to implement a subdirectory searching algorithm?
>
> Note that xdvi will likely share many header files with dvips.
I don't think so. Information for dvips can reasonably go in
texmf/dvips
and the organization can be whatever is convenient for dvips/xdvi/etc.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Feb 1995 10:42:57 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 8 Feb 1995 08:42:45 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502081642.IAA00250@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: mackay@murad.classics.washington.edu
Subject: comments on twg-tds draft
Has anyone else noticed the subtle effect of genuine rationality
in the example in section 9?
Section 5.2 despairs of the {\it source}-first organization, but there it
is again in Section 9. I don't hold out any hope for a return to
{\it source}-first as opposed to {\it type}-first, even though the
latest version of kpathsea searching on my creaky old no-memory
Sun 3-50 strongly validates Karl's claims for it. But the example
will need to be consistent with the recommendations in 5.2 whatever
they are.
I should like also to plead for the retention of the {\it public}
designation for a wide range of fonts and, on the whole, even to put
cm among them. DEK is really not a foundry, and I doubt that he
really cares whether he is advertised as one. Karl Berry and I talked
this out a while ago, and I think I was able to make the point that
{\it public} can be used to designate fonts for which there is no
problem of licensing when you send them out. Most foundry fonts, at
least in glyph form (and that includes PK renderings of Type1
outlines) can only be delivered to those who can show that they have
valid licences for that specific font. Those that are specifically
freed up for public distribution have traditionally (in the UnixTeX
world at least) gone into {\it public} because {\it public} expresses
their licensing situation better than any other term we could think
of. Of course there are anomalies. Part of Adobe Utopia (by no means
all of it) has been made available without restriction, Bitstream
charter, IBM Courier and the odd collection of URW fonts.
(Incidentally, how widely are people aware that Nimbus Roman is an
open-license Times and Nimbus Sans is an open-license Helvetica?) I
don't see any point in splitting hairs about this. I am not arguing
that these fonts be crammed into {\it public} just because their
licensing conditions are not the same as those for the remainder of
the foundry's fonts. But for the general run of METAFONTS and for any
others that may arrive perhaps in a different coding, {\it public}
seems a good catch-all rubric, and it actually conveys something to
the user.
Incidentally, does anyone know the status of Symbol and NewCenturySchoolbook?
There has been some suggestion that these are open-license too.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01112@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: architecture- and implementation-dependent directories
The current TDS allows:
\item[\filename{bin}/\replaceable{system}] for binaries
I think system/bin is also ok ... I don't think we can possibly (or need
to) legislate whether a site wants sun4/bin or bin/sun4.
\item[\filename{ini}/\replaceable{system}]
for pool files, format files, and base files.
I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
etc., as top-level directories, like `makeindx' and `bibtex'. That would
make the need for an ini directory (and this paragraph) go
away. (Despite my fondness for the name...)
Also, I think we should allow a top-level directory `info' for the
program-readable .info files produced from Texinfo source.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01120@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: type1 fonts in the tds
The current draft of the tds has:
\item[\filename{pfa}] Type 1 fonts in \filename{PFA} format
\item[\filename{pfb}] Type 1 fonts in \filename{PFB} format
I don't see anything in the archives that explains why we're
distinguishing these. It would simplify the paths to put them in one
directory, called, say, `type1'.
In practice, I think
1) it's highly dubious that people will have both a pfa and a pfb for
the same font; so we're not making the directories any smaller by
separating them.
2) every extant program can read both kinds if it can read either (at
least ghostscript and dvips can; not sure about ps2pk). So it's
not making any practically useful distinction to separate them,
either.
Put another way, every time .../pfa is put in someone's path, .../pfb is
needed also. So let's make everyone's life easier and put them together
in the first place.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:10 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01144@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: bibtex
I think there should be a chapter on bibtex in the tds -- it needs to be
almost as long as the chapter on Metafont :-). E.g.,
The TDS specifies two subdirectories of the top-level `bibtex'
directory:
bib -- for bibliography (.bib) files
bst -- for bibtex style (.bst) files
Rationale: this is in line with the general approach of the TDS to put
files of a particular type in a common directory.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:08 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01128@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: fonts/knuth?
The current tds draft has:
[for a font source] \literal{knuth} for the
original Computer Modern fonts
As Pierre wrote, I don't see the necessity for this. It's just another
directory where users and programs have to look for stuff. It's not like
its contents are going to be enlarged, ever again.
So I suggest we merge cm into public.
(In any case, it wouldn't be just the ``original Computer Modern
fonts'', but also concrete and logo and manfnt, presumably...)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:09 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01136@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: the initex directory
I hate to reopen this discussion, but the current draft of the tds
specifies a top-level initex directory.
Doesn't such a thing imply another whole set of things that have to go
in the paths, and where people & programs have to look?
I'm not sure I see the need. In the old mail, the things suggested for
it were
1) base files, like plain.tex and latex.ltx. Surely people would be more
inclined to find these in tex/<format>/base?
2) Joachim's unnamed initex-only files. They could be considered as
a package (if they aren't already) and put in tex/<package>?
3) hyphenation files. Could go in tex/hyphen.
Is there a practical advantage to the top-level initex/ to outweigh the
practical disadvantage?
By the way, these things kind of worry me. I'm just reading the
document, not actually trying to make a system [yet] that conforms to
it. I don't think the TDS should be declared official-and-accepted until
several implementations are actually distributing something that
conforms to it. Otherwise, we're just playing theoretical games.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 05:54:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:05 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01104@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: editorial comments
Editorial comments only, no one but Norm needs to read :-), sending to
the list only for archiving.
(Sorry, but the quotes are from the TeX document, not the SGML; I
neglected to retrieve that :-(.)
General comment #1: I don't see that the filename needs to have `twg-' in it.
General comment #2: I think `Unix' looks a lot better as `Unix' than
`\textsc{UNIX}'.
\title{A Directory Structure for Implementation-Independent {\TeX} Files \\ Version 0.61}
We talk about implementation-specific files as well, and I think it's
good for titles to be short and catchy, so how about tossing
`Implementation-Independent'.
to install it. This has resulted in hundreds of slightly different
... slightly (or not so slightly) different
(Text changes below not otherwise rationalized are just what struck me
as slightly improved wording as I was reading.)
structure for macros, fonts, and other implementation-independent {\TeX}
... other such
In the long run a consistent directory structure will make it
In the not-so-long run ...
work on all modern architectures. In particular, it can be used
`systems' instead of architectures, I think. Hardware seems irrelevant!
on \textsc{UNIX} workstations, \acronym{MS-DOS} and \acronym{OS/2}
\acronym{PC}'s, Macintoshes, and \acronym{VMS} machines.
under Unix, MS-DOS, OS/2, Macintoshes, and VMS.
(Also, by the way, \acronym is technically wrong here -- an acronym is
an abbreviation that's pronounced as a word: NASA and FAQ are acronym;
FBI (and VMS and PC and ...) are just abbreviations. No, I'm not saying
you have to change the control sequence name :-)
local system uses the \TeX\ Directory Structure.
... Structure recommended here.
(Also, I suggest saying the `\TeX Directory Structure (TDS)' here, and
then using `TDS' in most of the rest of the document. You already do
occasionally, and I think it would be clearer/shorter to use it
routinely. It's a single concept, after all. And you use TWG ...)
files into a single unit; for the purposes of use, it is frequently
more useful to segregate files (even similar files) from a single
..., it is traditional to segregate files ...
(Aside from the repeated `use...useful', what's ``useful'' is not the
same at every site.)
\subsection{Conventions}
A non-typographic convention you should note is that ``This document
uses / to separate filename components, as on Unix, purely
arbitrarily. The ideas are in no way Unix-specific.'' Or some such.
Filenames are represented in constant width.
`constant width' is not a term I've ever heard used as a noun. How about
simply `typewriter type'? Or `monospaced type', if you want to be fancy.
\item[\command{command}]
Commands are represented in italics.
Italics are fine, but `command' got printed here in bold italics,
probably because it's in a LaTeX \description. Yuck.
Literal text, things that you should type explicitly,
is represented in constant width.
`constant width' weirdness, as above. It's not exactly that you should
type them, either -- this isn't a user manual. I think `Literal text' is
clear enough by itself.
Replaceable text, like \replaceable{filename},
identifies a class of things. You should specify some member of
that class. Replaceable text is represented in constant width
oblique.
1) `constant width' again.
2) The `replaceable' wasn't printed in italic typewriter here, but
regular bold italic.
3) I think `package' would be a better example than `filename'.
4) The sentence `You should specify...' can be tossed, I think, as above
about typing.
5) I suggest we use cmsltt10 for this stuff. It's always part of a
filename (isn't it?), so some form of typewriter seems appropriate,
rather than regular italics. cmitt10 is a truly weird-looking font; I
think cmsltt10 is much cleaner.
\subsection{Subdirectory Searching}
Instead of making this part of the `Introduction' chapter, how about a
new chapter 2, `Basics' or some such, and put this, Constraints, Rooting
the tree, and Top Level Directories under it. I think that last should
not be a subsection of Rooting, either.
system configuration file, for example), but this is insufficient in
the general case.
I don't know what `in the general case' means. Sounds like handwaving to
me :-). How about `this is so cumbersome as to be unworkable at large
sites'?
On systems without runtime configuration files,
without some form of runtime configuration
(Envvars would suffice, doesn't have to be config files.)
As a result, the TWG decided that a comprehensive \TeX\ Directory Structure required
`concluded' is better than `decided', I think. It wasn't an arbitrary
decision. And here is a primse place to start `TDS' instead of `TeX
Directory Structure'. Those capital letters in the middle of a sentence
are disconcerting.
to specify that {\TeX} (and other {\TeX} utilities) search in both a
`and Metafont and their companion' instead of `other \TeX`?
specified directory and recursively through all subdirectories of that
... and implicitly recursively ...
(I think it's important to get the idea of ``implicitly'' across here;
we mean you specify a single directory name and the program does the
recursion, but that's not necessarily obvious from the present wording.)
directory when looking for an input file,
that is, a {\TeX} macro file, \filename{TFM} file, or a
\filename{PK}
bitmap font.
There's a lot more kinds of input files than those! (.bst, .mf, ...). I
suggest just deleting `that is ... bitmap font'.
Windows-NT, Macintosh, NeXT, and other systems) and the \application{em{\TeX}}
NeXT is Unix, no need to mention it separately.
distribution for \acronym{MS-DOS} and \acronym{OS/2}
Missing period at end of sentence.
This TWG recognizes that subdirectory searching places an extra burden
The TWG recognized ...
As an immediate consequence of the search strategy outlined
I'm not sure it's ``immediate''.
above, one cannot place variants of a file with the same name in
Well, you *can*. I mean, it's physically possible. I suggest wording
something like this:
... above, two files in a search path with the same name leads to
ambiguity. The TDS does not define which one is found. To disambiguate
this case, one must specify a search path that lists the respective
subtrees in the search order as needed.
(But, I have comments on your text, in case you keep it:)
If one wants to use diffferent versions, one has to specify
Three f's.
a \systemitem{ENVIRONVAR}{TEXINPUTS} search path that lists
You don't want to particularize to TEXINPUTS here.
the respective subtrees in the search order as needed. Then the file
.... Then the filenames
Having accepted that subdirectory searching was necessary, the TWG
agreed to adhere to the following constraints in designing the \TeX\ Directory Structure.
... the TWG adhered ...
(The only people we agreed with were ourselves!)
problem is surmountable. In particular, note that \acronym{MS-DOS},
... In particular, on
(I have an aversion to ever saying `Note that', since it's 100%
redundant with itself, and you can say that again.)
\textsc{UNIX} platforms can use symbolic links (that most of them now support)
The remaining case is Unix, but Unix systems can use hard or symbolic links
[and delete the parenthetical, or move to after the next sentence.]
Automatic font generation is a big win on systems that do not have
access to scalable fonts. It is important that the \TeX\ Directory Structure not restrict
... big win on TeX systems, since then Computer Modern and other such
bitmapped fonts can be used at any size without human intervention.
(It has nothing to do with scalable fonts...)
the applicability of automatic font generation. The arrangement
I don't see the ``constraint'' here, though. What does automatic font
generation imply for the needs of a TDS? Nothing that I can see.
If this bulleted item goes, so can the other one, and it just be the
main text of the section.
is called called \filename{texmf}, although the exact name
Only one `called'.
Similarly the location of
Comma after `Similarly'.
many systems, this may be at the root of the filesystem; however, on
No `however'.
\filename{/usr/local}.
or /usr/local/lib.
it reflects the fact that the directory contains more than {\TeX} files
(it also contains fonts), it is likely to be unused, and it is
Not only does it also contain fonts, it contains BibTeX inputs, etc.,
etc. Something like: the directory contains files to an entire TeX
system, including Metafont, BibTeX, etc., not just TeX itself.
The \filename{texmf} root \emphasis{should not} be placed
`is not intended to be' instead of `should not'? I don't see any dire
consequences resulting from doing this. The crucial thing is that the
TDS already makes provision for the implementation-specific files, so
there's no point to putting them outside the tree.
under a system-dependent directory. For example, \filename{texmf}
should not be created in the \filename{emtex} or \filename{pctex}
directories!
The ! seems like overkill.
Awareness of the fact that storing all of the {\TeX} files (including
system-dependent files such as binaries) under a single tree can be very
useful, has resulted in a few extensions within the \TeX\ Directory Structure to allow these
files to coexist.
I don't see that this has anything much to do with `rooting the
tree'. Anyway, you already have substantially the same text in the next
section, so I'd delete it here.
[tex] for the input files used by {\TeX}.
May as well have a ref to the relevant chapters for each of these.
\item[\replaceable{utility}]
This came out in the wrong font (bold italic), as discussed above.
Also, instead of `utility', how about `program', and have `emtex' and
`web2c' as other examples.
As I'll write in a subsequent message, I think `bibtex' should have its
own line (and chapter).
administration if the {\TeX} tree is maintained by someone other than
adminstration, especially if ...
(It's good even if texadmin == sysadmin.)
be used for other, standard, purposes (at the discretion of the installer
and system administrator):
`installer and system administrator' => `TeX administrator'?
Also, I would combine the following list with the previous list, so
there is one and only one list of top-level directories. I don't see any
need to separate them. Put the `Although designed...' paragraph
afterwards, and just say `not all these directories may be needed by all
sites' beforehand.
\item[\replaceable{utility}]
for \replaceable{utility} configuration files
(e.g. \filename{dvips}, \filename{bibtex}, \filename{makeindx},
etc.).
Already had this in the previous list. (I would add `dvips' to the list
of examples along with `makeindx'.) So can delete it here.
The \replaceable{system} directories allow multiple
implementations to share the common directory structure. For example,
the binaries for em{\TeX} might be installed in \filename{/texmf/bin/emtex}.
I think the word `system' is being overloaded here. texmf/bin/emtex is
fine -- but Unix binaries require a directory per architecture, not per
TeX implementation.
The current practice of lumping files into a single directory (or a
The common current practice ...
(There's no such thing as ``the'' current practice, or we wouldn't have
needed to create a TDS in the first place!)
To combat this maintenance problem, the \TeX\ Directory Structure specifies that macros
How about `help solve' instead of `combat'? Or `ameliorate' or `ease'?
\replaceable{format}\filename{/}
The spacing looks funny here (and in all other similar places) --
there's a space after the / (due to the eol), but none before. I don't
have strong feelings about which it should be (maybe no space to match
the no spaces in the literal `texmf/tex'?) but at least it should be
consistent.
examples of \replaceable{format}. Note that some of these
Note that => Although
For some formats, it may be natural to search more than one format
directory. For example, the \filename{amstex} and
\filename{plain}, and \filename{generic}
directories may be searched when using {\AmS}{\TeX}.
Thus, for almost every \replaceable{format}, it is correct to search the
format directory, and then the generic directory (in that order).
It may be necessary to search other directories as well. For example,
the \filename{amstex}, \filename{plain}, and \filename{generic}
directories should be searched when using {\AmS}{\TeX}.
(In any case, note you have an extra `and' after \filename{amstex}.)
Also, before this paragraph, I think we should explain the intended
difference between `plain' and `generic' (or maybe this should be
combined with your current text in some way):
The plain/ directory is intended for files which are only useful with
the plain TeX format: fontchart.tex, testfont.tex, story.tex,
manmac.tex, webmac.tex, etc., as well as plain.tex itself. The generic/
directory, by contrast, contains files which can be used with LaTeX
and/or AMSTeX as well as Plain: btxmac.tex, path.sty, texnames.sty,
null.tex, etc.
Packages that consist of \emphasis{only} a single file shall be
installed in the \filename{misc} package directory.
How about formats that have no subpackages and consist only of a single
file? I think it should be tex/texinfo/texinfo.tex, not
tex/texinfo/base/texinfo.tex.
(This should probably be a separate paragraph in the `format' item.)
For packages that consist of a single file, it seems pointless to
nest them within a directory of their own.
It seems pointless to nest such a package/file within a directory of
its own.
(Avoid repeating the `packages that consist' clause.)
The arrangement
actually adopted tends to spread files out into two or three places
(consider a package which includes extensive documentation and fonts).
Huh? We should only talking about TeX inputs here, shouldn't we? I'm
glad we have this section, and I think it's important, but I think it
should be somewhere else. An Is there a better way for the whole thing?
It has been demonstrated that this arrangement is usable in a production
environment whereas the alternative would be much more experimental.
In addition, several members of the TWG already have arrangements that are
similar to the \TeX\ Directory Structure and the CTAN archives have
a similar arrangement.
The fact that several members ... similar to the TDS demonstrates that
this arrangement is usable (proof by example). The alternative
arrangement is not in use at any known site, and the TWG felt it wrong
to mandate something with which there is no practical experience.
(I think the CTAN stuff is irrelevant to the argument.)
\section{{\protect\MF}}
How about `Non-font \MF inputs' as a name?
\filename{texmf/mf/mf}
What's the point of the extra mf/? What else goes in texmf/mf besides
these random files?
\filename{texmf/fonts/\replaceable{type}/\replaceable{source}/\replaceable{typeface}/\replaceable{files}}
Oh, I see, \replaceable comes out differently inside \filename than
outside. (In this case, it comes out as cmitt10, but everywhere else in
the document, it's regular italic.) Anyway, I'm still voting for
cmsltt10 everywhere, for the umpteenth time :-).
Font sources ({\protect\MF} files, property lists, etc.)
Uncapitalize the `Font'. Or else put a period at the end of the line.
Virtual fonts
virtual font metrics
(Trying to distinguish from .vpl here ...)
\filename{PK} bitmapped fonts
Just `PK files', I think. You didn't say `TFM font metric files'...
is the name of the font vendor or ``\filename{public}'' for
I think we should have the rationale for `public' here, from, e.g., that
recent message of Pierre's: it serves a good practical purpose. We don't
mean to necessarily be separating out the fonts you pay for from the
fonts you can get for free (e.g., Utopia, etc.) Make `ams' one of the
example sources, and that will be even clearer.
Also, there's no need for ``...'' around public, I think. The font
change to typewriter is enough. You don't quote anything else.
Perhaps it would be good to mention `Filenames for fonts' as a list of
sources (and typefaces, in the next item).
and \literal{latex} for the
extensions to Computer Modern distributed by the {\LaTeX} team.
I don't see this as a special case; latex seems like a perfectly
reasonable source to me. Also, it's not just extensions to Computer
Modern but the lasy* fonts as well. I'd just drop this phrase and add
`latex' as another example source.
I don't see knuth as a special case, either, but I'm arguing against
that in a separate msg.
type of printer (mode) for which the font was created and the
`device' would be more correct than `printer'.
directories. To identify the resolution, there are two common ways of
I think this second `To identify' should start a new paragraph.
For example, the same 300dpi bitmap would be named
\filename{cmr10.pk} in the directory \filename{300dpi}.
... would be named dpi300/cmr10.pk.
(It is typically dpi300 and not 300dpi, isn't it?)
Since long filenames are technically impossible on many file systems,
... are not allowed by many ... (ref constraints)
the \TeX\ Directory Structure has adopted the latter scheme for
the TDS must use the latter ...
naming fonts. Under the \filename{pk} directory, two more
fonts. Therefore, under the ...
\filename{ljfour}, \filename{canoncx}, and
cx, please, not canoncx.
Maybe mention modes.mf as a reference list?
For PostScript fonts rendered as bitmaps with the \command{ps2pk}
program, the mode \filename{ps2pk} should be used.
Ditto gsftopk.
consist of the string \filename{dpi} followed by the numeric
value of the resolution in decimal. \filename{dpi300},
\filename{dpi328}, and \filename{dpi1404} are
Rounded value or truncated value? Presumably the former. Then you want
dpi329, not 328.
The \TeX\ Directory Structure recommends the use of \filename{dpi300/cmr10.pk} for font
We don't recommend, we specify or mandate. In this case, anyway.
Also, I'd move this paragraph down to `Is there a better way'.
naming syntax as it is the
least-common-denominator (and therefore most portable) form. Extensions
... as it is the only portable form across present-day operating
systems. Extensions
and (b) neither gain nor loss of functionality accrues from this
variation.
Do you have any particular gain or loss in mind? I can't see how there
could be any. I'd just drop this clause.
There was almost immediate recognition within the TWG of the fact that
the use of short filenames has many disadvantages.
The TWG recognizes that the use ...
same name (\filename{cmr10.pk} identifies Computer Modern Roman 10pt
at 5--10 magnifications for 2--3 resolutions on many
systems).
same name. At a typical site, cmr10.pk will be the filename for Computer
... resolutions.
Within the \TeX\ Directory Structure, every \filename{PK} file \emphasis{must} contain
The TDS specifies that PK files must contain
This may seem autocratic, and perhaps, strictly speaking,
No perhaps about it. But I don't think it matters. We don't need to
apologize for it; I think maybe this paragraph can be tossed.
file derived from Karl Berry's \filename{modes.mf} distribution, the
derived from (or is in fact)
No other issue caused as much
heated debate among the members of the committee as the issue of the
font directory structure.
The TWG struggled more with the font directory structure than anything else.
little more we can do.
In other words, we're standardizing on something known to be insufficient.
Oh, well.
(I'm just randomly complaining, ignore me.)
packages themselves, but it seemed to be important that users find
source files for the packages, but ...
is a nuisance. And since developers and distributors bemoan all the
time that users don't read their documentation, it is important that
no additional barriers are introduced. For these reasons, we decided
Don't see the need for this sentence (And since ...).
find the particular documentation they were after.
In addition to this: we've already split up a package's file all over
creation, so the doc files may as well follow along.
for each package, in a tree like the \filename{tex}
... tree paralleling ...
Miscellaneous help
and information files (like the \acronym{FAQ}) should be stored in
the directory
\filename{help} and general purpose documents
should be stored in the directory \filename{general}.
Two special categories: `help' for metainformation, such as FAQ's,
David Jones' macro index, etc. `general' for standalone documents not
part of any package: Michael Doob's A Gentle Introduction to TeX,
Joachim Schrod's Components of TeX, texbook.tex and mfbook.tex, etc.
(I think we should make the distinction a little clearer.)
to document (or automate) how the files should be moved from the
(or, preferably, automate)
For example, a package for Martian language typesetting might include
the following files:
... might be distributed as the following:
the working TDS structure which looks something like this:
Delete `something'.
\section{Example}
Instead of `Example', I think we should make this `Summary', and provide
not just a minimal set of directories, but (more or less) every
directory in a small-but-real system.
I think this would also help pull together everything from the preceding
text.
I'll work on this, unless you have some problem with it!
texmf/fonts/knuth/cm/pk/canoncx
texmf/fonts/knuth/cm/pk/canoncx/dpi300
cx, not canoncx
texmf/tex/plain/amstex
Is there something in particular that goes in here?
I can't even think what something like this would mean -- wouldn't all
amstex files go in texmf/tex/amstex?
That's it!
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 08:43:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 13 Feb 1995 09:42:47 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
To: TWG-TDS@SHSU.edu
Message-ID: <792686567.936052.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
although i agree with pierre and karl that the knuth fonts are
"public", i think it's valuable to be able to identify which are
the *original* set and which are extensions, as the additional
sizes of cmmib in amsfonts and even more in the sauter complement.
for that matter, the amsfonts and those generated by the sauter
parameters are also "public" in the sense considered, but it would
also be useful for these to be separately identifiable.
at ams, we are now accepting papers for our publications in dvi
form. the policy on fonts is that either the knuth or amsfonts
can be used with no restriction, but that any other fonts either
require special prior arrangements or will be rejected. recently
we received a paper that used cmss7, a size that was in neither
the knuth nor the amsfonts complement. we were on the point of
rejecting it, but found that cmss7 had been implemented here
for a special request. even then, i'm not certain that the
checksums matched. we need to make these restrictions in order
to minimize the amount of time needed for processing, and if
authors are to be able to comply with our restrictions, they
have to be able to figure out with a mimimum of hassle exactly
what they are allowed to use. combining all "public" fonts
into one bucket won't be helpful in that situation.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 09:00:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 09:55:10 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131455.JAA01065@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
References: <199502131154.AA01144@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:10, K. Berry wrote:
> I think there should be a chapter on bibtex in the tds -- it needs to be
> almost as long as the chapter on Metafont :-). E.g.,
>
> The TDS specifies two subdirectories of the top-level `bibtex'
> directory:
>
> bib -- for bibliography (.bib) files
> bst -- for bibtex style (.bst) files
>
> Rationale: this is in line with the general approach of the TDS to put
> files of a particular type in a common directory.
Actually, I thought I had removed references to the 'bib' and 'bst'
directories. Where did you find them?
Anyway, I removed them because I didn't want it to look like we were
playing favorites. Yes, BibTeX is used by *a lot* of users, but there
are many that don't use it at all and many that use tib instead, etc.
I relegated BibTeX to the "utility" category (page 6).
I could be convinced to move BibTeX back up, but is it really necessary?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 09:02:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 09:58:17 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131458.JAA01368@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
References: <199502131154.AA01128@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:08, K. Berry wrote:
> The current tds draft has:
>
> [for a font source] \literal{knuth} for the
> original Computer Modern fonts
>
> As Pierre wrote, I don't see the necessity for this. It's just another
> directory where users and programs have to look for stuff. It's not like
> its contents are going to be enlarged, ever again.
>
> So I suggest we merge cm into public.
Unlike other "public" fonts, the Knuth fonts are special. They are
absolutely required to run TeX (you can configure TeX so that isn't
true, obviously, but who does?).
They also have special significance to the AMS, as Barbara pointed
out.
It's also a nod to the Grand Wizard.
> (In any case, it wouldn't be just the ``original Computer Modern
> fonts'', but also concrete and logo and manfnt, presumably...)
True. That doesn't bother me too much, though.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 09:05:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 10:00:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131500.KAA01581@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502131154.AA01112@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:07, K. Berry wrote:
> The current TDS allows:
>
> \item[\filename{bin}/\replaceable{system}] for binaries
>
> I think system/bin is also ok ... I don't think we can possibly (or need
> to) legislate whether a site wants sun4/bin or bin/sun4.
Fair enough.
>
> \item[\filename{ini}/\replaceable{system}]
> for pool files, format files, and base files.
>
> I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
> etc., as top-level directories, like `makeindx' and `bibtex'. That would
I don't remember saying that. The purpose of bin/system and ini/system
was for "bin/emtex" and "ini/emtex". As you note abouve, "emtex/ini"
and "emtex/bin" are equivalent.
> Also, I think we should allow a top-level directory `info' for the
> program-readable .info files produced from Texinfo source.
Agreed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 09:12:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 10:08:21 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131508.KAA02314@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131154.AA01120@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:07, K. Berry wrote:
> The current draft of the tds has:
>
> \item[\filename{pfa}] Type 1 fonts in \filename{PFA} format
> \item[\filename{pfb}] Type 1 fonts in \filename{PFB} format
>
> I don't see anything in the archives that explains why we're
> distinguishing these. It would simplify the paths to put them in one
> directory, called, say, `type1'.
I'd like to do that, but every other directory name is based purely
on the filename extension.
> In practice, I think
> 1) it's highly dubious that people will have both a pfa and a pfb for
> the same font; so we're not making the directories any smaller by
> separating them.
> 2) every extant program can read both kinds if it can read either (at
> least ghostscript and dvips can; not sure about ps2pk). So it's
> not making any practically useful distinction to separate them,
> either.
It's not a useful distinction, I agree. But we can't mandate one or
the other.
> Put another way, every time .../pfa is put in someone's path, .../pfb is
> needed also. So let's make everyone's life easier and put them together
> in the first place.
Yeah, it's true. What does everyone think? Break the filename extension
rule for this case?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 09:56:49 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
Date: Mon, 13 Feb 1995 15:55:46 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:276840:950213155606"@cl.cam.ac.uk>
i agree with Norm. if the algorithm says file name extension, dont
break it. how about just omit pfa from the example, and leave it top
people to wonder...
s
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:04:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:04:35 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131604.AA29762@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
Actually, I thought I had removed references to the 'bib' and 'bst'
directories. Where did you find them?
I didn't. I wanted them back in.
Anyway, I removed them because I didn't want it to look like we were
playing favorites.
It's not a question of playing favorites. It's a question of saying what
needs to be said. See below.
Yes, BibTeX is used by *a lot* of users, but there
are many that don't use it at all and many that use tib instead, etc.
If tib needs a directory with substructure, then by all means let's
mention that as well.
However, I don't think bibtex and tib are symmetrical: every TeX
installation (at least every one I've ever heard of) includes
bibtex. That's not true for tib.
I relegated BibTeX to the "utility" category (page 6).
I know. I think it deserves its own category.
I could be convinced to move BibTeX back up, but is it really necessary?
I think so. Right now, the bib and bst files are installed at different
places at different sites. Isn't rationalizing this the whole purpose of
the TDS?
Most utilities -- e.g., dvips -- install any aux files during normal
program installation. Thus the TDS doesn't need to specify anything
(beyond allowing `dvips' as a top-level directory). But bibtex is
different. People retrieve new .bib (and occasionally .bst) files all
the time. Where do they go?
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:07:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:07:28 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131607.AA29773@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
Norm> It's not a useful distinction, I agree. But we can't mandate one or
the other.
I don't see that we're mandating anything by saying both pfa and pfb
files go into one directory named type1, instead of two different directories.
Sebastian> i agree with Norm.
It's not clear to me that Norm was saying keep pfa/pfb.
if the algorithm says file name extension, dont
What algorithm?
*We* made the rule. We can break it if we want.
I don't see the downside here.
As I said, two different directories is *harder* for programs and people
to deal with, not easier.
break it. how about just omit pfa from the example, and leave it top
people to wonder...
Surely you jest.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:13:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:13:22 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131613.AA29800@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
> I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
> etc., as top-level directories, like `makeindx' and `bibtex'. That would
I don't remember saying that.
I remember Alan (I think) saying at one point that it would be quite
strange to allow a top-level directory for relatively obscure utilities
like makeindex, but to relegate the main TeX implementation itself to
subdirectories!
As you note abouve, "emtex/ini" and "emtex/bin" are equivalent.
I noted this? Now I'm very confused.
OK, let's put it this way:
I propose we
1) say the contents of the bin directory (or a `sun4'-like directory)
are purely up to the texadmin;
2) remove the ini/ directory;
3) explicitly allow TeX implementations to have their own top-level
directory, where not only .fmt/.base files can go, but also
configuration files.
Otherwise, where do web2c's and emtex's runtime config files go?
And, given the need for this, an ini/ directory seems redundant.
This is simply being consistent with the rule that each program that
needs it gets a top-level directory to put whatever files it needs in.
If dvips, why not emtex?
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:15:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 95 16:14:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502131614.AA03910@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
I could be convinced to move BibTeX back up, but is it really necessary?
I'd go with Karl on this one, The base TDS ought to say what to do
with any files in a standard `TeX distribution' and that includes
bibtex. If you want, you could mention tib (or others) as possible
`utility' programs that could have their own branch off the tds.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:18:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:14:22 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131614.LAA08358@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
References: <199502131604.AA29762@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:04:35, K. Berry wrote:
> Actually, I thought I had removed references to the 'bib' and 'bst'
> directories. Where did you find them?
>
> I didn't. I wanted them back in.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:20:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:20:40 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131620.AA29922@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
barbara> i think it's valuable to be able to identify which are
the *original* set and which are extensions, as the additional
sizes of cmmib in amsfonts and even more in the sauter complement.
I completely agree.
The AMS files would be in ams/extracm, and sauter in public/sauter.
public/cm (or knuth/cm, for that matter) would be for the original 75.
Unlike other "public" fonts, the Knuth fonts are special. They are
absolutely required to run TeX
Doesn't seem like an argument for a separate directory to me.
They also have special significance to the AMS, as Barbara pointed
out.
This is not affected by whether they're in knuth/ in public/, as I point
out above.
It's also a nod to the Grand Wizard.
Who could care less about it.
Oh well. I don't care as much about fonts/knuth as I do pfa/pdb, because
at least no one ever has to specify a path that explicitly says
/blah/blah/knuth:/blah/blah/public, etc. So it's more an annoyance and
slight inefficiency of another directory to search than anything else.
I just don't see the point of being annoyed and inefficient :-).
> (In any case, it wouldn't be just the ``original Computer Modern
> fonts'', but also concrete and logo and manfnt, presumably...)
True. That doesn't bother me too much, though.
It doesn't bother me, either. I was pointing out (maybe I did so more
explicitly in the editorial message?) that the current text was
misleading -- it says the knuth/ directory will have only the CM fonts.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:16:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131616.LAA08584@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131607.AA29773@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:07:28, K. Berry wrote:
> Sebastian> i agree with Norm.
>
> It's not clear to me that Norm was saying keep pfa/pfb.
I was leaving it the way it was.
> if the algorithm says file name extension, dont
>
> What algorithm?
> *We* made the rule. We can break it if we want.
> I don't see the downside here.
Fine, "type1" it is.
> As I said, two different directories is *harder* for programs and people
> to deal with, not easier.
>
> break it. how about just omit pfa from the example, and leave it top
> people to wonder...
>
> Surely you jest.
Yeah, Sebastian, you *were* joking weren't you? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:24:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:19:52 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131619.LAA08873@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502131613.AA29800@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:13:22, K. Berry wrote:
> I remember Alan (I think) saying at one point that it would be quite
> strange to allow a top-level directory for relatively obscure utilities
> like makeindex, but to relegate the main TeX implementation itself to
> subdirectories!
>
> As you note abouve, "emtex/ini" and "emtex/bin" are equivalent.
>
> I noted this? Now I'm very confused.
In your message, you pointed out that we should allow "bin/sun4" or
"sun4/bin". I extended this to include implementations as well, not
thinking of the fact that a single OS might have multiple implmentations,
which it will.
> 1) say the contents of the bin directory (or a `sun4'-like directory)
> are purely up to the texadmin;
Ok.
> 2) remove the ini/ directory;
What about ini files that aren't implementation-specific, like hyphenation
patterns? I thought that's what ini was for.
> 3) explicitly allow TeX implementations to have their own top-level
> directory, where not only .fmt/.base files can go, but also
> configuration files.
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:25:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 95 16:25:07 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502131625.AA03919@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
Karl
OK, let's put it this way:
I propose we
1) say the contents of the bin directory (or a `sun4'-like directory)
are purely up to the texadmin;
2) remove the ini/ directory;
3) explicitly allow TeX implementations to have their own top-level
directory, where not only .fmt/.base files can go, but also
configuration files.
Sounds OK to me (all three)
I was never that fond of initex specific directories (except obvious
things like hyphenation) although I thought having them was the
majority view...
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:30:07 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:29:56 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131629.IAA03240@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: type1 fonts in the tds
ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
look into the possibility of incorporating that step into the
basic code of ps2pk
I would have preferred to stick with type1, particularly since I
have been using type1/ as the final directory in the tree for
three years now. (Lots of links to pfa/, of course) The
division into pfa/ and pfb/ seems just fussy.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:30:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:29:56 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131629.IAA03240@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: type1 fonts in the tds
ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
look into the possibility of incorporating that step into the
basic code of ps2pk
I would have preferred to stick with type1, particularly since I
have been using type1/ as the final directory in the tree for
three years now. (Lots of links to pfa/, of course) The
division into pfa/ and pfb/ seems just fussy.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:34:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:29:58 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131629.LAA09828@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131629.IAA03240@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 08:29:56, Pierre MacKay wrote:
> ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
> look into the possibility of incorporating that step into the
> basic code of ps2pk
I think you're mistaken Pierre. Unless I've lost my mind (a possibility
that I cannot completely rule out), I've done ps2pk's on PFBs many
times.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:45:40 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:45:33 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131645.IAA04403@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
Doesn't the distinction between CM and EXTRACM, etc., achieve this? If it
is understood and stated that the cm directory contains exactly
the mf sources and derived fonts etc that are canonized by volume
E of Computers and Typesetting, then additions to that, whether
precompiled sauter interpolations or extracm-style reeditions
of the parameter files are clearly separate.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:55:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:55:27 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131655.IAA05398@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
The manual says that pfb2pfa is required!!!???
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 10:59:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:54:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131654.LAA12403@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131655.IAA05398@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 08:55:27, Pierre MacKay wrote:
> The manual says that pfb2pfa is required!!!???
Nevertheless,
norm@jasper$ ps2pk -V -P10 -a/usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ./gbk.300pk
Trying to open /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb
Trying to open /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm
Loading encoding vector from /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm ... done
Checking /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb font ... done
Creating character glyphs for /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ...^Cnorm@jasper$ ps2pk -V -P10 -a/usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ./gbk.300pk
Trying to open /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb
Trying to open /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm
Loading encoding vector from /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm ... done
Checking /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb font ... done
Creating character glyphs for /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ... done.
Creating ./gbk.300pk from /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb.
'040 '041 '042 '043 '044 '045 '046 '047
'050 '051 '052 '053 '054 '055 '056 '057
'060 '061 '062 '063 '064 '065 '066 '067
'070 '071 '072 '073 '074 '075 '076 '077
'100 '101 '102 '103 '104 '105 '106 '107
'110 '111 '112 '113 '114 '115 '116 '117
'120 '121 '122 '123 '124 '125 '126 '127
'130 '131 '132 '133 '134 '135 '136 '137
'140 '141 '142 '143 '144 '145 '146 '147
'150 '151 '152 '153 '154 '155 '156 '157
'160 '161 '162 '163 '164 '165 '166 '167
'170 '171 '172 '173 '174 '175 '176 '241
'242 '243 '244 '245 '246 '247 '250 '251
'252 '253 '254 '255 '256 '257 '261 '262
'263 '264 '266 '267 '270 '271 '272 '273
'274 '275 '277 '301 '302 '303 '304 '305
'306 '307 '310 '312 '313 '315 '316 '317
'320 '341 '343 '350 '351 '352 '353 '361
'365 '370 '371 '372 '373
norm@jasper$
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 11:23:48 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 09:19:32 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131719.JAA08405@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
If pfb2pfa is not necessary, so much the better. I never had
the occasion to find out, because I always convert to pfa
for other reasons.
Makes an even better case for consolidating pfb and pfa in one
type1 directory.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Feb 1995 13:31:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 17:32:24 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950213173224.22001967@vms.rhbnc.ac.uk>
Subject: Re: type1 fonts in the tds
>> The manual says that pfb2pfa is required!!!???
Sometimes the author loses control of his own code! I can confirm
that the MS/DOS version is very happy with PFB files. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Feb 1995 05:32:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Feb 1995 06:32:22 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502141132.AA12549@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
What about ini files that aren't implementation-specific, like hyphenation
patterns? I thought that's what ini was for.
Now, hyphenation patterns are something entirely different. That was the
subject of another message of mine; maybe it never made it out. In the
draft I read over the weekend, ini/ was only for pool/base/fmt
files. Hyphenation patterns were stored in a top-level initex directory.
Here's my msg arguing for removal of initex/:
To: twg-tds@shsu.edu
Subject: the initex directory
I hate to reopen this discussion, but the current draft of the tds
specifies a top-level initex directory.
Doesn't such a thing imply another whole set of things that have to go
in the paths, and where people & programs have to look?
I'm not sure I see the need. In the old mail, the things suggested for
it were
1) base files, like plain.tex and latex.ltx. Surely people would be more
inclined to find these in tex/<format>/base?
2) Joachim's unnamed initex-only files. They could be considered as
a package (if they aren't already) and put in tex/<package>?
3) hyphenation files. Could go in tex/hyphen.
Is there a practical advantage to the top-level initex/ to outweigh the
practical disadvantage?
By the way, these things kind of worry me. I'm just reading the
document, not actually trying to make a system [yet] that conforms to
it. I don't think the TDS should be declared official-and-accepted until
several implementations are actually distributing something that
conforms to it. Otherwise, we're just playing theoretical games.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Feb 1995 15:40:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Feb 1995 16:35:47 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502142135.QAA10716@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502141132.AA12549@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 February 1995 at 06:32:22, K. Berry wrote:
> What about ini files that aren't implementation-specific, like
> hyphenation patterns? I thought that's what ini was for.
>
> Now, hyphenation patterns are something entirely different. That was the
> subject of another message of mine; maybe it never made it out. In the
> draft I read over the weekend, ini/ was only for pool/base/fmt
> files. Hyphenation patterns were stored in a top-level initex directory.
>
> Here's my msg arguing for removal of initex/:
>
> To: twg-tds@shsu.edu
> Subject: the initex directory
>
> I hate to reopen this discussion, but the current draft of the tds
> specifies a top-level initex directory.
>
> Doesn't such a thing imply another whole set of things that have to go
> in the paths, and where people & programs have to look?
>
> I'm not sure I see the need. In the old mail, the things suggested for
> it were
> 1) base files, like plain.tex and latex.ltx. Surely people would be more
> inclined to find these in tex/<format>/base?
> 2) Joachim's unnamed initex-only files. They could be considered as
> a package (if they aren't already) and put in tex/<package>?
> 3) hyphenation files. Could go in tex/hyphen.
>
> Is there a practical advantage to the top-level initex/ to outweigh the
> practical disadvantage?
I agree with Karl and vote we remove both /ini and /initex from the
TDS.
> By the way, these things kind of worry me. I'm just reading the
> document, not actually trying to make a system [yet] that conforms to
> it. I don't think the TDS should be declared official-and-accepted until
> several implementations are actually distributing something that
> conforms to it. Otherwise, we're just playing theoretical games.
Agreed. You know, though, that one of the Linux distributions comes darn
close. I was amazed when it came installed on my new system ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Feb 1995 16:46:23 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 14 Feb 1995 14:46:19 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502142246.OAA10079@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
Without wanting to make excessive claims, I try to rework UnixTeX
into conformity with TDS in any parts of the tree that seem stable.
It is difficult though. ini/ has just disappeared again, and I am
still not quite clear on what to do with doc/
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Feb 1995 18:00:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Feb 95 00:57:26 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502152357.AA15308@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
: Agreed. You know, though, that one of the Linux distributions comes darn
: close. I was amazed when it came installed on my new system ;-)
Are you speeking of teTeX? It was me who set up this distribution. I listen
to this mailing-list since approx. 08/94 and I tried anticipiate the
(hopefully) upcoming TDS.
Maybe, teTeX will be fully TDS compiliant some day (since all drivers and the
web2c package use Kpathsea-2.6, I am very flexible (thanks Karl!)).
Any comments about the arrangements in teTeX are welcome.
Thomas
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 07:07:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 08:02:28 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011302.IAA10838@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <199502031155.MAA13902@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 12:55:43, Joachim Schrod wrote:
> I'm all in favor for specifying a directory for sources. It should be
> listed as one element in the set of ``additional directories [to] be
> used for other standard purposes'', like bin/, ini/, etc.
> "src/web2c/, src/latex/base, etc." are IMO a good example list for
> that item. (Btw, I don't care for the name `src', I would use
> `source', too. It's just my Unix-oriented attitude that shows off. :-)
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 07:07:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 08:03:21 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011303.IAA10859@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
References: <199502031319.OAA16518@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 14:19:47, Joachim Schrod wrote:
> Norm wrote:
> >
> > 2) A place for local packages and styles:
> >
> > /texmf/local/<format>/...
> >
> > 3) A place for local fonts:
> >
> > /texmf/fonts/<type>/local/<typeface>/...
>
> I don't like this.
>
> [...]
>
> 2+3) Add an explicit hint that more than one texmf tree may be
> available and should be usable in an installation. In particular, the
> constellation of one texmf tree that is an (unchanged) distribution
> and another texmf tree for local adaptions/enhancements/replacements
> is not uncommon.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 07:12:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 08:07:35 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011307.IAA10881@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: comments on twg-tds draft
References: <199502081642.IAA00250@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 8 February 1995 at 08:42:45, Pierre MacKay wrote:
> Has anyone else noticed the subtle effect of genuine rationality
> in the example in section 9?
>
> Section 5.2 despairs of the {\it source}-first organization, but there it
> is again in Section 9. I don't hold out any hope for a return to
> {\it source}-first as opposed to {\it type}-first, even though the
> latest version of kpathsea searching on my creaky old no-memory
> Sun 3-50 strongly validates Karl's claims for it. But the example
> will need to be consistent with the recommendations in 5.2 whatever
> they are.
Fixed.
> I should like also to plead for the retention of the {\it public}
> designation for a wide range of fonts and, on the whole, even to put
> cm among them. DEK is really not a foundry, and I doubt that he
> really cares whether he is advertised as one. Karl Berry and I talked
> this out a while ago, and I think I was able to make the point that
> {\it public} can be used to designate fonts for which there is no
> problem of licensing when you send them out.
Sounds like a good rational. Are we agreed, then?
> Incidentally, does anyone know the status of Symbol and NewCenturySchoolbook?
> There has been some suggestion that these are open-license too.
>From whom? And where are they?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 08:40:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 09:36:21 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011436.JAA12150@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <199502131154.AA01104@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:05, K. Berry wrote:
> Editorial comments only, no one but Norm needs to read :-), sending to
> the list only for archiving.
Ditto. Well, Karl, you should probably read it.
> General comment #1: I don't see that the filename needs to have `twg-' in it.
Ok. I'll go with tdsguide this time around.
> General comment #2: I think `Unix' looks a lot better as `Unix' than
> `\textsc{UNIX}'.
Fine, no complaints from me.
> \title{A Directory Structure for Implementation-Independent {\TeX} Files \\ Version 0.61}
>
> We talk about implementation-specific files as well, and I think it's
> good for titles to be short and catchy, so how about tossing
> `Implementation-Independent'.
You got it.
> to install it. This has resulted in hundreds of slightly different
>
> ... slightly (or not so slightly) different
Check.
> (Text changes below not otherwise rationalized are just what struck me
> as slightly improved wording as I was reading.)
>
> structure for macros, fonts, and other implementation-independent {\TeX}
>
> ... other such
Check.
> In the long run a consistent directory structure will make it
>
> In the not-so-long run ...
Check.
>
> work on all modern architectures. In particular, it can be used
>
> `systems' instead of architectures, I think. Hardware seems irrelevant!
Check.
> on \textsc{UNIX} workstations, \acronym{MS-DOS} and \acronym{OS/2}
> \acronym{PC}'s, Macintoshes, and \acronym{VMS} machines.
>
> under Unix, MS-DOS, OS/2, Macintoshes, and VMS.
Check.
> (Also, by the way, \acronym is technically wrong here -- an acronym is
> an abbreviation that's pronounced as a word: NASA and FAQ are acronym;
> FBI (and VMS and PC and ...) are just abbreviations. No, I'm not saying
> you have to change the control sequence name :-)
Yes...well...
> local system uses the \TeX\ Directory Structure.
>
> ... Structure recommended here.
Check.
> (Also, I suggest saying the `\TeX Directory Structure (TDS)' here, and
> then using `TDS' in most of the rest of the document. You already do
> occasionally, and I think it would be clearer/shorter to use it
> routinely. It's a single concept, after all. And you use TWG ...)
Sure.
> files into a single unit; for the purposes of use, it is frequently
> more useful to segregate files (even similar files) from a single
>
> ..., it is traditional to segregate files ...
Check.
> \subsection{Conventions}
>
> A non-typographic convention you should note is that ``This document
> uses / to separate filename components, as on Unix, purely
> arbitrarily. The ideas are in no way Unix-specific.'' Or some such.
>
> Filenames are represented in constant width.
>
> `constant width' is not a term I've ever heard used as a noun. How about
> simply `typewriter type'? Or `monospaced type', if you want to be fancy.
Check.
> `constant width' weirdness, as above. It's not exactly that you should
> type them, either -- this isn't a user manual. I think `Literal text' is
> clear enough by itself.
Check.
> Replaceable text, like \replaceable{filename},
> identifies a class of things. You should specify some member of
> that class. Replaceable text is represented in constant width
> oblique.
>
> 1) `constant width' again.
> 2) The `replaceable' wasn't printed in italic typewriter here, but
> regular bold italic.
> 3) I think `package' would be a better example than `filename'.
> 4) The sentence `You should specify...' can be tossed, I think, as above
> about typing.
> 5) I suggest we use cmsltt10 for this stuff. It's always part of a
> filename (isn't it?), so some form of typewriter seems appropriate,
> rather than regular italics. cmitt10 is a truly weird-looking font; I
> think cmsltt10 is much cleaner.
Check.
> \subsection{Subdirectory Searching}
>
> Instead of making this part of the `Introduction' chapter, how about a
> new chapter 2, `Basics' or some such, and put this, Constraints, Rooting
> the tree, and Top Level Directories under it. I think that last should
> not be a subsection of Rooting, either.
Ok.
> system configuration file, for example), but this is insufficient in
> the general case.
>
> I don't know what `in the general case' means. Sounds like handwaving to
> me :-). How about `this is so cumbersome as to be unworkable at large
> sites'?
Wave, wave, wave. Ok.
> On systems without runtime configuration files,
>
> without some form of runtime configuration
> (Envvars would suffice, doesn't have to be config files.)
Check.
> As a result, the TWG decided that a comprehensive \TeX\ Directory Structure required
>
> `concluded' is better than `decided', I think. It wasn't an arbitrary
> decision. And here is a primse place to start `TDS' instead of `TeX
> Directory Structure'. Those capital letters in the middle of a sentence
> are disconcerting.
Yep.
> to specify that {\TeX} (and other {\TeX} utilities) search in both a
>
> `and Metafont and their companion' instead of `other \TeX`?
Ok.
> specified directory and recursively through all subdirectories of that
>
> ... and implicitly recursively ...
> (I think it's important to get the idea of ``implicitly'' across here;
> we mean you specify a single directory name and the program does the
> recursion, but that's not necessarily obvious from the present wording.)
Check.
> directory when looking for an input file,
> that is, a {\TeX} macro file, \filename{TFM} file, or a
> \filename{PK}
> bitmap font.
>
> There's a lot more kinds of input files than those! (.bst, .mf, ...). I
> suggest just deleting `that is ... bitmap font'.
Ok.
> Windows-NT, Macintosh, NeXT, and other systems) and the \application{em{\TeX}}
>
> NeXT is Unix, no need to mention it separately.
Ok.
> distribution for \acronym{MS-DOS} and \acronym{OS/2}
>
> Missing period at end of sentence.
Check.
> This TWG recognizes that subdirectory searching places an extra burden
>
> The TWG recognized ...
>
> As an immediate consequence of the search strategy outlined
>
> I'm not sure it's ``immediate''.
>
> above, one cannot place variants of a file with the same name in
>
> Well, you *can*. I mean, it's physically possible.
Yer evil, Karl. ;-)
> I suggest wording
> something like this:
>
> ... above, two files in a search path with the same name leads to
> ambiguity. The TDS does not define which one is found. To disambiguate
> this case, one must specify a search path that lists the respective
> subtrees in the search order as needed.
Check.
> (But, I have comments on your text, in case you keep it:)
> If one wants to use diffferent versions, one has to specify
Nope.
> ... the TWG adhered ...
> (The only people we agreed with were ourselves!)
Ok.
> problem is surmountable. In particular, note that \acronym{MS-DOS},
>
> ... In particular, on
> (I have an aversion to ever saying `Note that', since it's 100%
> redundant with itself, and you can say that again.)
Ok.
> \textsc{UNIX} platforms can use symbolic links (that most of them now support)
>
> The remaining case is Unix, but Unix systems can use hard or symbolic links
> [and delete the parenthetical, or move to after the next sentence.]
Check.
> Automatic font generation is a big win on systems that do not have
> access to scalable fonts. It is important that the \TeX\ Directory Structure not restrict
>
> ... big win on TeX systems, since then Computer Modern and other such
> bitmapped fonts can be used at any size without human intervention.
> (It has nothing to do with scalable fonts...)
>
> the applicability of automatic font generation. The arrangement
>
> I don't see the ``constraint'' here, though. What does automatic font
> generation imply for the needs of a TDS? Nothing that I can see.
> If this bulleted item goes, so can the other one, and it just be the
> main text of the section.
Ok, we'll try that.
> is called called \filename{texmf}, although the exact name
>
> Only one `called'.
>
> Similarly the location of
>
> Comma after `Similarly'.
>
> many systems, this may be at the root of the filesystem; however, on
>
> No `however'.
>
> \filename{/usr/local}.
>
> or /usr/local/lib.
>
> it reflects the fact that the directory contains more than {\TeX} files
> (it also contains fonts), it is likely to be unused, and it is
>
> Not only does it also contain fonts, it contains BibTeX inputs, etc.,
> etc. Something like: the directory contains files to an entire TeX
> system, including Metafont, BibTeX, etc., not just TeX itself.
Ok.
> The \filename{texmf} root \emphasis{should not} be placed
>
> `is not intended to be' instead of `should not'? I don't see any dire
> consequences resulting from doing this. The crucial thing is that the
> TDS already makes provision for the implementation-specific files, so
> there's no point to putting them outside the tree.
>
> under a system-dependent directory. For example, \filename{texmf}
> should not be created in the \filename{emtex} or \filename{pctex}
> directories!
>
> The ! seems like overkill.
Well, my concern is vendors assuming that they'll be at the top and
if you install several vendors TeX's, you'll get copies of everything.
But I'll go with your way...
> Awareness of the fact that storing all of the {\TeX} files (including
> system-dependent files such as binaries) under a single tree can be very
> useful, has resulted in a few extensions within the \TeX\ Directory Structure to allow these
> files to coexist.
>
> I don't see that this has anything much to do with `rooting the
> tree'. Anyway, you already have substantially the same text in the next
> section, so I'd delete it here.
Ok.
> [tex] for the input files used by {\TeX}.
>
> May as well have a ref to the relevant chapters for each of these.
Ok.
> \item[\replaceable{utility}]
>
> This came out in the wrong font (bold italic), as discussed above.
> Also, instead of `utility', how about `program', and have `emtex' and
> `web2c' as other examples.
I'll go with program, but emtex goes under /system and web2c
probably goes under /source.
> As I'll write in a subsequent message, I think `bibtex' should have its
> own line (and chapter).
Ok.
> administration if the {\TeX} tree is maintained by someone other than
>
> adminstration, especially if ...
> (It's good even if texadmin == sysadmin.)
Check.
> be used for other, standard, purposes (at the discretion of the installer
> and system administrator):
>
> `installer and system administrator' => `TeX administrator'?
Check.
> Also, I would combine the following list with the previous list, so
> there is one and only one list of top-level directories. I don't see any
> need to separate them. Put the `Although designed...' paragraph
> afterwards, and just say `not all these directories may be needed by all
> sites' beforehand.
Check.
> \item[\replaceable{utility}]
> for \replaceable{utility} configuration files
> (e.g. \filename{dvips}, \filename{bibtex}, \filename{makeindx},
> etc.).
>
> Already had this in the previous list. (I would add `dvips' to the list
> of examples along with `makeindx'.) So can delete it here.
Yep.
> The \replaceable{system} directories allow multiple
> implementations to share the common directory structure. For example,
> the binaries for em{\TeX} might be installed in \filename{/texmf/bin/emtex}.
>
> I think the word `system' is being overloaded here. texmf/bin/emtex is
> fine -- but Unix binaries require a directory per architecture, not per
> TeX implementation.
Yeah...but see what you think now that I merged it into the list... ;-)
> The current practice of lumping files into a single directory (or a
>
> The common current practice ...
> (There's no such thing as ``the'' current practice, or we wouldn't have
> needed to create a TDS in the first place!)
Ok.
> To combat this maintenance problem, the \TeX\ Directory Structure specifies that macros
>
> How about `help solve' instead of `combat'? Or `ameliorate' or `ease'?
Check.
> \replaceable{format}\filename{/}
>
> The spacing looks funny here (and in all other similar places) --
> there's a space after the / (due to the eol), but none before. I don't
> have strong feelings about which it should be (maybe no space to match
> the no spaces in the literal `texmf/tex'?) but at least it should be
> consistent.
Yeah, that's a bug I'll work on.
> examples of \replaceable{format}. Note that some of these
>
> Note that => Although
Check.
> For some formats, it may be natural to search more than one format
> directory. For example, the \filename{amstex} and
> \filename{plain}, and \filename{generic}
> directories may be searched when using {\AmS}{\TeX}.
>
> Thus, for almost every \replaceable{format}, it is correct to search the
> format directory, and then the generic directory (in that order).
>
> It may be necessary to search other directories as well. For example,
> the \filename{amstex}, \filename{plain}, and \filename{generic}
> directories should be searched when using {\AmS}{\TeX}.
> (In any case, note you have an extra `and' after \filename{amstex}.)
You got it.
> Also, before this paragraph, I think we should explain the intended
> difference between `plain' and `generic' (or maybe this should be
> combined with your current text in some way):
>
> The plain/ directory is intended for files which are only useful with
> the plain TeX format: fontchart.tex, testfont.tex, story.tex,
> manmac.tex, webmac.tex, etc., as well as plain.tex itself. The generic/
> directory, by contrast, contains files which can be used with LaTeX
> and/or AMSTeX as well as Plain: btxmac.tex, path.sty, texnames.sty,
> null.tex, etc.
Check.
> Packages that consist of \emphasis{only} a single file shall be
> installed in the \filename{misc} package directory.
>
> How about formats that have no subpackages and consist only of a single
> file? I think it should be tex/texinfo/texinfo.tex, not
> tex/texinfo/base/texinfo.tex.
> (This should probably be a separate paragraph in the `format' item.)
Huh?
> For packages that consist of a single file, it seems pointless to
> nest them within a directory of their own.
>
> It seems pointless to nest such a package/file within a directory of
> its own.
> (Avoid repeating the `packages that consist' clause.)
>
> The arrangement
> actually adopted tends to spread files out into two or three places
> (consider a package which includes extensive documentation and fonts).
> Huh? We should only talking about TeX inputs here, shouldn't we? I'm
> glad we have this section, and I think it's important, but I think it
> should be somewhere else. An Is there a better way for the whole thing?
Perhaps.
>
> It has been demonstrated that this arrangement is usable in a production
> environment whereas the alternative would be much more experimental.
> In addition, several members of the TWG already have arrangements that are
> similar to the \TeX\ Directory Structure and the CTAN archives have
> a similar arrangement.
>
> The fact that several members ... similar to the TDS demonstrates that
> this arrangement is usable (proof by example). The alternative
> arrangement is not in use at any known site, and the TWG felt it wrong
> to mandate something with which there is no practical experience.
>
> (I think the CTAN stuff is irrelevant to the argument.)
Ok.
> \section{{\protect\MF}}
>
> How about `Non-font \MF inputs' as a name?
I'll run it up the flag pole
>
> \filename{texmf/mf/mf}
>
> What's the point of the extra mf/? What else goes in texmf/mf besides
> these random files?
Sure.
> \filename{texmf/fonts/\replaceable{type}/\replaceable{source}/\replaceable{typeface}/\replaceable{files}}
>
> Oh, I see, \replaceable comes out differently inside \filename than
> outside. (In this case, it comes out as cmitt10, but everywhere else in
> the document, it's regular italic.) Anyway, I'm still voting for
> cmsltt10 everywhere, for the umpteenth time :-).
Ok.
> Font sources ({\protect\MF} files, property lists, etc.)
>
> Uncapitalize the `Font'. Or else put a period at the end of the line.
>
> Virtual fonts
>
> virtual font metrics
> (Trying to distinguish from .vpl here ...)
>
> \filename{PK} bitmapped fonts
>
> Just `PK files', I think. You didn't say `TFM font metric files'...
Ok.
> is the name of the font vendor or ``\filename{public}'' for
>
> I think we should have the rationale for `public' here, from, e.g., that
> recent message of Pierre's: it serves a good practical purpose. We don't
> mean to necessarily be separating out the fonts you pay for from the
> fonts you can get for free (e.g., Utopia, etc.) Make `ams' one of the
> example sources, and that will be even clearer.
Ok.
> Also, there's no need for ``...'' around public, I think. The font
> change to typewriter is enough. You don't quote anything else.
Check.
> Perhaps it would be good to mention `Filenames for fonts' as a list of
> sources (and typefaces, in the next item).
Yep.
> and \literal{latex} for the
> extensions to Computer Modern distributed by the {\LaTeX} team.
>
> I don't see this as a special case; latex seems like a perfectly
> reasonable source to me. Also, it's not just extensions to Computer
> Modern but the lasy* fonts as well. I'd just drop this phrase and add
> `latex' as another example source.
Ok.
> I don't see knuth as a special case, either, but I'm arguing against
> that in a separate msg.
It's gone.
> type of printer (mode) for which the font was created and the
>
> `device' would be more correct than `printer'.
Yep.
> directories. To identify the resolution, there are two common ways of
>
> I think this second `To identify' should start a new paragraph.
Ok.
> For example, the same 300dpi bitmap would be named
> \filename{cmr10.pk} in the directory \filename{300dpi}.
>
> ... would be named dpi300/cmr10.pk.
> (It is typically dpi300 and not 300dpi, isn't it?)
Yes.
> Since long filenames are technically impossible on many file systems,
>
> ... are not allowed by many ... (ref constraints)
>
> the \TeX\ Directory Structure has adopted the latter scheme for
>
> the TDS must use the latter ...
>
> naming fonts. Under the \filename{pk} directory, two more
>
> fonts. Therefore, under the ...
>
> \filename{ljfour}, \filename{canoncx}, and
>
> cx, please, not canoncx.
> Maybe mention modes.mf as a reference list?
Check, check, check, ...
> For PostScript fonts rendered as bitmaps with the \command{ps2pk}
> program, the mode \filename{ps2pk} should be used.
>
> Ditto gsftopk.
>
> consist of the string \filename{dpi} followed by the numeric
> value of the resolution in decimal. \filename{dpi300},
> \filename{dpi328}, and \filename{dpi1404} are
>
> Rounded value or truncated value? Presumably the former. Then you want
> dpi329, not 328.
Ok.
> The \TeX\ Directory Structure recommends the use of \filename{dpi300/cmr10.pk} for font
>
> We don't recommend, we specify or mandate. In this case, anyway.
> Also, I'd move this paragraph down to `Is there a better way'.
Ok.
> naming syntax as it is the
> least-common-denominator (and therefore most portable) form. Extensions
>
> ... as it is the only portable form across present-day operating
> systems. Extensions
Yep.
> and (b) neither gain nor loss of functionality accrues from this
> variation.
>
> Do you have any particular gain or loss in mind? I can't see how there
> could be any. I'd just drop this clause.
Didn't you ask me to add it? Someone did? Pierre?
> There was almost immediate recognition within the TWG of the fact that
> the use of short filenames has many disadvantages.
>
> The TWG recognizes that the use ...
Ok.
> same name (\filename{cmr10.pk} identifies Computer Modern Roman 10pt
> at 5--10 magnifications for 2--3 resolutions on many
> systems).
>
> same name. At a typical site, cmr10.pk will be the filename for Computer
> ... resolutions.
Check.
> Within the \TeX\ Directory Structure, every \filename{PK} file \emphasis{must} contain
>
> The TDS specifies that PK files must contain
>
> This may seem autocratic, and perhaps, strictly speaking,
>
> No perhaps about it. But I don't think it matters. We don't need to
> apologize for it; I think maybe this paragraph can be tossed.
(splash!)
> file derived from Karl Berry's \filename{modes.mf} distribution, the
>
> derived from (or is in fact)
>
> No other issue caused as much
> heated debate among the members of the committee as the issue of the
> font directory structure.
>
> The TWG struggled more with the font directory structure than anything else.
Ok.
> packages themselves, but it seemed to be important that users find
>
> source files for the packages, but ...
>
> is a nuisance. And since developers and distributors bemoan all the
> time that users don't read their documentation, it is important that
> no additional barriers are introduced. For these reasons, we decided
>
> Don't see the need for this sentence (And since ...).
(splash!)
> find the particular documentation they were after.
>
> In addition to this: we've already split up a package's file all over
> creation, so the doc files may as well follow along.
Are you really suggesting I add this?
> for each package, in a tree like the \filename{tex}
>
> ... tree paralleling ...
Check.
> Miscellaneous help
> and information files (like the \acronym{FAQ}) should be stored in
> the directory
> \filename{help} and general purpose documents
> should be stored in the directory \filename{general}.
>
> Two special categories: `help' for metainformation, such as FAQ's,
> David Jones' macro index, etc. `general' for standalone documents not
> part of any package: Michael Doob's A Gentle Introduction to TeX,
> Joachim Schrod's Components of TeX, texbook.tex and mfbook.tex, etc.
>
> (I think we should make the distinction a little clearer.)
Ok.
> to document (or automate) how the files should be moved from the
>
> (or, preferably, automate)
Check.
> For example, a package for Martian language typesetting might include
> the following files:
>
> ... might be distributed as the following:
>
> the working TDS structure which looks something like this:
>
> Delete `something'.
Check.
> \section{Example}
>
> Instead of `Example', I think we should make this `Summary', and provide
> not just a minimal set of directories, but (more or less) every
> directory in a small-but-real system.
>
> I think this would also help pull together everything from the preceding
> text.
>
> I'll work on this, unless you have some problem with it!
Go for it!
> texmf/fonts/knuth/cm/pk/canoncx
> texmf/fonts/knuth/cm/pk/canoncx/dpi300
>
> cx, not canoncx
Check.
> texmf/tex/plain/amstex
>
> Is there something in particular that goes in here?
> I can't even think what something like this would mean -- wouldn't all
> amstex files go in texmf/tex/amstex?
(splash!)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 08:43:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 09:38:44 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011438.JAA12174@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
References: <199502131620.AA29922@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
I can't find all my mail for the fonts/public fonts/knuth discussion.
But we did decide to go with fonts/public, right?
> Oh well. I don't care as much about fonts/knuth as I do pfa/pdb, because
What became of this? I can see Karl's point, and I think /type1 is a
good idea, but it's going to be the *only* directory that isn't done
by extension. Nothing to be done about it, I guess.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 09:01:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503011455.PAA16771@spice.iti.informatik.th-darmstadt.de>
Subject: Re: fonts/knuth?
To: TWG-TDS@SHSU.edu
Date: Wed, 1 Mar 1995 15:55:55 +0100 (MEZ)
Content-Type: text
You wrote:
>
> > Oh well. I don't care as much about fonts/knuth as I do pfa/pdb, because
>
> What became of this? I can see Karl's point, and I think /type1 is a
> good idea, but it's going to be the *only* directory that isn't done
> by extension. Nothing to be done about it, I guess.
I would prefer to go with /type1. There is also another directory that
does not feature an extension name: /src (keeps both MF, VPL, etc.
files).
I have some more (small) comments that I will try to send later this
evening. (I'm currently at the DANTE meeting and it's not quite my
`usual' work environment...) In general, I support all comments Karl
made in the last two weeks. :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 09:18:44 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
Date: Wed, 01 Mar 1995 15:17:46 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:055880:950301151823"@cl.cam.ac.uk>
does that list of splashes and splishes mean i should suck a new copy
of the thing? can you posta confirnation when theres a new version
up, Norm?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 09:23:46 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
Date: Wed, 01 Mar 1995 15:23:29 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:058520:950301152339"@cl.cam.ac.uk>
by the way, in my capacity as a programme person for the TUG95
conferencee this summer, and as a Technical Council member, i'd like
to arrange a TDS workshop at TUG95. in fact, i shall proopse that all
TWGs report back at TUG95. For TDS, obviously Norm is the ideal
person, so how about it, Norm? i am posting the invitation in public
so that if Norm cant make it, someone else can step forward and
vounteer to explain all this. if all else fails, i will, but i have
other duties. Maybe Karl could make a
once-in-a-lifetime-public-appearance! that would be a
crowd-puller. like the Kraken but less diastrous consequences
TUGboat needs material. what do you say to publishing TDS as it stands?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 09:52:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 10:47:59 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011547.KAA13174@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <"swan.cl.cam.:055880:950301151823"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 1 March 1995 at 15:17:46, Sebastian Rahtz wrote:
> does that list of splashes and splishes mean i should suck a new copy
> of the thing? can you posta confirnation when theres a new version
> up, Norm?
Not yet, I'm still hacking. I'll post a note when there's a new
version.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 09:55:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Mar 1995 10:51:02 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503011551.KAA13220@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <"swan.cl.cam.:058520:950301152339"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 1 March 1995 at 15:23:29, Sebastian Rahtz wrote:
> by the way, in my capacity as a programme person for the TUG95
> conferencee this summer, and as a Technical Council member, i'd like
> to arrange a TDS workshop at TUG95. in fact, i shall proopse that all
> TWGs report back at TUG95. For TDS, obviously Norm is the ideal
> person, so how about it, Norm? i am posting the invitation in public
I've been planning to go to TUG95 (although I haven't gotten approval
for the travel expenses yet) If I go, I'll let the crowd throw
tomatoes at me. ;-)
> so that if Norm cant make it, someone else can step forward and
> vounteer to explain all this. if all else fails, i will, but i have
> other duties. Maybe Karl could make a
> once-in-a-lifetime-public-appearance! that would be a
I'll step aside for Karl ;-)
> TUGboat needs material. what do you say to publishing TDS as it stands?
Ask me again after everyone's commented on the next draft. Maybe it'll
be ready for prime time.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Mar 1995 18:30:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 1 Mar 1995 16:30:29 -0800
Message-ID: <199503020030.QAA04809@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
On 13 February 1995 at 06:54:05, K. Berry wrote:
> problem is surmountable. In particular, note that \acronym{MS-DOS},
>
> ... In particular, on
> (I have an aversion to ever saying `Note that', since it's 100%
> redundant with itself, and you can say that again.)
I disagree. `Note that' conveys more emphasis.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Mar 1995 11:46:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Mar 1995 12:41:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503021741.MAA22112@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: TDS 0.62
Reply-To: TWG-TDS@SHSU.edu
New draft available
ftp://jasper.ora.com/private/twg-tds/tdsguide.{ps,dvi}
Plus all the other files too.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 14:55:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Mar 1995 15:50:45 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503032050.PAA17230@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Added paragraph...
Reply-To: TWG-TDS@SHSU.edu
I don't feel like generating a new draft before I get more comments,
but I've re-worded the "package" list item on page 7:
The English in the second paragraph was clumsy. I think it's less clumsy
now. And I added the third paragraph, per a private suggestion by Karl.
<varlistentry><term><replaceable>package</></>
<listitem>
<para>
is the name of the package.
<filename role=dir>ams</>, <filename role=dir>seminar</>, and
<filename role=dir>pstricks</> are examples of <replaceable>packages</>.
The special package name <literal>base</> is reserved for the base
distribution for each format.
</para>
<para>
The special package name <filename role=dir>misc</> is also reserved.
Packages that consist of <emphasis>only</> a single file shall be
installed in the <filename role=dir>misc</> package directory. It
seems pointless to nest such a package/file within a directory of
its own. It may also make subdirectory searching slower.
</para>
<para>
In the (presently unique?) case where a format consists of only a single
file and has no auxilliary packages, that file can simply be placed
in the <replaceable>format</> directory. In other words,
&TeX;info goes in <literal>texmf/texinfo/texinfo.tex</> and not
<literal>texmf/texinfo/base/texinfo.tex</>.
</listitem></varlistentry>
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:21:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040122.CAA12802@spock.iti.informatik.th-darmstadt.de>
Subject: Bitmap Fonts
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:22:26 +0100 (MEZ)
Content-Type: text
I was asked by several guys at the DANTE meeting if we could not
acknowledge the usage of font libraries as utilized by emTeX. Perhaps
we could mention that as yet another alternative to the canonical
storage form of <mode>/<dpi>/<files>.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:21:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040121.CAA12283@spock.iti.informatik.th-darmstadt.de>
Subject: Filename constraints
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:21:53 +0100 (MEZ)
Content-Type: text
In addition, filenames [...] must begin with a letter.
There was lots of discussion about the truth of this statement. Did
anybody conform it now? I remember someone mentioning that this
restriction holds only for directory names, not for filenames.
Rick? Didn't you report any experience?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:30:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040126.CAA18981@spock.iti.informatik.th-darmstadt.de>
Subject: 2nd editorial comment
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:26:09 +0100 (MEZ)
Content-Type: text
I forgot to mention that in 2.4 (Top Level Directories) in item
source/, the closing parenthesis at texmf/source/web2c/ was replaced
by a slash.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:32:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040123.CAA16151@spock.iti.informatik.th-darmstadt.de>
Subject: Subdirectory searching
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:23:37 +0100 (MEZ)
Content-Type: text
This feature is already supported by the \application{Web2C}
distributions of {\TeX} (available for Unix workstations and
ported to \acronym{MS-DOS}, \acronym{OS/2}, Windows-NT, Macintosh,
and other systems) and the \application{em{\TeX}} distribution for
\acronym{MS-DOS} and \acronym{OS/2}.
(I have already mentioned this issue in the past, but don't remember a
resolvement.)
Please add other known implementations that support it, too. E.g., I
know that Public\TeX{} does. IMO it's politically better, otherwise
other developpers might feel set back. Peter Breitenlohner did, for
instance.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:33:30 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040120.CAA19174@spock.iti.informatik.th-darmstadt.de>
Subject: DANTE meeting
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:20:20 +0100 (MEZ)
Content-Type: text
DANTE meeting
As I have mentioned, I have been on the DANTE meeting the last few
days. Again, TDS was an important discussion point. In particular, the
font tree layout was hashed over again, with the same arguments we
have shared on this list so often... :-(
Anyhow. As you might know, DANTE prepares quite a few distributions
for its members (that are usually also available by ftp, from CTAN): A
Unix distribution (web2c-based, of course), and one for DOS, OS/2,
Amiga, and Atari. With the exception of the Amiga guy, I was able to
talk with all other folks that create such distributions, and I
convinced everybody that the next to-be-released distribution will be
based on TDS.
These discussions were not `between-the-talks' issues, but there was
enough interest to make a one-hour plenary session, where many of the
120 people there contributed to the discussion. TDS seems to be a
topic that meets interest.
DANTE will also produce a CD that will utilize TDS structure. (Yet
another one, CD production seems to be a pet peeve of many people
nowadays. No comment. ;-)
I hope this will help to get TDS up and going. In the name of the TWG
I have expressed my thanks to DANTE for this `moral support', I hope
you don't think I did arrogate myself while presenting me as the
group's representative.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:39:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040122.CAA18953@spock.iti.informatik.th-darmstadt.de>
Subject: INITEX woes
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:22:44 +0100 (MEZ)
Content-Type: text
While I don't think that texmf/initex/ was really needed, throwing it
completely out was a bit of overreaction...
** Hyphenation patterns
hyphen/ should be listed as a possible instance of format/. I think a
paragraph after the introduction of generic/ would be fine, or after
the discussion of multiple directories that should be searched for
AmS-TeX. (More on that topic in the mail ``TeX macro files''.)
** Where go the INITEX files?
I have two problems:
1) Where do I store files like babel's language.dat?
I would prefer to put them somewhere else than in generic/babel/,
since it's not the original file that will get deleted when a new
babel release arrives.
A similar problem is for any other configuration files, like
LaTeX's *.cfg files.
How about <format>/config/?
2) It should be mentioned explicitely that INITEX-only input files
should be placed in <format>/base/. That's particular important
for LaTeX, where the installation instructions doesn't tell people
that these files (*.ltx) should be installed. (One needs them if
one wants to add another hyphenation pattern set, or if the
TeX implementation gets updated, etc.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:39:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040120.CAA12269@spock.iti.informatik.th-darmstadt.de>
Subject: Documentation subdirectories
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:20:57 +0100 (MEZ)
Content-Type: text
[2 comments]
** Paralleling TeX tree impracticable
If we really use doc/<format>/<package>/ and establish there a tree
``paralleling'' the tex/ tree, there will be lots of subdirectories
with only one file. Namely, many LaTeX packages come with one
documentation file and this will be the only member in that directory.
I would prefer to say all style documentation that consists only of
one file goes in a directory doc/latex/styles/, for instance.
** Do we prescribe the <package> subdir?
I don't understand that in full: I read
texmf/<doc>/<category>/<package>/
as general description. OTOH I read
Files below the <category> level are determined by the
documentation author.
I.e., we don't tell anything about <package>. But then it continues
Below the level of the \replaceable{package}, the \textsc{TDS}
does not make any demands on the arrangement of files.
I.e., we do say something about the <package> level again.
I would prefer if <package> in general is dropped, and some hints are
added for those <category>s we're in contact with the authors. In
particular, for LaTeX. (David? Alan?)
Joachim
PS: The questions to David and Alan are rhetoric currently. I know
that they are in Mainz, about 30km from here, without email
connection... :-) But I hope they will respond later.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:40:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040124.CAA12062@spock.iti.informatik.th-darmstadt.de>
Subject: TeX macro files
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:24:24 +0100 (MEZ)
Content-Type: text
[4 comments]
** generic/ example files.
Drop btxmac.tex; it's not generic. (May not be used with LaTeX.)
[[ Karl, do you see eplain as an own format? Or do you think it's a
plain package? ]]
** <package>/ level may be superfluous
Add another paragraph to the <package> item that this level may be
dropped if there are two few files for this format at all. Currently
this holds at least for amstex/ (7 files), texinfo (1 file), and mft
(1 file). [[Or are the latter plain macros, and not a format?! ]] And
for some local macro formats folks don't distribute. (E.g., I have
such macros that are from pre-LaTeX days. I still do my letters with
them... ;-)
** Recommendation for TeX implementors
Please add somewhere a paragraph that, as a consequence of the macro
structure, the TDS recommends to TeX implementers to allow the
specification of different TEXINPUTS search path values for different
formats. Actually, both Web2C TeX and Public\TeX{} support this
already. In general, the X resource stuff provides a good model to
look at in this context.
** Place for config files
Once again, I would like to get a <package>-level directory for
user-changed configuration files. (babel's language.dat, LaTeX's
*.cfg, etc.) My recommendation is <format>/config/.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 21:41:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040121.CAA16372@spock.iti.informatik.th-darmstadt.de>
Subject: Editorial comments
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:21:22 +0100 (MEZ)
Content-Type: text
Below are my editorial comments to 0.62:
** Logos
Please use the METAFONT logo. (There's a 2e package for that, btw.)
And use the AmS-TeX logo.
** 1 Introduction
The purpose of this document is to describe a standard directory
structure for macros, fonts, and other such implementation-independent
{\TeX} files (as a matter of practicality, this document also suggests
>> . (As
ways to incorporate the rest of the {\TeX} files into a single
structure).
I still think this should be two sentences.
** 2.4 Top Level Directories
Directory names are badly broken. How about utilizing path.sty, it
should be easy to add to tdsguide.sty.
In the TEXINPUTS example, I would have ordered the two directories the
other way round: Local stuff (.../oratexmf/...) before the general
installation (.../texmf/...).
** 4 Fonts
Both in the <source> and in the <typeface> item, the sentence
For more information about font filenames, consult \emphasis{Filenames
for {\TeX} fonts}: CTAN:/\filename{/info/fontname}.
Ad 1: The slash is doubled.
Ad 2: One should not feature the slash at all. This is relative to the
root of this logical AFA, but not to the root of the physical AFA.
** 4.1 Font Bitmaps
For example, the same 300dpi bitmap would be named \filename{cmr10.pk}
in the directory \filename{300dpi}.
According to the TDS that's illegal. :-) dpi300, you mean.
Analagously for \command{gsftopk}.
Analogously
** 4.1.1 Valid Font Bitmaps
At a typical site, \filename{cmr10.pk} will be the filename for
Computer Modern Roman 10pt at 5--10 magnifications for 2--3
resolutions.
Change `resolutions' to `modes'. Different resolutions are already
covered by the `magnifications' clause.
If you have been using a local modes file derived from (or is in fact)
Karl Berry's \filename{modes.mf} distribution, the required
information is \emphasis{already} in all of your \filename{PK} files.
I can't parse the ``derived from (or is in fact)'' part of this
sentence. Is the parenthesis really correct English?
** 6 BibTeX
[ NORM: THE {\protect\BibTeX} LOGO IS BOMBING TEX IN A SECTION TITLE! ]
Yeah, you have to use \protect there as well! Or add it to the
definition, in front of \smsize.
** 7 Documentation
Michael Doob's \emphasis{A Gentle Introduction to TeX}, Joachim
Schrod's \emphasis{Components of TeX}, \filename{texbook.tex} and
\filename{mfbook.tex}, etc.
Please use logos for TeX. (You want to make me update my article, do
you?)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 22:00:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Mar 95 20:00:06 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503040400.AA00707@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
JS> Rick? Didn't you report any experience?
I sent a bunch of stuff directly to Norm, most of which was concerned with
typos, etc. The part about file names read as follows:
3. monocase, 8.3 filenames with ...
upper-case, 8.3 filenames (e.g., "FILENAME.EXT") with ...
Many Unix systems (e.g., SunOS) map filenames to lower case,
but they must be upper-case on the disc itself.
4. ISO-9660 does NOT require that filenames begin with letters.
Call 800-433-DISC and ask DMI to send you copies of their
technical papers, especially "Introduction to ISO 9660".
Here is a bit more detail...
ISO-9660 file and names are made up of the character set [A-Z0-9_],
with "." used to separate the name from the extension. There must be
either a name or an extension. There is also a version number, which
may range from 1-32767, and is separated by a semi-colon. Thus, the
following are all valid file names, as far as I know:
1.2;1 _._;1 A.B;1 FILENAME.EXT;32000
1.;1 _.;1 A.;1 FILENAME.;32000
.2;1 ._;1 .B;1 .EXT;32000
Directory names have neither extensions nor version numbers. These are
all valid directory names, IMHO:
1 _ A DIRECTOR
My other substantive comments were:
7. I think you may cause confusion by using the word "source"
for the font supplier. How about "supplier", "vendor", or
"foundry"? I also think that you should use either "source"
or "src" consistently (for font and program source code).
and, approximately:
I would like to suggest a figure of the following sort:
<texmf>/ top-level directory for TDS tree
. bibtex/ BibTeX input files
. . bib/ databases of common interest
. . bst/ style files
. bin/*/ binaries, by system type
. doc/ user documentation
. . <format>/ name of a format file (e.g., plain)
. . . base/ base distribution for format
. . . misc/ single-file packages
. . . <package>/ name of a package (e.g., ams)
. . general/ standalone documents
. . help/ meta-information (FAQs, etc.)
. . <program>/ TeX applications, by name
. fonts/ font-related files
. . <type>/ file type (e.g., pk)
. . . <supplier>/ name of font supplier
. . . . <typeface>/ name of type face
. . . . . <mode>/ printer type (type pk only)
. . . . . . <dpi>/ font resolution (type pk only)
. info/ TeXinfo documents
. man/ Unix-style manual pages
. mf/ METAFONT (non-font) input files
. <program>/ TeX applications, by name
. source/ program source code
. tex/ TeX input files
. . <format>/ name of a format file (e.g., plain)
. . . base/ base distribution for format
. . . misc/ single-file packages
. . . <package>/ name of a package (e.g., ams)
1 2 3 4 5 6 7
I think there should be some explicit discussion of how packages
*should* be set up for down-loading into the TDS. My personal idea
is that we should standardize on Info-Zip, and ask that the packages
be zipped up from a sparse tree, so that they will "drop in" to the
right locations on the target machine. We also need some basic
distributions (e.g., web2c, emTeX) in TDS-compliant form.
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 22:03:11 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040123.CAA16144@spock.iti.informatik.th-darmstadt.de>
Subject: latex is a font source?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:23:07 +0100 (MEZ)
Content-Type: text
\item[\replaceable{source}]
is the name of the font vendor or \filename{public}. The
\filename{public} serves a practical purpose; it designates forts for
which there are no licensing problems if/when they are redistributed.
\filename{adobe}, \filename{ams}, \filename{latex},
\filename{monotype}, and \filename{public} are examples of
\replaceable{source}. For more information about font filenames,
consult \emphasis{Filenames for {\TeX} fonts}:
CTAN:/\filename{/info/fontname}.
Hmm, I'm irritated. I always thought latex/ is an example of
typeface/, not of source/. What are the <typeface>/ dirs below?
Currently I have
puma:fonts $ ll public/latex/src/
total 101
-rw-rw-r-- 1 tex software 9689 Jun 6 1994 circle.mf
-rw-rw-r-- 1 tex software 5485 Jun 6 1994 icmcsc10.mf
-rw-rw-r-- 1 tex software 4159 Jun 6 1994 icmex10.mf
-rw-rw-r-- 1 tex software 3792 Jun 6 1994 icmmi8.mf
-rw-rw-r-- 1 tex software 4720 Jun 6 1994 icmsy8.mf
-rw-rw-r-- 1 tex software 3781 Jun 6 1994 icmtt8.mf
-rw-rw-r-- 1 tex software 310 Jun 6 1994 ilasy8.mf
-rw-rw-r-- 1 tex software 3876 Jun 6 1994 ilcmss8.mf
-rw-rw-r-- 1 tex software 3883 Jun 6 1994 ilcmssb8.mf
-rw-rw-r-- 1 tex software 3902 Jun 6 1994 ilcmssi8.mf
-rw-rw-r-- 1 tex software 14306 Jun 6 1994 lasy.mf
-rw-rw-r-- 1 tex software 129 Jun 6 1994 lasy10.mf
-rw-rw-r-- 1 tex software 127 Jun 6 1994 lasy5.mf
-rw-rw-r-- 1 tex software 127 Jun 6 1994 lasy6.mf
-rw-rw-r-- 1 tex software 127 Jun 6 1994 lasy7.mf
-rw-rw-r-- 1 tex software 127 Jun 6 1994 lasy8.mf
-rw-rw-r-- 1 tex software 127 Jun 6 1994 lasy9.mf
-rw-rw-r-- 1 tex software 131 Jun 6 1994 lasyb10.mf
-rw-rw-r-- 1 tex software 392 Jun 6 1994 lcircle10.mf
-rw-rw-r-- 1 tex software 392 Jun 6 1994 lcirclew10.mf
-rw-rw-r-- 1 tex software 3777 Jun 6 1994 lcmss8.mf
-rw-rw-r-- 1 tex software 3785 Jun 6 1994 lcmssb8.mf
-rw-rw-r-- 1 tex software 3803 Jun 6 1994 lcmssi8.mf
-rw-rw-r-- 1 tex software 8990 Jun 6 1994 line.mf
-rw-rw-r-- 1 tex software 564 Jun 6 1994 line10.mf
-rw-rw-r-- 1 tex software 565 Jun 6 1994 linew10.mf
-rw-rw-r-- 1 tex software 3184 Jun 6 1994 sroman.mf
-rw-rw-r-- 1 tex software 2229 Jun 6 1994 sromanu.mf
What's the new structure?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Mar 1995 22:06:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503040120.CAA13022@spock.iti.informatik.th-darmstadt.de>
Subject: Combine and move ``Is there a better way''
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sat, 4 Mar 1995 02:20:00 +0100 (MEZ)
Content-Type: text
[KARL RECOMMENDS MOVING THIS. WE NEED AN ``IS THERE A BETTER'' WAY
SECTION FOR THE WHOLE THING, PERHAPS?]
As so often, I agree with him. The arguments in these sections (macros
& fonts) are almost the same anyhow.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 12:36:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 11:00:20 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041600.AA29483@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: INITEX woes
How about <format>/config/?
Sounds fine to me.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 12:41:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 10:43:57 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041543.AA29174@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: latex is a font source?
I always thought latex/ is an example of
typeface/, not of source/.
Yes, it should be a typeface. I think I'm the one who mistakenly
suggested latex as a source. I was confused.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:01:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 11:02:01 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041602.AA29507@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Bitmap Fonts
I was asked by several guys at the DANTE meeting if we could not
acknowledge the usage of font libraries as utilized by emTeX. Perhaps
we could mention that as yet another alternative to the canonical
storage form of <mode>/<dpi>/<files>.
``Acknowledge'' in the sense of being current practice, sure, no harm there.
``Acknowledge'' in the sense of an officially-accepted-alternative to
the present scheme, I hope not. Unless font libraries actually provide
more/better functionality than the usual tree.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:10:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 10:59:33 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041559.AA29455@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: TeX macro files
** generic/ example files.
Drop btxmac.tex; it's not generic. (May not be used with LaTeX.)
My belief is that generic/ is for files that can be used with two or
more formats. LaTeX need not be one of them.
Otherwise, where does btxmac.tex go? plain is not the right place, since
it works with amstex.
[[ Karl, do you see eplain as an own format? Or do you think it's a
plain package? ]]
It's like Texinfo. Can be (and is) used both ways. And, come to think
of it, it's a single file, so the `present unique?' parenthetical in the
current draft should be dropped, Norm.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:12:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 13:29:40 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051829.NAA12035@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 2nd editorial comment
References: <199503040126.CAA18981@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:26:09, Joachim Schrod wrote:
> I forgot to mention that in 2.4 (Top Level Directories) in item
> source/, the closing parenthesis at texmf/source/web2c/ was replaced
> by a slash.
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:30:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 10:53:26 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041553.AA29310@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Editorial comments
If you have been using a local modes file derived from (or is in fact)
Karl Berry's \filename{modes.mf} distribution,
I can't parse the ``derived from (or is in fact)'' part of this
sentence. Is the parenthesis really correct English?
Yes, but I guess it's unclear.
The idea is that the local modes file might be derived from modes.mf, or
it might actually *be* modes.mf, i.e., the site is using it unchanged.
(Lots of places do.)
How about:
If you have been using Karl Berry's \filename{modes.mf} (or a derivation
thereof) for your local modes file ...
Actually, I'm not sure my name should be there. If someone else took
over modes.mf maintenance the sentence wouldn't change.
So maybe just ... using \filename{modes.mf} ...
(We need an appendix or footnote giving ftp sites/ctan locations.)
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:46:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 13:29:05 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051829.NAA12022@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Bitmap Fonts
References: <199503040122.CAA12802@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:22:26, Joachim Schrod wrote:
> I was asked by several guys at the DANTE meeting if we could not
> acknowledge the usage of font libraries as utilized by emTeX. Perhaps
> we could mention that as yet another alternative to the canonical
> storage form of <mode>/<dpi>/<files>.
I amended "Extensions to this recommendation, such as cmr10.300pk,
may..." to read "Extensions to this recommendation, such as
cmr10.300pk or the use of font library files, may..."
Is that sufficient?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:47:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:21:37 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051921.OAA12465@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: Re: Combine and move ``Is there a better way''
References: <199503040120.CAA13022@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:20:00, Joachim Schrod wrote:
> [KARL RECOMMENDS MOVING THIS. WE NEED AN ``IS THERE A BETTER'' WAY
> SECTION FOR THE WHOLE THING, PERHAPS?]
>
> As so often, I agree with him. The arguments in these sections (macros
> & fonts) are almost the same anyhow.
Ok, I'm going to combine them (badly, no doubt) and move them. Unfortunately,
it seems impossible to move them to the "intro" or "basics" section since
they (must) refer to things that won't have been seen by then.
I'll drop them into a chapter of their own right before the summary
(section 9).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:47:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:21:37 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051921.OAA12465@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: Re: Combine and move ``Is there a better way''
References: <199503040120.CAA13022@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:20:00, Joachim Schrod wrote:
> [KARL RECOMMENDS MOVING THIS. WE NEED AN ``IS THERE A BETTER'' WAY
> SECTION FOR THE WHOLE THING, PERHAPS?]
>
> As so often, I agree with him. The arguments in these sections (macros
> & fonts) are almost the same anyhow.
Ok, I'm going to combine them (badly, no doubt) and move them. Unfortunately,
it seems impossible to move them to the "intro" or "basics" section since
they (must) refer to things that won't have been seen by then.
I'll drop them into a chapter of their own right before the summary
(section 9).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 13:56:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 4 Mar 1995 10:49:44 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503041549.AA29207@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
7. I think you may cause confusion by using the word "source"
for the font supplier. How about "supplier", "vendor", or
"foundry"?
I used to use `foundry' in the fontname doc, but people objected, since
`public' and `ams' aren't foundries.
I'm opposed to `vendor' because that implies a monetary transaction to
me :-).
`supplier' seems ok. I personally don't mind `foundry', either.
I agree two different uses of `source' is a bad idea.
I also think that you should use either "source"
or "src" consistently (for font and program source code).
Good point. Do people working on OS's other than Unix typically use
`src' at all? Do they use `source'?
Certainly we don't want to be Unix-centric, but we also don't want to
throw away established conventions for no reason.
I would like to suggest a figure of the following sort:
Yes. I think the way we should generate this is by taking an actual
working (minimal) TDS system and showing all the relevant pieces. I
think a complete example will be well worth the space. Joachim, can your
tree be made suitable for that purpose?
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:00:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:59:11 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051959.OAA12721@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: DANTE meeting
References: <199503040120.CAA19174@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:20:20, Joachim Schrod wrote:
>
> I hope this will help to get TDS up and going. In the name of the TWG
> I have expressed my thanks to DANTE for this `moral support', I hope
> you don't think I did arrogate myself while presenting me as the
> group's representative.
Not at all. Glad you were there!
This brings up a point:
1) Sebastian has asked me to present the TDS at TUG'95.
2) Rich thinks a panel discussion (or some other, larger event)
makes more sense
3) Joachim says there were 120 people willing to talk about it
for an hour (!)
How many of us are going to be at TUG'95? Should we plan to do something
larger (or, more officially, should we propose something larger to the
TUG Program Committee?)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:02:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:24:33 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051924.OAA12489@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: latex is a font source?
References: <199503040123.CAA16144@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:23:07, Joachim Schrod wrote:
> \item[\replaceable{source}]
>
> is the name of the font vendor or \filename{public}. The
> \filename{public} serves a practical purpose; it designates forts for
> which there are no licensing problems if/when they are redistributed.
> \filename{adobe}, \filename{ams}, \filename{latex},
> \filename{monotype}, and \filename{public} are examples of
> \replaceable{source}. For more information about font filenames,
> consult \emphasis{Filenames for {\TeX} fonts}:
> CTAN:/\filename{/info/fontname}.
>
> Hmm, I'm irritated. I always thought latex/ is an example of
> typeface/, not of source/. What are the <typeface>/ dirs below?
> Currently I have
Hmm, I think Joachim's right here. My mistake probably...I'll move
latex back to a typeface:
texmf/fonts/source/public/latex/...
texmf/fonts/source/public/cm/...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:02:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 04 Mar 1995 10:51:33 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
To: TWG-TDS@SHSU.edu
Message-ID: <794332293.637206.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i still haven't gotten a chance to read the draft carefully, but
would like to point out one bit that seems to be going in the
wrong direction ...
in rich morin's proposed structure figure, there are two
instances of "ams" being given as an example of a package name:
[...]
. doc/ user documentation
. . <format>/ name of a format file (e.g., plain)
. . . base/ base distribution for format
. . . misc/ single-file packages
. . . <package>/ name of a package (e.g., ams)
[...]
. tex/ TeX input files
. . <format>/ name of a format file (e.g., plain)
. . . base/ base distribution for format
. . . misc/ single-file packages
. . . <package>/ name of a package (e.g., ams)
i've said this before, but i guess not strongly enough ...
there is no "ams" package. ams has three items for distribution
that we refer to as packages: ams-tex, ams-latex, and amsfonts.
granted that ams-latex is now accepted (by the latex3 group) as
included in the main latex2e collection; that doesn't mean that
ams-tex can be referred to unambiguously simply as "ams".
please fix this in whatever way is most appropriate. <smile>
thanks. -- bb
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:03:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 13:42:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051842.NAA12153@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Subdirectory searching
References: <199503040123.CAA16151@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:23:37, Joachim Schrod wrote:
>
> This feature is already supported by the \application{Web2C}
> distributions of {\TeX} (available for Unix workstations and
> ported to \acronym{MS-DOS}, \acronym{OS/2}, Windows-NT, Macintosh,
> and other systems) and the \application{em{\TeX}} distribution for
> \acronym{MS-DOS} and \acronym{OS/2}.
>
> (I have already mentioned this issue in the past, but don't remember a
> resolvement.)
>
> Please add other known implementations that support it, too. E.g., I
> know that Public\TeX{} does. IMO it's politically better, otherwise
> other developpers might feel set back. Peter Breitenlohner did, for
> instance.
>
I've added PublicTeX (anyone know what platform(s) it runs on?) and
I'll add any others that we can think of.
<para>
This feature is already supported by several implementations of
&TeX; including, but not limited to, em&TeX;, Public&TeX;,
and <application>Web2C</>.
</para>
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:19:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 13:33:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051833.NAA12069@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
References: <9503040400.AA00707@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 3 March 1995 at 20:00:06, Rich Morin wrote:
>
> JS> Rick? Didn't you report any experience?
>
> I sent a bunch of stuff directly to Norm, most of which was concerned with
> typos, etc. The part about file names read as follows:
Rich, I can't find your mail. We had some file system problems
here, and I think it may have been a casualty. Could you send it
again? Sorry...
> ISO-9660 file and names are made up of the character set [A-Z0-9_],
> with "." used to separate the name from the extension. There must be
> either a name or an extension. There is also a version number, which
> may range from 1-32767, and is separated by a semi-colon. Thus, the
> following are all valid file names, as far as I know:
>
> 1.2;1 _._;1 A.B;1 FILENAME.EXT;32000
> 1.;1 _.;1 A.;1 FILENAME.;32000
> .2;1 ._;1 .B;1 .EXT;32000
>
> Directory names have neither extensions nor version numbers. These are
> all valid directory names, IMHO:
>
> 1 _ A DIRECTOR
I'll reword the TDS document accordingly.
> My other substantive comments were:
>
> 7. I think you may cause confusion by using the word "source"
> for the font supplier. How about "supplier", "vendor", or
> "foundry"? I also think that you should use either "source"
> or "src" consistently (for font and program source code).
Good points. I'll switch to "vendor" and check for src vs. source.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:20:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:28:01 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051928.OAA12495@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: INITEX woes
References: <199503040122.CAA18953@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:22:44, Joachim Schrod wrote:
> While I don't think that texmf/initex/ was really needed, throwing it
> completely out was a bit of overreaction...
>
>
> ** Hyphenation patterns
>
> hyphen/ should be listed as a possible instance of format/. I think a
> paragraph after the introduction of generic/ would be fine, or after
> the discussion of multiple directories that should be searched for
> AmS-TeX. (More on that topic in the mail ``TeX macro files''.)
Ok, I'll add "hyphen" as a reserved format name.
> I have two problems:
>
> 1) Where do I store files like babel's language.dat?
> I would prefer to put them somewhere else than in generic/babel/,
> since it's not the original file that will get deleted when a new
> babel release arrives.
>
> A similar problem is for any other configuration files, like
> LaTeX's *.cfg files.
>
> How about <format>/config/?
Sounds good to me. Anyone object?
> 2) It should be mentioned explicitely that INITEX-only input files
> should be placed in <format>/base/. That's particular important
> for LaTeX, where the installation instructions doesn't tell people
> that these files (*.ltx) should be installed. (One needs them if
> one wants to add another hyphenation pattern set, or if the
> TeX implementation gets updated, etc.)
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:24:01 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
Date: Sun, 05 Mar 1995 18:13:39 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:178250:950305181345"@cl.cam.ac.uk>
comments on TDS 0.62
====================
I haven't read TDS for a while, so I tried to look at it from a
practical point of view, not even considering disagreeing with the
principles. so most of my comments are (pretending to be naive)
implementation questions.
1. p3. as Joachim said, mention all implementations which do subdir
searching. add Y&Y's TeX, and remind the reader that it applies to dvi
drivers as well as TeX itself. so mention dvips and xdvi as programs
that implement it (natively as well as in *k versions)
2. p4. i think it is worth putting in a para saying
"Even if your TeX implementation does not support subdirectory
searching, you may still find it useful to adopt the structure if you
do not use many fonts or packages. For instance, if you only use
Computer Modern and AMS fonts, it it still possible to set them in the
TDS structure, and list the directories individually in configuration
files or enviornment variables"
so as not to depress people. i did this, for instance, at home before.
i got everything working as i wanted
3. p5. in naive mode, i wonder why BibTeX and MakeIndex are treated
separately; they both come in any standard kit, and have standard
support files.
4. p7. ams and pstricks are bad examples; there is no package called
ams! and pstricks is generic. "babel" and "fancyheadings" might be
better.
5. (general).
a) the martian example uses the texmf/initex/hyphen directory to put
hyphenation patterns; this isnt discussed elsewhere, and is this still
what we recommend? i suggest an explicit section about hyphenation
patterns.
b) is it also quite clear that .dtx files should go in doc? or should
they?
c) i agree that "better way" should occur once, in an appendix
d) (politics) may be sensible to note that this group only existed by
email, just in case people think we have been meeting in person at
vast cost. would it also be sensible to give affiliations of members?
As I argued ages ago, the best thing to do with this draft is get it
out in the hands of the critics!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:39:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 14:55:57 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503051955.OAA12713@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX macro files
References: <199503040124.CAA12062@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:24:24, Joachim Schrod wrote:
> [4 comments]
>
> ** generic/ example files.
>
> Drop btxmac.tex; it's not generic. (May not be used with LaTeX.)
> [[ Karl, do you see eplain as an own format? Or do you think it's a
> plain package? ]]
That's covered in the format section:
<para>
Although some of these formats can also
be used as macro packages; in this case we store them as formats.
By adjusting the <systemitem class=environvar>TEXINPUTS</> search
path, it is still possible to use them as macro packages under
another format (whereas placing them in the tree of another format
would completely obscure their possible use as a format).
</para>
eplain is a format.
> ** <package>/ level may be superfluous
>
> Add another paragraph to the <package> item that this level may be
> dropped if there are two few files for this format at all. Currently
> this holds at least for amstex/ (7 files), texinfo (1 file), and mft
> (1 file). [[Or are the latter plain macros, and not a format?! ]] And
> for some local macro formats folks don't distribute. (E.g., I have
> such macros that are from pre-LaTeX days. I still do my letters with
> them... ;-)
There's a paragraph in 0.62 to this effect about texinfo that would
apply to mft, but I am unwilling to say the same thing about amstex.
If there's only *one* file, you can skip the package; but if there
are seven, I think you need the package level. Let's not encourage
people to blur the boundries.
What's wrong with
texmf/tex/amstex/base
for the amstex files? Or is it really
texmf/tex/plain/amstex
(I forget if there is an amstex format file?)
> ** Recommendation for TeX implementors
>
> Please add somewhere a paragraph that, as a consequence of the macro
> structure, the TDS recommends to TeX implementers to allow the
> specification of different TEXINPUTS search path values for different
> formats. Actually, both Web2C TeX and Public\TeX{} support this
> already. In general, the X resource stuff provides a good model to
> look at in this context.
How does Web2C do this? It's a good idea, but I don't know how to
suggest it...I didn't know any implementations did it...
> ** Place for config files
>
> Once again, I would like to get a <package>-level directory for
> user-changed configuration files. (babel's language.dat, LaTeX's
> *.cfg, etc.) My recommendation is <format>/config/.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 14:41:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 5 Mar 1995 15:33:10 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503052033.PAA13153@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <199503040121.CAA16372@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:21:22, Joachim Schrod wrote:
> Below are my editorial comments to 0.62:
> ** Logos
>
> Please use the METAFONT logo. (There's a 2e package for that, btw.)
Is there someplace I don't?
> And use the AmS-TeX logo.
Check.
> ** 1 Introduction
>
> The purpose of this document is to describe a standard directory
> structure for macros, fonts, and other such implementation-independent
> {\TeX} files (as a matter of practicality, this document also suggests
> >> . (As
> ways to incorporate the rest of the {\TeX} files into a single
> structure).
>
> I still think this should be two sentences.
Check.
> ** 2.4 Top Level Directories
>
> Directory names are badly broken. How about utilizing path.sty, it
> should be easy to add to tdsguide.sty.
Fine.
> In the TEXINPUTS example, I would have ordered the two directories the
> other way round: Local stuff (.../oratexmf/...) before the general
> installation (.../texmf/...).
Duh! Thanks!
> ** 4 Fonts
>
> Both in the <source> and in the <typeface> item, the sentence
>
> For more information about font filenames, consult \emphasis{Filenames
> for {\TeX} fonts}: CTAN:/\filename{/info/fontname}.
>
> Ad 1: The slash is doubled.
> Ad 2: One should not feature the slash at all. This is relative to the
> root of this logical AFA, but not to the root of the physical AFA.
Check. Check.
> ** 4.1 Font Bitmaps
>
> For example, the same 300dpi bitmap would be named \filename{cmr10.pk}
> in the directory \filename{300dpi}.
>
> According to the TDS that's illegal. :-) dpi300, you mean.
Yep.
>
> Analagously for \command{gsftopk}.
>
> Analogously
Check.
> ** 4.1.1 Valid Font Bitmaps
>
> At a typical site, \filename{cmr10.pk} will be the filename for
> Computer Modern Roman 10pt at 5--10 magnifications for 2--3
> resolutions.
>
> Change `resolutions' to `modes'. Different resolutions are already
> covered by the `magnifications' clause.
Check.
> If you have been using a local modes file derived from (or is in fact)
> Karl Berry's \filename{modes.mf} distribution, the required
> information is \emphasis{already} in all of your \filename{PK} files.
>
> I can't parse the ``derived from (or is in fact)'' part of this
> sentence. Is the parenthesis really correct English?
Nah. But this is better:
... file derived from (or that is, in fact) Karl ...
> ** 6 BibTeX
>
> [ NORM: THE {\protect\BibTeX} LOGO IS BOMBING TEX IN A SECTION TITLE! ]
>
> Yeah, you have to use \protect there as well! Or add it to the
> definition, in front of \smsize.
Thanks! I knew there was a \protect missing somewhere!
> ** 7 Documentation
>
> Michael Doob's \emphasis{A Gentle Introduction to TeX}, Joachim
> Schrod's \emphasis{Components of TeX}, \filename{texbook.tex} and
> \filename{mfbook.tex}, etc.
>
> Please use logos for TeX. (You want to make me update my article, do
> you?)
No, but maybe Karl does...those were his suggestions ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 15:09:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Mar 1995 15:57:03 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503062057.PAA02314@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Bitmap Fonts
References: <199503041602.AA29507@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 11:02:01, K. Berry wrote:
> I was asked by several guys at the DANTE meeting if we could not
> acknowledge the usage of font libraries as utilized by emTeX. Perhaps
> we could mention that as yet another alternative to the canonical
> storage form of <mode>/<dpi>/<files>.
>
> ``Acknowledge'' in the sense of being current practice, sure, no harm there.
>
> ``Acknowledge'' in the sense of an officially-accepted-alternative to
> the present scheme, I hope not. Unless font libraries actually provide
> more/better functionality than the usual tree.
They provide a convenient way of circumventing filename length limitations
under (some) operating systems. In emTeX FLI files, for example, you can
have PK files with longer than 8.3 names.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 15:10:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Mar 1995 13:44:42 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503061844.AA21276@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: editorial comments
Another editorial msg, sent to the list for archiving purposes.
and Norman Walsh (Chair)}}
I feel like there should be a period at the end here. Also, I think we
should make a new section after `Conventions' called `References' or
some such, and put things like the group's email address, the mail
archives on shsu.edu, explain `CTAN', and collect all the references to
external documents that we mention elsewhere (e.g., fontname and modes.mf).
In the table of contents, `9 Summary' ended up on the second page. No
good! All the frontmatter should be on page 1, and page 2 should start
with the section heading `Introduction'.
The purpose of this document is to describe a standard directory
The primary purpose ...
files (as a matter of practicality, this document also suggests ways
to incorporate the rest of the {\TeX} files into a single structure).
Make the `as a matter' a separate sentence, instead of a
parenthetical. It deserves it.
much easier for system administrators and users to install and maintain
Delete `for system administrators and users', since mentioning those
groups is (1) too general, and (2) not general enough :-).
We hope that users and developers of both free and commercial implementations
`administrators', not `users'.
of {\TeX} will adopt this standard immediately. It has been designed to
Suggest dropping the `immediately', especially since it's going to be
circulated as a draft. Anyway, who are we to say what should be done
immediately in the texadmin's lives ...
it can be used
the TWG believes it is usable? we intend it to be usable? ...?
under Unix \acronym{MS-DOS}, \acronym{OS/2},
Macintoshes, and \acronym{VMS}.
on Unix, ... Macintosh, and ...VMS} systems.
(note missing comma after Unix, singular Macintosh)
complete runnable system to a simple macro or style file. It will also
`single' better than `simple' here.
The role of the TDS is to stabilize the organization of software
... of TeX-related software
part of this role, however they do not. The role of the CTAN archives
... however,
(always commas on either end of however in the middle of sentence.)
distribution on CTAN it's useful to combine many different types of
I think a comma after CTAN would be good here.
In this document, ``/'' is used to seperate filename components. This
separate (global replace, this occurs at least in one other place)
Also, perhaps say `components, as in texmf/fonts/...', just so people
can see what we're talking about.
is the Unix convention but it is arbitrary. The ideas are in no way
Just drop the `it is arbitary', and combine the next sentence into this one.
Filenames are represented in typewriter (constant width) type.
I don't like the word `represented' here. It should be `represented by',
anyway. How about `typeset in'?
Replaceable text, like \replaceable{package},
identifies a class of things.
Replaceable text is represented in typewriter
oblique.
To be parallel with the others, these sentences should be transposed.
Also, somewhere in this Conventions section, we should say that ``TeX''
in this document generally means ``the TeX system, including Metafont,
utilities, etc.'', not just the `tex' program itself. (Blah blah blah.)
This monolithic arrangement makes maintenance of {\TeX} software
`a TeX system' more accurate than `TeX software' here, I think.
Most implementations provide some ability to load files from different
directories by specifying a list of directories to search (in the
\systemitem{ENVIRONVAR}{TEXINPUTS} environment variable or a
system configuration file, for example), but this is so cumbersome
as to be unworkable at large sites.
All this text is out of place where it is. It belongs in the next
paragraph somewhere. In fact, here's a proposed revision of this whole
area, since I don't think we're making the reasoning clear in the
current text (a [w]diff should produce useful results, if you don't want
to take it wholesale, once you undent):
This monolithic arrangement makes maintenance of a {\TeX} system
a nightmare. It can also be the source of catastrophic error if two or
more macro packages happen to have input files with the same name.
Therefore, the TWG felt each package and typeface should be in a separate
directory. But then explicitly listing all directories to be searched would be
unbearable---there are dozens of packages and typefaces a site may
wish to install, which would lead to paths many thousands of characters
long, overflowing the available space on some systems.
Also, installing or removing a new package would also mean
changing a path as well as installing or removing the actual files, a
time-consuming and error-prone operation, even with
implementations that provide some ability to specify the
directories to search at runtime (in the
\systemitem{ENVIRONVAR}{TEXINPUTS} environment variable or a
system configuration file, for example).
On systems without some form of runtime configuration,
it would possibly even require recompiling software, an intolerable burden.
As a result, the TWG concluded that a comprehensive \textsc{TDS} required
that implementations of {\TeX} must support some form of implicit subdirectory
searching. In other words, it must be possible to specify that {\TeX},
{\protect\MF}, and their companion utilities search in both a specified
directory and recursively through all subdirectories of
that directory when looking for an input file. We encourage
implementors to provide subdirectory searching (at the option of the
installer and user) for all paths, though the TDS requires subdirectory
searching only for {\TeX} input files and fonts.
This TWG recognized that subdirectory searching places an extra burden
The TWG recognizes
(or `We recognize')
is imperative to a well organized \textsc{TDS}. Implementors are encouraged to
well-organized TDS, for the reasons stated above.
If a hit is found in the database, subdirectory searching is never required
`not' instead of `never'.
and the performance of the system is essentially independent of the number
Replace `essentially' with `this',
of levels of subdirectories present on the system.
`of levels' can be deleted.
As an consequence of the search strategy outlined above, two files in
a consequence (not `an')
define which one is found. To disambiguate this case, one must specify
a search path that lists the respective subtrees in the search order
... a search path must be specified ...
(usually I avoid passive voice with a passion, but it's too hard to say
precisely who does the specifying here)
} requires monocase, 8.3
Probably should explain ``8.3''. We know what we mean, but ...
materials. In this document we shall assume that this directory
`call' or `designate' would be better than `assume that', I think.
is called \filename{texmf}, although the exact name
`but' instead of `although'.
of the directory is up to the installer. On PC networks, this could
map to a logical drive specification, for example
\filename{T:}.
On PC networks, for example, this could ... specification such as T:.
Unix systems, this would traditionally be located in
... it would traditionally be
itself), it is likely to be unused, and it is
It's wrong to say `likely to be unused', since the default path for
web2c/kpathsea has been using $(prefix)/lib/texmf for a while now.
Either drop this clause, or say it's either unused or used in a
mostly-compatible way (informal predecessor to the TDS, etc., etc.).
under a system-dependent directory.
I think it's `implementation-dependent' here, not `system-dependent'.
For example, \filename{texmf} should not be created in the \filename{emtex} or \filename{pctex} directories.
Maybe clearer to be flat-out about it: For example, `emtex/texmf' is wrong.
All of these directories
may not be needed by all sites.
Not all of these directories are needed at all sites.
structure. For example, the binaries for a Sun workstation {\TeX}
... \TeX system
might be installed in \filename{/texmf/bin/sun-sunos4.1.3}.
`sparc' is more likely than `sun' here. Also, perhaps say `Or TeX
administrators may wish to put executables outside texmf/ altogether'.
(The TDS does not require execute be located in any particular place.)
for {\TeX}info documents
1) It's Texinfo (all regular roman), not {\TeX}info.
2) missing a period after documents.
3) It should be `processed Texinfo documents', anyway, since it's the
.info* files that go in info/, not the .texi sources.
In this case, sources includes
things like the source for Web2C (\filename{texmf/source/web2c/}
and the \filename{dtx} sources for {\LaTeX}
(\filename{texmf/source/latex/base}).
For example, texmf/source/web2c and the \filename{dtx} sources ...
example, Unix sites may wish to place all {\TeX} related files
TeX-related
``local'' files. Sites are encouraged to maintain a seperate tree for
separate
local styles and to use both trees in search paths. For example:
Doubling the size of every path. Sigh. I guess there's no alternative.
\begin{alltt}
TEXINPUTS=.:/usr/local/texmf/tex/latex//:/usr/local/oratexmf/tex/latex//
\end{alltt}
1) latex/ should not be in this path.
2) the `TEXINPUTS=' seems unnecessary.
\filename{texmf/tex/}\replaceable{format}\filename{/}\replaceable{package}\filename{/}\replaceable{files}
files => file
be used as macro packages; in this case we store them as formats.
...; the TDS nevertheless stores them as formats.
another format (whereas placing them in the tree of another format
would completely obscure their possible use as a format).
drop the parens and add a comma after `another format'.
By providing a format directory, subdirectory searching can be
\replaceable{format}
The special format directory \filename{generic} is
1) `special' seems unnecessary
2) \replaceable{format}
Thus, for almost every \replaceable{format}, it is correct to
almost?
For example, the \filename{amstex},
\filename{plain}, and \filename{generic}
directories should be searched when using {\AmS}{\TeX}.
Additional text: This does mean \emph{only} those directories must be
searched: texmf/tex// is a correct path for TeX inputs in a TDS tree.
is the name of the package.
`a' package, not `the'.
The special package name \literal{base} is reserved for the base
Again, `special' seems deletable.
Packages that consist of \emphasis{only} a single file shall be
installed in the \filename{misc} package directory.
It seems pointless to nest such a package/file within a directory
of its own.
It may also make
subdirectory searching slower. For this reason, the \filename{misc} directory is reserved.
For parallelism, this should start with something like:
The package name \filename{misc} is reserved for packages that consist
of a single file. It seems pointless ...
(and dump the `For this reason' sentence.)
arrangement after several long discussions about how best to arrange
after long discussion
The primary competition for this arrangement was a scheme which reversed
`alternative to' better than `competition for'?
[KARL RECOMMENDS MOVING THIS. WE NEED AN ``IS THERE A BETTER'' WAY
SECTION FOR THE WHOLE THING, PERHAPS?]
Nothing in this section has anything in particular to do with macros
(vs. fonts, for example). Does it? Let's make it a section of its own
before the Summary? Or in the Basics? Or somewhere. Not here.
Hmm.
make maintenance possible. The \textsc{TDS} specifies that fonts should be stored
`feasible' better than `possible', I think. Anything's *possible*.
purpose; it designates forts for which there are no licensing problems
fonts, not forts!
font filenames, consult \emphasis{Filenames for {\TeX} fonts}:
CTAN:/\filename{/info/fontname}.
1) Only need this ref once, either before or after the list, I think.
2) we have to explain the meaning of CTAN. I wonder if a URL
ftp::/\replaceable{CTAN}/... would be better.
3) The first slash comes out in the wrong font.
4) The path is wrong. Has to start with /tex-archive. Assuming you mean
`CTAN' is a host name.
are the individual files.
... files, e.g., cmr10.tfm, putr.pfa, ptmr.pfa. But PK files need
additional structure; see the next section.
There is no need to ever have GF bitmap font files in a working TeX
installation, since PK format bitmaps store the same information in less space.
type of device (mode) for which the font was created and the
(i.e., mode)
To identify the mode, fonts are typically segregated into different
..., common practice is to segregate fonts into ...
convention is usually to include the resolution in the filename. For
Can drop the `usually'.
And add `(in fact, this is how Metafont itself names its output)',
maybe?
\filename{cmr10.300pk}. On other systems, for example \acronym{MS-DOS},
`such as' instead of `for example' maybe. The `for example's are getting
a bit thick.
\filename{cmr10.pk} in the directory \filename{300dpi}.
dpi300, not 300dpi.
Since long filenames are not allowed by many file systems,
Since the TDS cannot assume long filenames
(see \xref{Section 4})
It's not section 4, it's 2.2. Where's your symbolic references?!
Therefore, under the \filename{pk} directory, two more
subdirectory levels are used:
... directory, the TDS specifies two more subdirectory levels:
$\ldots$\filename{/pk/}\replaceable{source}/\replaceable{typeface}/\replaceable{mode}\filename{/}\replaceable{dpi}\filename{/}\replaceable{files}
Some of the slashes are in the wrong font.
is the mode name which identifies the printer type. This
identifiers the device type.
Karl Berry maintains a complete set of {\protect\MF} modes; see:
CTAN:\filename{/fonts/modes}.
1) For a complete set of Metafont modes, see ...
(my name is irrelevant)
2) all the same comments about CTAN apply as before.
3) the path is tex-archive/fonts/modes/modes.mf.
Analagously for \command{gsftopk}.
Analogously
is the resolution of the font. The directory name should
specifies the resolution ...
It is necessary to place \filename{dpi} in front of the
resolution because some file systems require names to begin with a letter.
Not sure this is true any more?
So could say `Placing dpi in front of the resolution is common practice'.
Also, ``filesystem'' should be one word. Everywhere.
\filename{cmr10.300pk}) provided that the basic scheme is also
Comma after the ).
The \textsc{TDS} specifies that \filename{PK} files \emphasis{must} contain
In a TDS-conformant installation, all PK files *must* contain ...
(We can't say anything about all PK files everywhere in the world!)
Luckily, this information is very easy to supply: a simple addition to
Delete `Luckily'. Luck is not involved :-).
The `very' seems unnecessary.
provide the required information. If you have been using a local modes
Possibly the `If you ...' sentence should be after the colon, and then
something like `If not, a simple addition based on the code in modes.mf'
etc. etc.
file derived from (or is in fact) Karl Berry's \filename{modes.mf} distribution, the
Delete my name again.
required information is \emphasis{already} in all of your \filename{PK}
Delete `all of'.
optionally be employed on those systems which support this file name
Let's make `filename' one word.
The ``other'' arrangement that we considered was:
``other'' => alternative
unusable if the implementation did not have some method for ``short
if the implementation did not have => without
There are still some concerns about efficiency, but there seems to be
Some concerns about eff. remain, but ...
{\protect\BibTeX} databases and style files are frequently scattered in with other
frequently => commonly?
for them.
them:
documentation should be stored in a structure that parallels the fonts
parallels to some extent
source files for the packages, but it seemed to be important that users find
documentation in one place---for humans, searching directory trees
is a nuisance. For these reasons, we decided
..., but we felt it was important that users be able to find
documentation in one place, not mixed in with the source files; most
users have no interest in sources. For these reasons ...
(the stuff about `directory trees is a nuisance' doesn't make sense --
putting the docs in with the sources would actually *reduce* the # of dirs!)
\filename{texmf/doc/}\replaceable{category}\filename{/}\replaceable{package}/$\ldots$
Insert `The TDS specifies:' before this. (Separate paragraph.)
For \replaceable{format}s, this will be the name
For TeX ... (just to remind them)
and \filename{amstex}, etc.
Delete `and'.
Other categories include documentation for utilities
... include utility names, e.g., texmf/doc/bibtex, texmf/doc/makeindx, etc.
There are two special catagories:
... two reserved category names:
David Jones' macro index, etc. and \filename{general} for standalone
comma after etc.
\emphasis{A Gentle Introduction to TeX},
\emphasis{Components of TeX}, \filename{texbook.tex} and
\TeX, not TeX, needed for both these.
to document (or, preferably, automate) how the files should be moved from the
archive structure into the TDS structure.
New sentence: One possible method of automation is to make the
distribution TDS-conformant itself, so a simple recursive copy will
install the package.
(Or something like that.)
For example, a package for Martian language typesetting might be distrubited
distributed
the working TDS structure which looks like this:
the corresponding TDS structure:
texmf/fonts/martian/src/mart10.mf
texmf/fonts/martian/tfm/mart10.tfm
Hmm. I don't like these font filenames! Oh well.
Didn't quite make the weekend, but oh well again. Looking forward
to the next draft. Another couple rounds and we might have it.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 17:04:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 06 Mar 1995 17:59:22 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
To: TWG-TDS@SHSU.edu
Message-ID: <794530762.959428.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
rich morin:
7. I think you may cause confusion by using the word "source"
for the font supplier. How about "supplier", "vendor", or
"foundry"? I also think that you should use either "source"
or "src" consistently (for font and program source code).
norm walsh:
Good points. I'll switch to "vendor" and check for src vs. source.
i don't think the ams thinks of itself quite as a "vendor";
"supplier" would be better from our point of view. (i agree
that "source" is too overused and would be imprecise here.)
another reason for preferring the word "supplier" -- the work
on font services in the standards committees i participate in
is using the term "font supplier".
-- bb
p.s. i accidentally sent this previously while identified as my
alter ego "tech-support". i think it bounced. but if it didn't,
apologies for duplication.
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Mar 1995 18:40:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Mar 95 16:36:53 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503070036.AA12561@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Filename constraints
> > I would like to suggest a figure of the following sort:
>
> Yes. I think the way we should generate this is by taking an actual
> working (minimal) TDS system and showing all the relevant pieces.
I think an actual working (minimal) TDS system would be a good check on
such a figure, but I would not want to constrain the figure to match
any given minimal system. Instead, I think it should be a skeleton
showing the range of possibilities, in an annotated, abstract form.
2) Rich thinks a panel discussion (or some other, larger event)
makes more sense
Only because I think there are topics that extend beyond the definition
itself. I would imagine Norm could do a great job of presenting the
motivations, history, politics, and conclusions of the TWG on his own.
I would then fold in talks about conversion, distribution, installation,
maintenance, etc. That is, how does the TDS best get put into practice?
What's involved in making a usable TDS CD-ROM, a clean distribution, or
a large TDS-compliant installation? Should there be any form of package
QA and/or registration to ensure TDS compliance and perhaps a minimal
level of documentation? (The end result we want is drop-in packages, any
level of standardization short of that is only a partial solution!)
I have some thoughts on these issues, but I'm not sure everyone wants to
go down this path in the TDS. Norm, is there any chance of setting up a
second list (e.g., tdsi) to discuss such issues? What would be the best
way to do so?
> in rich morin's proposed structure figure, there are two
> instances of "ams" being given as an example of a package name:
I guess my figure has already shown its utility, by exposing a piece of
Norm's text to careful scrutiny (:-). Seriously, the purpose of the
figure is to boil down the information in the TDS into a single chart
that one can digest all at once. I think it works for that.
-r
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 05:16:29 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
Date: Tue, 07 Mar 1995 11:13:44 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:091710:950307111414"@cl.cam.ac.uk>
re TUG95 and public discussion, i suggest that i draft Rich Morin as
chairman for a reasonable-length session on "setting up and
maintaining a TeX system" at the conference. we can decide how to
actually fill this later, but obviously one important part will be
Norm's formal launch and defense of the TDS. for those of you who were
at TUG93, i imagine something like the session that formally brought
CTAN into the world.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:36:07 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071235.NAA17874@spock.iti.informatik.th-darmstadt.de>
Subject: Re: TeX macro files
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:35:51 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> ** generic/ example files.
>
> Drop btxmac.tex; it's not generic. (May not be used with LaTeX.)
>
> My belief is that generic/ is for files that can be used with two or
> more formats. LaTeX need not be one of them.
My belief is that generic/ is for files that work with all formats
that use plain category codes.
> Otherwise, where does btxmac.tex go? plain is not the right place, since
> it works with amstex.
IMO tex/plain/misc/ or tex/plain/bibtex/ is the right place.
Following your arguments, I would have to put virtually all plain
macro files in generic/. Typically they are usable with AmS-TeX, as
AmS-TeX is a actually a plain extension. I.e., a specific search path
for AmS-TeX should list the plain area as well. The counter example
is LaTeX which uses the category codes of plain, but where you
normally can't use plain macros.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:41:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071241.NAA11487@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:41:34 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> 3. p5. in naive mode, i wonder why BibTeX and MakeIndex are treated
> separately; they both come in any standard kit, and have standard
> support files.
Because BibTeX is presented more precisely later. (That's because it
has a substructure, but MakeIndex does not have one (yet).)
> 4. p7. ams and pstricks are bad examples; there is no package called
> ams! and pstricks is generic. "babel" and "fancyheadings" might be
> better.
babel is generic, too...
amslatex is a good LaTeX package example.
And `tools' if I think about it. That might make it clear that the
term _package_ in this context is something different than a LaTeX2e
_package_.
> b) is it also quite clear that .dtx files should go in doc? or should
> they?
I thought they go in source/latex/base/ ?
> As I argued ages ago, the best thing to do with this draft is get it
> out in the hands of the critics!
It is out (ftp.th-darmstadt.de:/pub/tex/TDS-compliant/draft/) and is
read already. I often send email or mention it in News if an
appropriate question comes up.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:43:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071242.NAA15082@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Bitmap Fonts
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:42:21 +0100 (MEZ)
Content-Type: text
Norman wrote:
>
> > [font libraries]
>
> I amended "Extensions to this recommendation, such as cmr10.300pk,
> may..." to read "Extensions to this recommendation, such as
> cmr10.300pk or the use of font library files, may..."
>
> Is that sufficient?
Yes.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:48:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071248.NAA17910@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Subdirectory searching
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:48:41 +0100 (MEZ)
Content-Type: text
Norman wrote:
>
> I've added PublicTeX (anyone know what platform(s) it runs on?)
It runs on DOS PCs, not only on 386-class machines, but also on 286
and even XTs. It was made by Klaus-Peter Thull (who published about
it in TUGboat) and is now maintained by Peter Breitenlohner.
It's the first DOS port where source has been made available. IMO the
missing source is the main drawback of emTeX; in particular since
Eberhard is a student and I don't think he can support emTeX any
further when he has finished his studies. The other DOS port with
source is gtex (web2c, actually).
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:52:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071251.NAA17668@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:51:06 +0100 (MEZ)
Content-Type: text
Norman wrote:
>
> > Please use the METAFONT logo. (There's a 2e package for that, btw.)
>
> Is there someplace I don't?
In my print, it's used nowhere. (But I did TeX the document anew as I
did work at home, and it's quicker to transfer just the TeX file
instead of the DVI file.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 06:54:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071254.NAA11278@spock.iti.informatik.th-darmstadt.de>
Subject: Off topic (was: editorial comments)
To: TWG-TDS@SHSU.edu
Date: Tue, 7 Mar 1995 13:54:15 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> distribution on CTAN it's useful to combine many different types of
>
> I think a comma after CTAN would be good here.
ARRRGGGGHHH!!!
The English language will always be a mystery to me. ``think ...
would be good here''... Don't you can set up some solid comma rules
that mere mortals like me can learn over time?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 07:00:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503071259.NAA13344@spock.iti.informatik.th-darmstadt.de>
Subject: GF fonts
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 7 Mar 1995 13:59:36 +0100 (MEZ)
Content-Type: text
Where are GF fonts placed? In fonts/gf/, or below fonts/pk/?
If it's the latter, a respective remark should be added.
If it's the former, we have to note it when we present the additional
<mode> level for bitmap fonts. (GF fonts are mode-specific, too.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 07:35:11 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Subdirectory searching
Date: Tue, 07 Mar 1995 13:34:43 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:176990:950307133459"@cl.cam.ac.uk>
> It's the first DOS port where source has been made available. IMO the
first? before web2c?
anyway, *please* also mention Y&Y's TeX package. It is good, and
Berthold deserves the recognition that he brings it up standards like
TDS as soon as he can
and i reiterate, add a sentence reminding peple that this is about
drivers as well as TeXex, and there are fewer confirmant ones of them
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 07:38:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 95 13:07:59 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503071307.AA06667@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: GF fonts
>>>>> Joachim Schrod writes:
Joachim> Where are GF fonts placed? In fonts/gf/, or below fonts/pk/?
Joachim> If it's the latter, a respective remark should be added.
Joachim> If it's the former, we have to note it when we present the additional
Joachim> <mode> level for bitmap fonts. (GF fonts are mode-specific, too.)
I suppose fonts/gf although for most sites /dev/null is a more
appropriate place. Are not these always converted to pk files then
deleted?
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 10:23:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 07 Mar 1995 17:21:27 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Fonts...
To: twg-tds@shsu.edu
Message-ID: <01HNV1V4K8N6002FBO@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Though I decided to abstain from this discussion, I think I have to add two
points.
Here's the first, containing an argument to have different directories for
pfa and pfb files. I think, any directory should contain either text files
or binaries, but not both of them intermixed. The reason is, that you need
different modes to transfer text files and binary files across different
operating systems. Line ends are different in text files, some OSes prefer
fixed record files to stream linefeed type binaries -- and the adjustment
needed for this reason will damage the other type of files.
--J"org Knappen.
(Second point will come in a separate post)
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 11:04:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 1995 17:04:31 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950307170431.22403472@vms.rhbnc.ac.uk>
Subject: RE: editorial comments
Following J"org's lead, and despite my own abstention being somewhat more
protracted and formal, I would like to make one very small contribution
to the group's grammar:
1.
>> Replaceable text, like \replaceable{package},
^^^^ `such as', not `like'.
>> identifies a class of things.
>> Replaceable text is represented in typewriter
>> oblique.
2.
>> In this case, sources include.
>> things like the source for Web2C (\filename{texmf/source/web2c/}
^^^^ -ditto-
>> and the \filename{dtx} sources for {\LaTeX}
>> (\filename{texmf/source/latex/base}).
3.
>> the working TDS structure which looks like this:
^^^^ perfect, stet.
The expression `such as' is needed when one cites an actual instance of a more
general class; in ex.~1, `replaceable text' is generic, whilst `\replaceable
{package}' is specific. `Such as' is therefore needed, since the thing being
cited (`\replaceable {package}') is an actual instance of the more general
concept `replaceable text'. If, however, two entities of the same level of
abstraction are being compared, then `like' is required, since neither can be
an actual instance of the other (as in, e.g., `LaTeX, like AMS-TeX, uses the
same catcode regime as Plain').
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 11:07:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 07 Mar 1995 18:04:05 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Fonts... /Knuth
To: twg-tds@shsu.edu
Message-ID: <01HNV2PD9YPE002EQU@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
This is a completely different approach to font in general.
Let me first sketch the layout:
fonts/base contains the 75 cm fonts described in C&T Vol. E
+ some utility fonts (logo, manfnt, other fonts needed
to print C&T, web documentation etc.)
fonts/packages/ams AMS fonts, including euler, ams symbols, wn cyrillic,
extra cm fonts
fonts/packages/latex lasy fonts, SliTeX fonts (visble and invisible),
lcircle and line fonts
fonts/packages/lamstex 6 special fonts for LAMSTeX diagrammes
...
fonts/contibuted/musictex [stands here just as an example for the many
contributed fonts available]
...
fonts/local/lw35 Locally available fonts (here the package consisting of
the 35 standard fonts for many laserprinters), which may
be commercially sold, etc.
Rationale:
The fonts in font/base are a true part of the TeX typesetting system, as
documented in the 5 volumes of D. E. Knuth, Computers and Typesetting. They
are only a subset of the fonts Knuth has designed (for example the punk
fonts), therefore this directory does not match fonts/knuth.
The major macro packages require additional fonts, this is reflected by
putting them into directories fonts/package.
There is a plethora of other fonts, many of them are contributed to the TeX
system as METAFONT sources, those are in fonts/contributed.
There are more fonts, which are available due to local circumstances
(in-house fonts, fonts bought from different vendors, built-in fonts of
local printers), all those are in fonts/local. I really don't care for
standardisation of this local area, because one cannot expect those areas
to match between different installations. Maybe it should be moved to the
parallel tree at all.
--J"org Knappen.
P.S. I have avoided all the thorny points, e.g. whether some special fonts
are a package or contributed (I'd prefer the dc fonts being a package,
becaue they are the base fonts for LaTeX's T1 encoding), or how the
detailed directory tree sould be organised (i.e. where to insert <type>).
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 14:05:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 95 09:59:48 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503071759.AA16084@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: proposed panel: "Bringing TDS Back Home"
> re TUG95 and public discussion, i suggest that i draft Rich Morin
> as chairman for a reasonable-length session on "setting up and
> maintaining a TeX system" at the conference.
\begin{sarcasm}
Gee thanks, Sebastian. Can I do something nice for you?
\end{sarcasm}
Actually, I have no problem with setting up such a session, save that I:
1. have no particular expertise in setting up TeX systems,
2. think the proposed topic is too general,
3. hadn't actually committed myself to going to TUG95 yet, and
4. don't know how long a "reasonable-length session" might be.
These are all resolvable, in theory, so let's start down the path and
see what happens. (BTW, on reflection, it might be useful for Norm to
structure *his* session as a panel on TDS design issues. He could grab
one or two of the folks who are stuck with implementing TDS features in
software to discuss the reasons why we "didn't do the obvious things"
that members of the audience will no doubt bring up.)
Assuming that Norm's session covers TDS design and implementation issues,
my session would be free to cover all sorts of (packaging, distribution,
conversion/installation, maintenance, etc.) issues that relate to
"Bringing TDS Back Home"
(my preferred title for the panel, at present). Here are some ideas:
1. TDS distribution -- roles of CTAN, CD-ROM, and other distribution
methods. Quality-control mechanisms: registration, documentation,
standardized distribution formats, reference installation sites.
2. TDS administration -- conversion/installation, removal, conflict
avoidance, gotchas, OS- and package-specific considerations
3. TDS packaging -- standard distribution format, conversion tools,
exception handling, etc.
4. TDS-compliant CD-ROMs -- fundamental limitations and capabilities,
design issues, review of current and upcoming products
Suggestions, comments, and volunteers are, of course, earnestly requested.
I think I can handle #1, or at least will be able to by the time TUG95 is
at our throats. I will definitely need a victim or two for #2, however.
Items #3 and #4 are things I could discuss, but I'm not comfortable with
hogging the stage and I'd probably run out of steam by then, as well. Also,
I'm not sure how interested folks would be in such specialized topics. I
suspect there may be some better topics out there -- suggestions?
Careful readers will no doubt see some references in the above text to
activities this TWG has never even contemplated. Rather than extend this
message to cover them, I will follow it with another one under a different
subject line.
Later, Rich
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Mar 1995 17:59:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 95 13:29:25 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503072129.AA16831@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: TDS Implementation
I have received some feedback indicating that I should go ahead with the
(conversion, distribution, installation, maintenance, etc.) topics I have
alluded to in previous notes. I guess the folks that don't find the
thread interesting can simply ignore it; if it gets too TeDiouS for the
majority of the group, we can split it off.
The Problem
===========
The TDS defines a directory structure, but it says nothing about how
TeX-related packages are going to get:
1. converted into the structure
2. packaged for archiving and distribution
3. loaded onto users' systems
4. documented, kept up to date, etc.
I contend that these aspects need to be covered if the TDS is to be a
real aid (let alone a solution) to the raft of administrative queries
we see on comp.text.tex, etc.
My Proposal
===========
1. TDS standard distribution format
If we don't have a standard format for distributing sets of
TDS-compliant files, everything else will get *much* harder.
I suggest that add-in packages be built as sparse, compliant
directory trees, then archived using Info-Zip.
Base distributions *could* use this technique, but would not
be required to do so. Commercial vendors, in particular, are
likely to have specialized needs that this method may not meet.
Any solution(s) should, however, allow add-in packages (in the
standard format) to be folded in later without undue hassle.
2. Documentation
The internal documentation of packages is not my concern here.
Instead, I am talking about creation of a standardized "packing
list" that can be relied upon to have certain key information:
Package Name, Version, Revision Date, Description, ...
Author/Maintainer Name, Address
Availability
TDS Usage
...
Most of the above is pretty standard stuff. We'll have to
agree on a standard presentation format, however, to allow
automated searching, printing, etc.
The Availability information would tell the reader how to get
a current copy. This could be an FTP site, a company name, or
whatever.
Each TDS Usage entry would be the name of a directory (or, in
some cases, only a file) that is claimed for this package in
the TDS. Most packages would have several such entries, one
for each name claimed. By requiring each package to list its
TDS Usage, we can detect (and reduce!) name space clashes.
3. Registration
By registering TDS-compliant packages, we can provide a known,
if minimal, level of quality assurance to the TDS-using public.
We can also reduce the frequency of TDS name space clashes.
To register a package, one would submit a TDS "packing list".
The TDS Registry would check for conflicts, missing information,
etc., then register the package. Updated information would be
handled in a similar manner. The registry data would be freely
redistributable and available online.
Note that the registry would handle both proprietary and freely
redistributable packages! The only difference between the two
would be the details of distribution, support, etc.
4. Package Conversion
Note: I am specifically *not* talking here about programming
changes that will be required to allow TeX-related programs to
deal with TDS-compliant installations! That's a hard and very
important problem, but it isn't really a distribution issue. My
focus here is limited to moving TeX-related files from old-style
(random) locations into TDS-compliant ones, then archiving them.
There are really two problems here. One is the conversion of
crufty but useful packages into TDS-compliant distributions. I
think this will require a lot of hand work by volunteers. My
approach would be to provide some useful tools and let folks do
conversions as needed. Registering a converted package would be
considered a Good Thing, as it would reduce the amount of wasted
effort. Lots of stuff in the CTAN would never get converted, but
most of the useful stuff would come along fairly quickly.
The second problem is the continuing conversion of current items.
The ideal way to do this is to convince the item's maintainer(s)
to do the conversion themselves. Failing this, we may find that
volunteers will appear to keep up TDS "ports" of useful packages.
In any case, most of the conversion should be automated, either
by the build code (make file, etc.) distributed with the package
or by a separate script that "knows" how to distribute the files
in a TDS-compliant manner. I think some basic tools for all this
will emerge very quickly as we begin the conversion efforts.
5. Base Distributions
Before a site can start installing add-in packages, it must set
up the basic TeX distribution in a TDS-compliant manner. To this
end, I suggest that we encourage the creation of "easy install"
and/or "plug and play" base distributions for the most popular
TeX variants and operating systems.
I think that's enuff for a start. Now, where did I put my hardhat and
flak jacket?
Later, Rich
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 03:25:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 1995 16:19:22 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503072119.QAA03814@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: proposed panel: "Bringing TDS Back Home"
References: <9503071759.AA16084@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 7 March 1995 at 09:59:48, Rich Morin wrote:
>
> > re TUG95 and public discussion, i suggest that i draft Rich Morin
> > as chairman for a reasonable-length session on "setting up and
> > maintaining a TeX system" at the conference.
>
> \begin{sarcasm}
> Gee thanks, Sebastian. Can I do something nice for you?
> \end{sarcasm}
Sebastian's got a real knack, wouldn't you say, Rich? ;-)
(I'll try to get through the rest of my mail tomorrow)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 05:27:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 06:28:02 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081128.AA20893@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX macro files
IMO tex/plain/misc/ or tex/plain/bibtex/ is the right place.
Following your arguments, I would have to put virtually all plain
macro files in generic/. Typically they are usable with AmS-TeX, as
OK, I'm convinced (about generic/). I like tex/plain/misc more than
tex/plain/bibtex, since it's a ``single file''.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 06:05:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081203.NAA22052@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Fonts...
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 13:03:30 +0100 (MEZ)
Content-Type: text
Joerg Knappen wrote:
>
> Here's the first, containing an argument to have different directories for
> pfa and pfb files. I think, any directory should contain either text files
> or binaries, but not both of them intermixed. The reason is, that you need
> different modes to transfer text files and binary files across different
> operating systems.
But the TDS structure is not there for transferring (i.e.,
distributing) software. It's there for installing and maintaining this
installation.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 06:08:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081207.NAA17455@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 13:07:51 +0100 (MEZ)
Content-Type: text
Joerg Knappen wrote:
>
> This is a completely different approach to font in general.
>
> Let me first sketch the layout:
>
> fonts/base contains the 75 cm fonts described in C&T Vol. E
> + some utility fonts (logo, manfnt, other fonts needed
> to print C&T, web documentation etc.)
>
> [etc.]
For my taste, this proposal is too METAFONT / CM centric.
In particular, your fonts/local/ is IMO the area that _must_ be
structured. One must not look at freely distributable MF fonts alone.
Joachim
PS: Besides, the proposal obviously tries to mirror the macro layout.
But there is no package/ level there.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 06:22:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081222.NAA19833@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Subdirectory searching
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 13:22:22 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > It's the first DOS port where source has been made available. IMO the
> first? before web2c?
We're talking about work done in 1987 & 1988, for 8086 & 80286
platforms. Reported in TUGboat Vol. 10, No. 1 (April 1989).
That's around the same time when TurboTeX was made.
As far as I know, web2c for DOS does still not run on these class of
computers.
> anyway, *please* also mention Y&Y's TeX package.
Full agreement. We should name all TeX ports we know that support
directory tree searching.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 06:22:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 Mar 95 12:59:41 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503071159.AA00940@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Question re. MetaPost files
Hi,
I'm sorry to jump into the discussion like that and I must admit that
I haven't even managed to catch up on the archives of this group I
downloaded from the SHSU gopher site, but I wanted to ask a question
before anything gets finalized and it is too late for additions.
The question is: What's the recommended directory structure for
MetaPost files, now that it has been placed in the public domain
earlier this year and stands a good chance to find its way into
standard TeXware eventually? When I developed some patches to
integrate MetaPost into the current web2c/kpathsea distribution,
I decided to put the MetaPost macro files (*.mp) into texmf/mp,
which I find a natural place and a nice counterpart for texmf/mf.
At present there aren't that many MetaPost macro files, so a single
directory is enough at the moment, yet the question arises what
to do when people start writing contributed MetaPost macros.
(I already started hacking some macros, but I haven't organized
that as separate macro files.) Would it be better to have one level
of subdirectories below texmf/mp, such as texmf/mp/{base,contrib}
in that case?
Another question is what do to about the other files that come with
MetaPost, most notably the troff support files. When I did the patches
for the current web2c, I put them into texmf/mplip in order not to
have them below texmf/mp, but I'm not sure if they really belong
into the TEXMF tree at all. Path searching currently doesn't work
for these files anyway, they use a fixed path specified at compile
time or by an environment variable MPLIP, so they might go anywhere.
(Some further explanation for those not familiar with MetaPost:
To process labels in figures, MetaPost normally invokes a shell
script `makempx' which in turn invokes the utilities `mptotex',
`tex' and `dvimp'. However, when invoked with a `-T' command line
option, MetaPost calls `troffmpx' instead which in turn invokes
`mptotr', `troff' and `dmp'. The latter utility requires some
auxiliary files such as a font map, a character adjustment table,
and a subdirectory holding some rather obscurely named files.)
Now what are the opinions of the list members? Is there any need
to specify a directory structure for MetaPost in the standard?
Should we care about the troff support files for MetaPost or leave
them out completely as TeX users usually wouldn't care to use them
anyway? For your information, I'll append an (edited) directory
listing of my personal MetaPost installation below.
texmf/doc:
total 2
drwxr-xr-x 2 vieth 2048 Mar 1 16:29 mp
texmf/doc/mp:
total 1446
-rw-r--r-- 1 vieth 40629 Jan 17 10:07 mpintro.tex
-rw-r--r-- 1 vieth 1202 Apr 20 1993 mpintro.bib
-rw-r--r-- 1 vieth 712 Jan 17 10:06 mpintro.bbl
-rw-r--r-- 1 vieth 53636 Feb 1 15:58 mpintro.dvi
-rw-r--r-- 1 vieth 143921 Feb 1 15:58 mpintro.ps
-rw-r--r-- 1 vieth 6057 Feb 1 12:01 examples.mp % figures
% for mpintro
-rw-r--r-- 1 vieth 340176 Jan 4 13:53 mpman.dvi
-rw-r--r-- 1 vieth 569067 Feb 1 16:02 mpman.ps
-rw-r--r-- 1 vieth 19920 Mar 29 1993 manfig.mp % figures
% for mpman
-rw-r--r-- 1 vieth 56720 Oct 4 1993 mpgraph.dvi
-rw-r--r-- 1 vieth 184847 Feb 3 10:59 mpgraph.ps
-rw-r--r-- 1 vieth 2974 Oct 4 1993 mpgraph.mp
-rw-r--r-- 1 vieth 935 Feb 3 10:55 agepop91.d % data files
-rw-r--r-- 1 vieth 753 Feb 3 10:55 agepopm.d % for mpgraph
-rw-r--r-- 1 vieth 958 Feb 3 10:55 countries.d % (missing in
-rw-r--r-- 1 vieth 2296 Feb 3 10:55 energy.d % distribution,
-rw-r--r-- 1 vieth 280 Feb 3 10:55 lead.d % got them from
-rw-r--r-- 1 vieth 258 Feb 3 10:55 matmul.d % John Hobby
-rw-r--r-- 1 vieth 252 Feb 3 10:55 timepop.d % on request)
texmf/dvips:
total 3
-rw-r--r-- 1 vieth 2165 Mar 1 16:34 mpfonts.map % MP currently
% can't use
% psfonts.map
% from dvips
texmf/mp:
total 88
-rw-r--r-- 1 vieth 322 Jan 11 17:02 TEX.mp
-rw-r--r-- 1 vieth 6842 Jan 11 17:02 boxes.mp
-rw-r--r-- 1 vieth 6912 Jan 11 17:02 format.mp
-rw-r--r-- 1 vieth 26388 Jan 11 17:02 graph.mp
-rw-r--r-- 1 vieth 4120 Jan 11 17:02 marith.mp
-rw-r--r-- 1 vieth 19169 Jan 11 17:02 mfplain.mp % mfmp format
-rw-r--r-- 1 vieth 15396 Jan 11 17:02 plain.mp % mp format
-rw-r--r-- 1 vieth 1060 Jan 11 17:02 rboxes.mp
-rw-r--r-- 1 vieth 1419 Jan 11 17:02 sarith.mp
-rw-r--r-- 1 vieth 763 Jan 11 17:02 string.mp
-rw-r--r-- 1 vieth 407 Jan 11 17:02 texnum.mp
-rw-r--r-- 1 vieth 230 Jan 11 17:02 troffnum.mp
texmf/mplib: % troff support
total 4
drwxr-xr-x 2 vieth 512 Mar 1 16:26 charlib
-rw-r--r-- 1 vieth 185 Aug 27 1990 trchars.adj % char. table
-rw-r--r-- 1 vieth 1340 Mar 7 1991 trfonts.map % fontmap
texmf/mplib/charlib:
total 35
-rw-r--r-- 1 vieth 255 Aug 22 1990 12
-rw-r--r-- 1 vieth 255 Aug 22 1990 14
-rw-r--r-- 1 vieth 257 Aug 23 1990 34
-rw-r--r-- 1 vieth 167 Aug 21 1990 Ao
-rw-r--r-- 1 vieth 162 Aug 21 1990 Fi
-rw-r--r-- 1 vieth 162 Aug 21 1990 Fl
-rw-r--r-- 1 vieth 2097 Aug 21 1990 L1
-rw-r--r-- 1 vieth 8827 Aug 21 1990 LH
-rw-r--r-- 1 vieth 3142 Aug 21 1990 Lb
-rw-r--r-- 1 vieth 1145 Aug 23 1990 Sl
-rw-r--r-- 1 vieth 168 Aug 21 1990 ao
-rw-r--r-- 1 vieth 147 Aug 22 1990 bx
-rw-r--r-- 1 vieth 179 Aug 21 1990 ci
-rw-r--r-- 1 vieth 138 Aug 21 1990 ff
-rw-r--r-- 1 vieth 1837 Aug 21 1990 lh
-rw-r--r-- 1 vieth 180 Aug 21 1990 ob
-rw-r--r-- 1 vieth 1724 Aug 22 1990 rh
-rw-r--r-- 1 vieth 234 Aug 22 1990 sq
-rw-r--r-- 1 vieth 124 Aug 22 1990 ~=
texmf/tex:
total 1
drwxr-xr-x 3 vieth 512 Mar 1 16:31 plain
texmf/tex/plain:
total 1
drwxr-xr-x 2 vieth 512 Mar 1 16:31 misc
texmf/tex/plain/misc:
total 1
-rw-r--r-- 1 vieth 532 Jan 11 17:02 mproof.tex % test file
% for proofs
Any comments on that?
Greetings,
Ulrik Vieth.
P.S. (1) One might ask if the top-level directory name TEXMF is still
approprate or should be turned into something like TEXMFMP. Even though
I think MetaPost should become part of standard TeXware eventually,
I wouldn't suggest changing the top-level name by now as MetaPost isn't
very widely available yet. (So far only on Unix system, maybe someone
is working on a DOS port? At least there was enquiriy about TRAP test
results recently from someone experimenting on a non-Unix system.)
P.S. (2) As I'm not currently a member of this group, I would be glad
if the list-owner could add me to the list please, at least temporarily.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 06:27:18 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081225.NAA17537@spice.iti.informatik.th-darmstadt.de>
Subject: Re: GF fonts
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 13:25:29 +0100 (MEZ)
Content-Type: text
David wrote:
>
> Joachim> Where are GF fonts placed? In fonts/gf/, or below fonts/pk/?
>
> I suppose fonts/gf although for most sites /dev/null is a more
> appropriate place. Are not these always converted to pk files then
> deleted?
Yes, on any sensible installation. But this is not the point. I
stumbled over this question when I was transforming the TDS example
distribution to the new font structure.
In the web2c-specific part, I had to specify a value for GFFONTS. I
would like to know what to put there... OTOH, Karl can throw out
support for $GFFONTS from his software, then I'll be quiet. :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:09:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 08:05:34 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081305.IAA15630@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Documentation subdirectories
References: <199503040120.CAA12269@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 02:20:57, Joachim Schrod wrote:
> ** Paralleling TeX tree impracticable
>
> If we really use doc/<format>/<package>/ and establish there a tree
> ``paralleling'' the tex/ tree, there will be lots of subdirectories
> with only one file. Namely, many LaTeX packages come with one
> documentation file and this will be the only member in that directory.
>
> I would prefer to say all style documentation that consists only of
> one file goes in a directory doc/latex/styles/, for instance.
Well, I can see your point. I'd be tempted to say that single documentation
files go in the "misc" package, but then how does a user find the docs?
Is that not confusing?
If we say everything goes in texmf/doc/latex/styles, what about styles
with several documentation files (a readme, doc.tex, example, and something
else)?
> ** Do we prescribe the <package> subdir?
>
> I don't understand that in full: I read
>
> texmf/<doc>/<category>/<package>/
>
> as general description. OTOH I read
>
> Files below the <category> level are determined by the
> documentation author.
Ooops. That should be <package> level; I've cleaned it up:
<para>
Files below the <replaceable>package</> level are determined by the
documentation author. The documentation directory may contain &TeX;
sources, <filename role=ext>DVI</> files, text files, or whatever form
of documentation will best explain the package.
</para>
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:14:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 08:10:39 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081310.IAA15661@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <199503041553.AA29310@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 10:53:26, K. Berry wrote:
> Actually, I'm not sure my name should be there. If someone else took
> over modes.mf maintenance the sentence wouldn't change.
> So maybe just ... using \filename{modes.mf} ...
Ok, I took out your name.
> (We need an appendix or footnote giving ftp sites/ctan locations.)
Yes, we do.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:19:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 08:14:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081314.IAA15687@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
References: <199503041549.AA29207@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 10:49:44, K. Berry wrote:
> 7. I think you may cause confusion by using the word "source"
> for the font supplier. How about "supplier", "vendor", or
> "foundry"?
>
> I used to use `foundry' in the fontname doc, but people objected, since
> `public' and `ams' aren't foundries.
>
> I'm opposed to `vendor' because that implies a monetary transaction to
> me :-).
I changed it to "supplier".
> I also think that you should use either "source"
> or "src" consistently (for font and program source code).
>
> Good point. Do people working on OS's other than Unix typically use
> `src' at all? Do they use `source'?
I vote for "source," regardless of convention because it's clearer.
A non-programmer type might not even recognize "src".
> Yes. I think the way we should generate this is by taking an actual
> working (minimal) TDS system and showing all the relevant pieces. I
> think a complete example will be well worth the space. Joachim, can your
> tree be made suitable for that purpose?
Agreed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:20:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 08:16:39 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081316.IAA15706@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
References: <794332293.637206.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 4 March 1995 at 10:51:33, BNB@math.ams.org wrote:
> i've said this before, but i guess not strongly enough ...
> there is no "ams" package. ams has three items for distribution
> that we refer to as packages: ams-tex, ams-latex, and amsfonts.
> granted that ams-latex is now accepted (by the latex3 group) as
> included in the main latex2e collection; that doesn't mean that
> ams-tex can be referred to unambiguously simply as "ams".
> please fix this in whatever way is most appropriate. <smile>
Sigh. We can certainly make the directories "amstex", "amslatex",
and "amsfonts", but I would have thought that the AMS would like
the simplification ;-)
texmf/tex/plain/ams is amstex because it's for plain
texmf/tex/latex/ams is amslatex because it's for latex
texmf/fonts/pk/ams is amsfonts because it's for fonts
No problem, though.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:35:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 08:30:51 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081330.IAA15971@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <"swan.cl.cam.:178250:950305181345"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 5 March 1995 at 18:13:39, Sebastian Rahtz wrote:
> comments on TDS 0.62
> ====================
> 1. p3. as Joachim said, mention all implementations which do subdir
> searching. add Y&Y's TeX, and remind the reader that it applies to dvi
> drivers as well as TeX itself. so mention dvips and xdvi as programs
> that implement it (natively as well as in *k versions)
Check.
> 2. p4. i think it is worth putting in a para saying
>
> "Even if your TeX implementation does not support subdirectory
> searching, you may still find it useful to adopt the structure if you
> do not use many fonts or packages. For instance, if you only use
> Computer Modern and AMS fonts, it it still possible to set them in the
> TDS structure, and list the directories individually in configuration
> files or enviornment variables"
>
> so as not to depress people. i did this, for instance, at home before.
> i got everything working as i wanted
Check.
> 3. p5. in naive mode, i wonder why BibTeX and MakeIndex are treated
> separately; they both come in any standard kit, and have standard
> support files.
MakeIndex isn't handled separately, it's just an example of "program".
BibTeX is large enough, and has enough user-contributed support files,
to warrant a special place.
Does everyone agree? Are there other tools we should specifically
mention?
> 4. p7. ams and pstricks are bad examples; there is no package called
> ams! and pstricks is generic. "babel" and "fancyheadings" might be
> better.
Ok.
> 5. (general).
>
> a) the martian example uses the texmf/initex/hyphen directory to put
Bloody heck. I ought to just take the martian example out and wait until
we can put in a real example. In fact, I think that's what I'll do.
> b) is it also quite clear that .dtx files should go in doc? or should
> they?
I'm assuming they should. I added a statement to that effect in the
documentation section (as an example, actually).
> c) i agree that "better way" should occur once, in an appendix
Check.
> d) (politics) may be sensible to note that this group only existed by
> email, just in case people think we have been meeting in person at
> vast cost. would it also be sensible to give affiliations of members?
>
> As I argued ages ago, the best thing to do with this draft is get it
> out in the hands of the critics!
I added an appendix for this purpose. Everyone should send me a "who you
are" statement, please.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 07:44:05 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Date: Wed, 08 Mar 1995 12:39:28 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:142300:950308124017"@cl.cam.ac.uk>
Joerg's proposal is interesting, but too me it is too backward looking
in its emphasis on Knuth's fonts as being different to others. i want
to squash this notion of the "canonical fonts" for ever and for
ever. you listening, Phil?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 08:25:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 14:23:59 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950308142359.22414a81@vms.rhbnc.ac.uk>
Subject: Re: Fonts... /Knuth
>> Joerg's proposal is interesting, but too me it is too backward looking
>> in its emphasis on Knuth's fonts as being different to others. i want
>> to squash this notion of the "canonical fonts" for ever and for
>> ever. you listening, Phil?
I certainly am. I felt considerable sympathy for, and empathy with, J"org's
suggestion, and felt that Joachim's rebuttal was somewhat o.t.t. (But then
Joachim is one of the few contributors who preferentially use IMO rather than
IMHO, and I think this tells us quite a lot in itself...). There is no doubt in
my ever-so-humble mind that Knuths _original_ fonts (not all Knuthian fonts:
I would not presume to argue for the canonicity of Punk) are indeed not only
`special' but are also `canonical'; they are either referenced in one or more
of Volumes A--E, or are needed to process some of the equally `canonical'
documentation.
But I also understand the reservations of Joachim, Norm, Sebastian et al,
who from the best of motives[1] wish to emphasise that
$$\TeX \not \implies \hbox {Computer Modern}$$
although I suspect that there are very few who would argue the contra-positive:
$$\hbox {Computer Modern} \not \implies \TeX$$
I also feel that J"org did himself and his proposal a considerable disservice
by not seeing it through to completion: to develop a nicely structured tree for
the {CM, LaTeX, AmsTeX, ...} fonts, but to leave the whole (and thorny) issue
of non-MetaFont fonts to simply be subsumed under [...local] is to abrogate
one's responsibilities rather prematurely. I would like take this opportunity
to encourage J"org to continue to develop his proposal, and to come up with a
proposal that Joachim will undoubtedly continue to regard as excessively
Knuthiocentric, but which would (at least to my unjaundiced mind) give equal
prominence to the existence of, and ever increasing need for, non-MetaFont-based
fonts.
** Phil.
[Who realises that he has just been drawn back into a debate from which he
publicly withdrew some time ago, and now wonders whether he should simply
type `Quit'rather than `Exit', in order that no-one but he ever sees the
text of this message. Ah well, if anyone _does_ see this message they
will know which decsion he reached!]
[P.S: recursive directory searching is available in Christian Spieler's
VMS implementations which I am currently beta-testing]
--------
[1] motives which I share.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:04:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 08 Mar 1995 10:04:44 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Message-ID: <794675084.684696.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
although, like phil, i hesitate to get back into this fray, i feel
i must. i'm not prepared to go so far as say that the cm fonts
should be identified as .../base/... but do find it essential that
they be segregated and clearly identified.
ams is now undertaking to accept input to publications in the form
of .dvi files, and it is imperative that we be able to tell our
authors in a very clear and understandable manner exactly what
fonts can be used. if there's a failure in printing on account
of an unidentified font, rather than spend the time and effort
of trying to identify and obtain it (an expensive undertaking
requiring the technical support staff), we would more likely take
the also costly, but potentially much less so, route of rekeying
it from scratch (authors are also required to submit the document
on paper). since this decision to use authors' .dvi files
depends on the general public availability of fonts, we're going
to be seeing a lot more computer modern. (part of the decision
is based on a related decision that much ams material will be
posted electronically, though not necessarily completely public
or free. we don't yet feel that postscript is sufficiently
universal among our audience to limit distribution to that form,
and we are also reluctant to force anyone to purchase fonts just
for the purpose of reading a few papers from ams. if there's
going to be money involved, it should benefit ams, in the form
of subscription or use fees.)
briefly, the fonts we feel must be clearly identifiable are:
- the basic cm 75
- amsfonts
- the latex fonts (lasy, line and circle)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:10:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 10:06:18 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081506.KAA17274@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <199503061844.AA21276@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 6 March 1995 at 13:44:42, K. Berry wrote:
> Another editorial msg, sent to the list for archiving purposes.
In among all the Checks and Oks are a few points we should talk about.
Sorry to make you go digging.
>
> and Norman Walsh (Chair)}}
>
> I feel like there should be a period at the end here. Also, I think we
> should make a new section after `Conventions' called `References' or
> some such, and put things like the group's email address, the mail
> archives on shsu.edu, explain `CTAN', and collect all the references to
> external documents that we mention elsewhere (e.g., fontname and modes.mf).
I added two appendices for this purpose: where are the files? and
about the committee.
> In the table of contents, `9 Summary' ended up on the second page. No
> good! All the frontmatter should be on page 1, and page 2 should start
> with the section heading `Introduction'.
Agreed. Although I've just added more sections, making the problem worse,
not easier to solve.
Suggestions?
> The purpose of this document is to describe a standard directory
>
> The primary purpose ...
Check.
>
> files (as a matter of practicality, this document also suggests ways
> to incorporate the rest of the {\TeX} files into a single structure).
>
> Make the `as a matter' a separate sentence, instead of a
> parenthetical. It deserves it.
>
Check.
> much easier for system administrators and users to install and maintain
>
> Delete `for system administrators and users', since mentioning those
> groups is (1) too general, and (2) not general enough :-).
Check.
> We hope that users and developers of both free and commercial implementations
>
> `administrators', not `users'.
Check.
>
> of {\TeX} will adopt this standard immediately. It has been designed to
>
> Suggest dropping the `immediately', especially since it's going to be
> circulated as a draft. Anyway, who are we to say what should be done
> immediately in the texadmin's lives ...
Check.
> it can be used
>
> the TWG believes it is usable? we intend it to be usable? ...?
TWG believes it is usable
> under Unix \acronym{MS-DOS}, \acronym{OS/2},
> Macintoshes, and \acronym{VMS}.
>
> on Unix, ... Macintosh, and ...VMS} systems.
> (note missing comma after Unix, singular Macintosh)
Fixed.
> complete runnable system to a simple macro or style file. It will also
>
> `single' better than `simple' here.
Check.
>
> The role of the TDS is to stabilize the organization of software
>
> ... of TeX-related software
Check.
>
> part of this role, however they do not. The role of the CTAN archives
>
> ... however,
> (always commas on either end of however in the middle of sentence.)
Check.
> distribution on CTAN it's useful to combine many different types of
>
> I think a comma after CTAN would be good here.
Check. And sorry Joachim, this is English, we don' need no stinkin' rules. ;-)
> In this document, ``/'' is used to seperate filename components. This
>
> separate (global replace, this occurs at least in one other place)
Check. (I really loathe that word).
> Also, perhaps say `components, as in texmf/fonts/...', just so people
> can see what we're talking about.
Check.
> is the Unix convention but it is arbitrary. The ideas are in no way
>
> Just drop the `it is arbitary', and combine the next sentence into this one.
Ok.
> Filenames are represented in typewriter (constant width) type.
>
> I don't like the word `represented' here. It should be `represented by',
> anyway. How about `typeset in'?
Ok. We'll burn the online bridge later ;-)
> Replaceable text, like \replaceable{package},
> identifies a class of things.
> Replaceable text is represented in typewriter
> oblique.
>
> To be parallel with the others, these sentences should be transposed.
Check.
> Also, somewhere in this Conventions section, we should say that ``TeX''
> in this document generally means ``the TeX system, including Metafont,
> utilities, etc.'', not just the `tex' program itself. (Blah blah blah.)
Check.
> This monolithic arrangement makes maintenance of {\TeX} software
>
> `a TeX system' more accurate than `TeX software' here, I think.
Check.
> Most implementations provide some ability to load files from different
> directories by specifying a list of directories to search (in the
> \systemitem{ENVIRONVAR}{TEXINPUTS} environment variable or a
> system configuration file, for example), but this is so cumbersome
> as to be unworkable at large sites.
>
> All this text is out of place where it is. It belongs in the next
> paragraph somewhere. In fact, here's a proposed revision of this whole
> area, since I don't think we're making the reasoning clear in the
> current text (a [w]diff should produce useful results, if you don't want
> to take it wholesale, once you undent):
I took it wholesale, Sebastian ;-)
> This TWG recognized that subdirectory searching places an extra burden
>
> The TWG recognizes
Check.
> is imperative to a well organized \textsc{TDS}. Implementors are encouraged to
>
> well-organized TDS, for the reasons stated above.
Check.
> If a hit is found in the database, subdirectory searching is never required
>
> `not' instead of `never'.
Check.
>
> and the performance of the system is essentially independent of the number
>
> Replace `essentially' with `this',
Huh? You don't mean:
and the performance of the system is this independent...
Do you mean:
and the performance of this system is essentially independent...
> of levels of subdirectories present on the system.
>
> `of levels' can be deleted.
Ok.
>
> As an consequence of the search strategy outlined above, two files in
>
> a consequence (not `an')
Check.
>
> define which one is found. To disambiguate this case, one must specify
> a search path that lists the respective subtrees in the search order
>
> ... a search path must be specified ...
> (usually I avoid passive voice with a passion, but it's too hard to say
> precisely who does the specifying here)
Fine.
> } requires monocase, 8.3
>
> Probably should explain ``8.3''. We know what we mean, but ...
I've added an example, as per Rich's suggestion. Good enough?
> materials. In this document we shall assume that this directory
> `call' or `designate' would be better than `assume that', I think.
Check.
> is called \filename{texmf}, although the exact name
>
> `but' instead of `although'.
Check.
>
> of the directory is up to the installer. On PC networks, this could
> map to a logical drive specification, for example
> \filename{T:}.
>
> On PC networks, for example, this could ... specification such as T:.
Check.
> Unix systems, this would traditionally be located in
>
> ... it would traditionally be
Check.
> itself), it is likely to be unused, and it is
>
> It's wrong to say `likely to be unused', since the default path for
> web2c/kpathsea has been using $(prefix)/lib/texmf for a while now.
> Either drop this clause, or say it's either unused or used in a
> mostly-compatible way (informal predecessor to the TDS, etc., etc.).
Dropped.
> under a system-dependent directory.
>
> I think it's `implementation-dependent' here, not `system-dependent'.
Check.
> For example, \filename{texmf} should not be created in the \filename{emtex} or \filename{pctex} directories.
>
> Maybe clearer to be flat-out about it: For example, `emtex/texmf' is wrong.
Ok.
> All of these directories
> may not be needed by all sites.
>
> Not all of these directories are needed at all sites.
Check.
> structure. For example, the binaries for a Sun workstation {\TeX}
>
> ... \TeX system
Check.
> might be installed in \filename{/texmf/bin/sun-sunos4.1.3}.
>
> `sparc' is more likely than `sun' here. Also, perhaps say `Or TeX
> administrators may wish to put executables outside texmf/ altogether'.
> (The TDS does not require execute be located in any particular place.)
Check.
> for {\TeX}info documents
>
> 1) It's Texinfo (all regular roman), not {\TeX}info.
Really? Ok.
> 2) missing a period after documents.
> 3) It should be `processed Texinfo documents', anyway, since it's the
> .info* files that go in info/, not the .texi sources.
Check.
> In this case, sources includes
> things like the source for Web2C (\filename{texmf/source/web2c/}
> and the \filename{dtx} sources for {\LaTeX}
> (\filename{texmf/source/latex/base}).
>
> For example, texmf/source/web2c and the \filename{dtx} sources ...
Check. Oh, but wait, are DTX files sources or documentation?
> example, Unix sites may wish to place all {\TeX} related files
>
> TeX-related
Check.
> ``local'' files. Sites are encouraged to maintain a seperate tree for
>
> separate
Check.
> \begin{alltt}
> TEXINPUTS=.:/usr/local/texmf/tex/latex//:/usr/local/oratexmf/tex/latex//
> \end{alltt}
>
> 1) latex/ should not be in this path.
> 2) the `TEXINPUTS=' seems unnecessary.
Check.
> \filename{texmf/tex/}\replaceable{format}\filename{/}\replaceable{package}\filename{/}\replaceable{files}
>
> files => file
Check.
> be used as macro packages; in this case we store them as formats.
> ...; the TDS nevertheless stores them as formats.
Check.
> another format (whereas placing them in the tree of another format
> would completely obscure their possible use as a format).
>
> drop the parens and add a comma after `another format'.
Check.
> By providing a format directory, subdirectory searching can be
>
> \replaceable{format}
Check.
> The special format directory \filename{generic} is
>
> 1) `special' seems unnecessary
> 2) \replaceable{format}
>
> Thus, for almost every \replaceable{format}, it is correct to
Check.
> For example, the \filename{amstex},
> \filename{plain}, and \filename{generic}
> directories should be searched when using {\AmS}{\TeX}.
>
> Additional text: This does mean \emph{only} those directories must be
> searched: texmf/tex// is a correct path for TeX inputs in a TDS tree.
Did you mean "does not mean only" or am I missing something?
> is the name of the package.
>
> `a' package, not `the'.
Check.
> The special package name \literal{base} is reserved for the base
>
> Again, `special' seems deletable.
Check
> Packages that consist of \emphasis{only} a single file shall be
> installed in the \filename{misc} package directory.
> It seems pointless to nest such a package/file within a directory
> of its own.
> It may also make
> subdirectory searching slower. For this reason, the \filename{misc} directory is reserved.
>
> For parallelism, this should start with something like:
> The package name \filename{misc} is reserved for packages that consist
> of a single file. It seems pointless ...
> (and dump the `For this reason' sentence.)
Check.
> arrangement after several long discussions about how best to arrange
>
> after long discussion
Check.
> The primary competition for this arrangement was a scheme which reversed
>
> `alternative to' better than `competition for'?
Check.
> [KARL RECOMMENDS MOVING THIS. WE NEED AN ``IS THERE A BETTER'' WAY
> SECTION FOR THE WHOLE THING, PERHAPS?]
>
> Nothing in this section has anything in particular to do with macros
> (vs. fonts, for example). Does it? Let's make it a section of its own
> before the Summary? Or in the Basics? Or somewhere. Not here.
I dropped it in an appendix...I forget who suggested that.
> make maintenance possible. The \textsc{TDS} specifies that fonts should be stored
>
> `feasible' better than `possible', I think. Anything's *possible*.
Anything?! ;-) Check.
> purpose; it designates forts for which there are no licensing problems
>
> fonts, not forts!
Check.
> font filenames, consult \emphasis{Filenames for {\TeX} fonts}:
> CTAN:/\filename{/info/fontname}.
>
> 1) Only need this ref once, either before or after the list, I think.
Check.
> 2) we have to explain the meaning of CTAN. I wonder if a URL
> ftp::/\replaceable{CTAN}/... would be better.
A non-specific URL? Ugh. And explanation of CTAN can go in Where are all
these files?
> 3) The first slash comes out in the wrong font.
And it doesn't belong there...
> 4) The path is wrong. Has to start with /tex-archive. Assuming you mean
> `CTAN' is a host name.
I don't, CTAN is a meta-thingy...
ftp.shsu.edu:/tex-archive or ftpserver.nus.sg:/pub/zi/TeX
> are the individual files.
>
> ... files, e.g., cmr10.tfm, putr.pfa, ptmr.pfa. But PK files need
> additional structure; see the next section.
Check.
> There is no need to ever have GF bitmap font files in a working TeX
> installation, since PK format bitmaps store the same information in less space.
I don't think we're all in agreement on that...
> type of device (mode) for which the font was created and the
>
> (i.e., mode)
Check.
> To identify the mode, fonts are typically segregated into different
>
> ..., common practice is to segregate fonts into ...
Ok.
> convention is usually to include the resolution in the filename. For
>
> Can drop the `usually'.
Check.
> And add `(in fact, this is how Metafont itself names its output)',
> maybe?
Ok.
> \filename{cmr10.300pk}. On other systems, for example \acronym{MS-DOS},
>
> `such as' instead of `for example' maybe. The `for example's are getting
> a bit thick.
Check.
> \filename{cmr10.pk} in the directory \filename{300dpi}.
>
> dpi300, not 300dpi.
Check.
> Since long filenames are not allowed by many file systems,
>
> Since the TDS cannot assume long filenames
Check.
> (see \xref{Section 4})
>
> It's not section 4, it's 2.2. Where's your symbolic references?!
The references are symbolic...in the SGML files! But apparently the filter
is broken...sigh...
> Therefore, under the \filename{pk} directory, two more
> subdirectory levels are used:
>
> ... directory, the TDS specifies two more subdirectory levels:
>
> $\ldots$\filename{/pk/}\replaceable{source}/\replaceable{typeface}/\replaceable{mode}\filename{/}\replaceable{dpi}\filename{/}\replaceable{files}
>
> Some of the slashes are in the wrong font.
Check.
> is the mode name which identifies the printer type. This
>
> identifiers the device type.
Check.
> Karl Berry maintains a complete set of {\protect\MF} modes; see:
> CTAN:\filename{/fonts/modes}.
>
> 1) For a complete set of Metafont modes, see ...
> (my name is irrelevant)
> 2) all the same comments about CTAN apply as before.
> 3) the path is tex-archive/fonts/modes/modes.mf.
Fixed, sortof.
> Analagously for \command{gsftopk}.
>
> Analogously
Check.
> is the resolution of the font. The directory name should
>
> specifies the resolution ...
Check.
> It is necessary to place \filename{dpi} in front of the
> resolution because some file systems require names to begin with a letter.
>
> Not sure this is true any more?
> So could say `Placing dpi in front of the resolution is common practice'.
AURGH! Common practice is to place it after. Should we switch to 300dpi
since it's allowed?
> Also, ``filesystem'' should be one word. Everywhere.
Check.
> \filename{cmr10.300pk}) provided that the basic scheme is also
>
> Comma after the ).
Check.
> The \textsc{TDS} specifies that \filename{PK} files \emphasis{must} contain
>
> In a TDS-conformant installation, all PK files *must* contain ...
> (We can't say anything about all PK files everywhere in the world!)
Check.
> Luckily, this information is very easy to supply: a simple addition to
>
> Delete `Luckily'. Luck is not involved :-).
> The `very' seems unnecessary.
Check.
> provide the required information. If you have been using a local modes
>
> Possibly the `If you ...' sentence should be after the colon, and then
> something like `If not, a simple addition based on the code in modes.mf'
> etc. etc.
I made a stab at it. Let me know what you think.
> file derived from (or is in fact) Karl Berry's \filename{modes.mf} distribution, the
>
> Delete my name again.
Yep.
> required information is \emphasis{already} in all of your \filename{PK}
>
> Delete `all of'.
Check.
> optionally be employed on those systems which support this file name
>
> Let's make `filename' one word.
Ok.
> The ``other'' arrangement that we considered was:
>
> ``other'' => alternative
Check.
> unusable if the implementation did not have some method for ``short
>
> if the implementation did not have => without
Check.
> There are still some concerns about efficiency, but there seems to be
>
> Some concerns about eff. remain, but ...
Check.
> {\protect\BibTeX} databases and style files are frequently scattered in with other
>
> frequently => commonly?
Check.
> for them.
>
> them:
Check.
> documentation should be stored in a structure that parallels the fonts
>
> parallels to some extent
Check.
> source files for the packages, but it seemed to be important that users find
> documentation in one place---for humans, searching directory trees
> is a nuisance. For these reasons, we decided
>
> ..., but we felt it was important that users be able to find
> documentation in one place, not mixed in with the source files; most
> users have no interest in sources. For these reasons ...
Check.
> \filename{texmf/doc/}\replaceable{category}\filename{/}\replaceable{package}/$\ldots$
>
> Insert `The TDS specifies:' before this. (Separate paragraph.)
Ok.
> For \replaceable{format}s, this will be the name
>
> For TeX ... (just to remind them)
Ok.
> and \filename{amstex}, etc.
>
> Delete `and'.
Check.
> Other categories include documentation for utilities
>
> ... include utility names, e.g., texmf/doc/bibtex, texmf/doc/makeindx, etc.
>
> There are two special catagories:
>
> ... two reserved category names:
Check and Check.
> David Jones' macro index, etc. and \filename{general} for standalone
>
> comma after etc.
Check.
> \emphasis{A Gentle Introduction to TeX},
> \emphasis{Components of TeX}, \filename{texbook.tex} and
>
> \TeX, not TeX, needed for both these.
Check.
> to document (or, preferably, automate) how the files should be moved from the
> archive structure into the TDS structure.
>
> New sentence: One possible method of automation is to make the
> distribution TDS-conformant itself, so a simple recursive copy will
> install the package.
> (Or something like that.)
We've talked about this a little bit; didn't we conclude that it's not
feasible to have TDS compliant distributions? Do we really want to
recommend this?
> For example, a package for Martian language typesetting might be distrubited
>
> distributed
Check
> the working TDS structure which looks like this:
>
> the corresponding TDS structure:
Check.
> texmf/fonts/martian/src/mart10.mf
> texmf/fonts/martian/tfm/mart10.tfm
>
> Hmm. I don't like these font filenames! Oh well.
Would you like to suggest alternatives?! ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:30:31 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Date: Wed, 08 Mar 1995 15:08:41 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:223790:950308151338"@cl.cam.ac.uk>
i wondered if i could coax Phil out his cave...
but it really cannot be right
a) to say that the 75 fonts are the *base* of a TeX distribution,
like the latex base directory; they are optional, albeit common; i
have thrown many of them away but cant still typeset the LaTeX guides,
which wouldnt be true if threw away teh LaTeX base directory
b) to arrange fonts according to which famous books areypeset using
them
is it also suggested that the macros tree strat with base/, which
contains plain.tex?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:31:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 10:26:59 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081526.KAA17640@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
References: <794675084.684696.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 10:04:44, BNB@math.ams.org wrote:
> although, like phil, i hesitate to get back into this fray, i feel
> i must. i'm not prepared to go so far as say that the cm fonts
> should be identified as .../base/... but do find it essential that
> they be segregated and clearly identified.
Fonts will be the death of us all.
We have, as a body, accepted the following arrangement:
texmf/fonts/<type>/<supplier>/<typeface>/
Using TFM files for illustrative purposes, this results in
texmf/fonts/tfm/public/cm/cmr10.tfm
texmf/fonts/tfm/public/latex/lasy10.tfm
texmf/fonts/tfm/amsfonts/euler/eurb10.tfm
Agreed? (That that's what the current draft says, not that it's what we want)
On J"org's proposal the problem I see is that
texmf/fonts/packages/amsfonts/...
puts us back in "texmf/fonts/<supplier>/<typeface>/<type>" land and,
please, let us not descend into that h*ll again. There's no way out.
We disagree. There are sound political and technical reasons for the
choice we've accepted (if "sound political reasons" is a semantically
meaningful construction ;-).
If the suggestion really is
texmf/fonts/<type>/base/...
texmf/fonts/<type>/packages/amsfonts/...
I don't see what it buys us. Directory levels are at a premium here:
texmf/fonts/pk/packages/amsfonts/euler/cx/dpi300/eurb10.pk
is too deep. Or, at best, just barely doable, I'm not sure how to read the
ISO-9660 spec. on this point.
On Barbara's proposal that the CM 75, AMS, and LaTeX fonts need special
identification, the problem I see is that ... I don't see how to do it.
Within the
texmf/fonts/<type>/<supplier>/<typeface>/
framework, what would satisfy the requirements of special identification?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The most likely way for the world to be
Production Tools Specialist | destroyed, most experts agree, is by accident.
O'Reilly & Associates, Inc. | That's where we come in; we're computer
90 Sherman Street | professionals. We cause accidents. -- Nathaniel
Cambridge, MA 02140 | Borenstein
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:48:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 10:44:29 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081544.KAA17854@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: GF fonts
References: <199503081225.NAA17537@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 13:25:29, Joachim Schrod wrote:
> David wrote:
> >
> > Joachim> Where are GF fonts placed? In fonts/gf/, or below fonts/pk/?
I added a note. I think they should go in fonts/gf/...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 09:59:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 10:55:09 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081555.KAA18010@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
References: <9503071159.AA00940@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 7 March 1995 at 12:59:41, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> At present there aren't that many MetaPost macro files, so a single
> directory is enough at the moment, yet the question arises what
> to do when people start writing contributed MetaPost macros.
> (I already started hacking some macros, but I haven't organized
> that as separate macro files.) Would it be better to have one level
> of subdirectories below texmf/mp, such as texmf/mp/{base,contrib}
> in that case?
>
> Another question is what do to about the other files that come with
> MetaPost, most notably the troff support files. When I did the patches
> for the current web2c, I put them into texmf/mplib in order not to
> have them below texmf/mp, but I'm not sure if they really belong
> into the TEXMF tree at all. Path searching currently doesn't work
> for these files anyway, they use a fixed path specified at compile
> time or by an environment variable MPLIB, so they might go anywhere.
I guess I'd vote that "mp" is just a program from the point of view
of the TDS spec. It doesn't seem large enough, or well enough established,
to warrant special treatment yet.
I'd say texmf/mp/ and what goes below that is whatever you want.
Personally, I'd probably use:
texmf/mp/lib
texmf/mp/macros
etc.
Sound reasonable?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 10:11:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 16:07:58 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950308160758.22417af9@vms.rhbnc.ac.uk>
Subject: Re: editorial comments
% > and the performance of the system is essentially independent of the number
% >
% > Replace `essentially' with `this',
%
% Huh? You don't mean:
%
% and the performance of the system is this independent...
%
% Do you mean:
%
% and the performance of this system is essentially independent...
No, he meant `thus': the human brain is meant to excel at fuzzy matching,
unlike most present computer systems...
% Check. Oh, but wait, are DTX files sources or documentation?
Yes :-)
** Phil.
================================================================================
From BNB@MATH.AMS.ORG Wed, 08 Mar 1995 11:09:36 EST
Return-path: <BNB@MATH.AMS.ORG>
Date: 08 Mar 1995 11:09:12 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Subject: Re: editorial comments
In-reply-to: <199503081506.KAA17274@jasper.ora.com>
To: norm@ora.com, karl@cs.umb.edu
Cc: bnb@MATH.AMS.ORG
Content-transfer-encoding: 7BIT
Mail-System-Version: <MultiNet-MM(351)+TOPSLIB(158)+PMDF(4.1)@MATH.AMS.ORG>
i think karl made a typo:
draft:
and the performance of the system is essentially independent of the number
karl:
Replace `essentially' with `this',
norm:
Huh? You don't mean:
and the performance of the system is this independent...
Do you mean:
and the performance of this system is essentially independent...
i think karl meant
and the performance of the system is thus independent...
^
i think i'll add karl to my list of terrorist proofreaders -- but we
may have to give him some more typing practice. <smile>
-- bb
================================================================================
From norm@ora.com Wed, 08 Mar 1995 11:15:25 EST
Return-path: <norm@ora.com>
Date: 08 Mar 1995 11:10:07 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: editorial comments
To: bbeeton <BNB@MATH.AMS.ORG>
Reply-to: norm@ora.com
Content-transfer-encoding: 7BIT
References: <199503081506.KAA17274@jasper.ora.com>
<794678952.165191.BNB@MATH.AMS.ORG>
On 8 March 1995 at 11:09:12, BNB@math.ams.org wrote:
> i think karl made a typo:
Thanks! I think you're right...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 10:28:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 16:28:43 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081628.AA07565@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
> Oh, but wait, are DTX files sources or documentation?
Don't know: probably best to do whatever Joachim says, he knowing
more about this LitProg stuff:-)
I think I am coming round to the view that *.dtx are *sources*, but
one may want to generate dvi/html/whatever *documentation* from them,
just as you can generate TeX input files.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 10:38:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081608.RAA22261@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Documentation subdirectories
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 17:08:35 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> On 4 March 1995 at 02:20:57, Joachim Schrod wrote:
> > ** Paralleling TeX tree impracticable
> >
> > If we really use doc/<format>/<package>/ and establish there a tree
> > ``paralleling'' the tex/ tree, there will be lots of subdirectories
> > with only one file. Namely, many LaTeX packages come with one
> > documentation file and this will be the only member in that directory.
> >
> > I would prefer to say all style documentation that consists only of
> > one file goes in a directory doc/latex/styles/, for instance.
>
> Well, I can see your point. I'd be tempted to say that single documentation
> files go in the "misc" package, but then how does a user find the docs?
> Is that not confusing?
That's why I didn't like the name misc/.
> If we say everything goes in texmf/doc/latex/styles, what about styles
> with several documentation files (a readme, doc.tex, example, and something
> else)?
Make a subdirectory in doc/latex/styles/. As this tree is looked at by
humans, not be speed-hungry algorithms, we can mix files and
subdirectories therein.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 10:42:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081634.RAA17706@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 17:34:17 +0100 (MEZ)
Content-Type: text
Phil wrote:
>
> I felt considerable sympathy for, and empathy with, J"org's
> suggestion, and felt that Joachim's rebuttal was somewhat o.t.t.
I would like to emphasize that I didn't send a `rebuttal', but a
comment that started with `For my taste' and as such is an expression
of a feeling, not of an argument.
Joachim
Some more, personal, comments on this mail, which you might not want
to read:
> (But then
> Joachim is one of the few contributors who preferentially use IMO rather than
> IMHO, and I think this tells us quite a lot in itself...).
Oh, I can help you to decipher that. In my mails IMO and IMHO are
short abbreviations of longer sentences: (1) IMO means ``it's my
opinion, and I think I have arguments for it that I will bring
forward if necessary.'' (2) IMHO means ``I start to have an opinion,
I have very prematurely arguments where I'm not sure that they will
last more than a minute in any serious discussion, but I will raise
the opinion nevertheless to get the discussion going.'' (3) With
neither of these, I think I'll have _good_ arguments and will present
them accordingly.
Besides, I think that the usage of IMHO is very bad style as it
assumes that the reader is dumb. Therefore I try to avoid it as often
as possible. Chuq Von Rospach once wrote
IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an
opinion something that is clearly from context an opinion to everyone
except the mentally dense. Opinions flagged by IMHO are actually
rarely humble. IMHO.
He's right. IMO.
> There is no doubt in my ever-so-humble mind
See? You assume we're so dumb that we can't see that you have an
`ever-so-humble mind.' Phil, we know your humbleness; you don't have
to emphasize it.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 10:51:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 16:50:21 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081650.AA07576@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
> On Barbara's proposal that the CM 75, AMS, and LaTeX fonts need special
> identification, the problem I see is that ... I don't see how to do it.
> Within the
> texmf/fonts/<type>/<supplier>/<typeface>/
> framework, what would satisfy the requirements of special identification?
Perhaps it would be sufficient to more strongly document that
texmf/fonts/*/public/cm
Should only consist of the original Knuth fonts, not any extra fonts
based on cmbase, by Knuth or anyone else.
That leaves the ams to document to authors that if they are using a
tds installation, they should ensure that they only use
texmf/fonts/tfm/public/cm/
texmf/fonts/tfm/public/latex
texmf/fonts/tfm/amsfonts
Not too bad, Barbara?
The only other alternative that would fit in the scheme of things
would be to invent two new <supplier>s and so move cm and LaTeX up a
level. However I think this was rejected finally last week, so I am
not arguing in support of this.
Actually most authors are not going to care about the font layout
anyway, so in practice, the ams documentation is presumably going to
say:
Don't use any packages that load fonts, unless they have been
supplied as part of amslatex.
Ie giving the restriction in terms of the document. Especially as it
is not always obvious where TeX did find a font.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:11:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Date: Wed, 08 Mar 1995 16:55:44 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:286720:950308165918"@cl.cam.ac.uk>
if the AMS wants to do us all a favour, they could propose a *real*
base set. what i object to about the "75" is the way we drag around
the baggage of cmdun, cminch, cmf* - when will it end? will be go on
being the laughing stock of the world forever because we stick in
Funny Fibonacci at the drop of a hat?
what i woild like would be a clear breakup of the Knuth fonts into
CMR
CMSS
CMTT
CM math
and "other" :-}
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:24:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 08 Mar 1995 12:23:40 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Message-ID: <794683420.335767.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
norm:
Fonts will be the death of us all.
[...]
On Barbara's proposal that the CM 75, AMS, and LaTeX fonts need special
identification, the problem I see is that ... I don't see how to do it.
thanks, norm.
actually, what you have listed, for tfm files,
texmf/fonts/tfm/public/cm/cmr10.tfm
texmf/fonts/tfm/public/latex/lasy10.tfm
texmf/fonts/tfm/amsfonts/euler/eurb10.tfm
does serve to segregate and identify the groups sufficiently
clearly.
(i didn't mean that they should all be packed somewhere
together, only that we need to be able to tell our authors
where to look, or -- if they get a new version from our
e-math archive -- where they should put them.)
i am now reassured, and that's all i need.
-- bb
================================================================================
From CHAA006@vms.rhbnc.ac.uk Wed, 08 Mar 1995 13:12:50 EST
Return-path: <CHAA006@vms.rhbnc.ac.uk>
Date: 08 Mar 1995 18:11:51 +0000 (GMT)
From: Philip Taylor <CHAA006@vms.rhbnc.ac.uk> (RHBNC)
Subject: TWG-TDS
To: bnb@MATH.AMS.ORG
Cc: CHAA006@vms.rhbnc.ac.uk
Reply-to: P.Taylor@Vms.Rhbnc.Ac.Uk
Content-transfer-encoding: 7BIT
>> i am now reassured, and that's all i need.
Oh groan... now you've given in, just when I thought we had them!
:-)
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:35:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 08 Mar 1995 12:35:31 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Message-ID: <794684131.907767.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
david:
Perhaps it would be sufficient to more strongly document that
texmf/fonts/*/public/cm
Should only consist of the original Knuth fonts, not any extra fonts
based on cmbase, by Knuth or anyone else.
yes, david. perfect!
re the suggested admonition to authors
Don't use any packages that load fonts, unless they have been
supplied as part of amslatex.
i think it would be wise to expand it:
Don't use any packages that load fonts, \emph{including your
own}, unless they have been supplied as part of amslatex.
(i know, it's somewhat self-contradictory, but authors will try
to get away with anything they can. <smile>) then all we have
to do is get authors to actually read the documentation ...
thanks.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:39:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 8 Mar 1995 09:39:43 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081739.JAA19416@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Strongly support the idea that cm/ means those fonts, and only those
fonts that are presented in Computers and Typesetting Volume E.
This means that it does not include extracm, or Sauter interpolations
or anything else of that sort. That really matters only for the
mf sources, but it had better be consistent across all the
other <type>s as well, especially when the <type>/<supplier> path
tends to scatter cm-related files across the landscape.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:44:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 17:44:09 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081744.AA07634@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Sebastian
what i woild like would be a clear breakup of the Knuth fonts into
CMR
CMSS
CMTT
CM math
An excellent idea, I agree with you that one of the main reasons for
not taking the idea of a `standard set' of fonts seriously is that the
set is so clearly just a collection of excercises in the use of
metafont, rather than something designed as a base set for a large
class of documents.
Hence fibonacci fonts are included , but `missing' are many small and
bold versions (some of the major gaps here now being filled by the ams
cmextra collection)
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 11:48:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 12:44:12 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081744.MAA20389@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New draft...
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/private/twg-tds/tdsguide.*
As usual, all the other files are there too...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:07:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 18:08:01 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950308180801.2241648c@vms.rhbnc.ac.uk>
Subject: Re: Fonts... /Knuth
>> if the AMS wants to do us all a favour, they could propose a *real*
>> base set. what i object to about the "75" is the way we drag around
>> the baggage of cmdun, cminch, cmf* - when will it end? will be go on
>> being the laughing stock of the world forever because we stick in
>> Funny Fibonacci at the drop of a hat?
There is no Funny Fibonacci; the `I' of CMFI is `Italic', and there is no
corespondence whatsoever between CMFI (`funny italic') and CMFIB (`fibonacci')
other than the purely coincidental one of their names...
But no matter how little you like them, each and every one of the 75 is
documented in Volume E, and therefore `canonical' all the while we
continue to acknowledge DEK's inalienable right to the system called `TeX'.
Of course, if you want to re-formulate this group as the `Technical Working
Group on a LaTeX Directory Structure', you can throw most of the 75 out
of the window...
>> what i woild like would be a clear breakup of the Knuth fonts into
>> CMR
>> CMSS
>> CMTT
>> CM math
>> and "other" :-}
Presumably including CMBX, CMTI, CMXBTI, and all the other vital members of the
CM family which are omitted from the above (IMESHO over-simplistic) analysis...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:25:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081824.TAA19710@spice.iti.informatik.th-darmstadt.de>
Subject: Re: editorial comments
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 19:24:20 +0100 (MEZ)
Content-Type: text
David wrote:
>
> > Oh, but wait, are DTX files sources or documentation?
>
> Don't know: probably best to do whatever Joachim says, he knowing
> more about this LitProg stuff:-)
Thanks for the flowers, but I don't know what to do here either.
For me, as somebody who's also writing LaTeX packages, DTX files are
indispensable as documentation. Since quite some folks write macros,
they might be in the same situation. Ergo: doc/latex/source/ or
similar.
On the other hand: DTX _are_ the sources of LaTeX, by definition.
Ergo: source/latex/base/.
In any case, here comes the IMHO ;-) of LaTeX style documentation: I
provide DVI versions of the user manual part of DTX files in
doc/latex/styles/. My users (most of them don't do TeX programming)
have responded with positive feedback, as DTX sources in themselves
are not very readable and TeXed DTX sources present stuff that is
baggage (in their view, as pure authors). Actually, I use an ltxdoc
configuration for this aim, that I append FYI below.
Cheers,
Joachim
---------------- included file
% ltxdoc.cfg 11 Jan 95
%------------------------------------------------------------
%
% Configuration for LaTeX standard class `ltxdoc'
% (Program documentation for LaTeX)
%
% A4 paper is used almost everywhere, except in the US; make that the
% default.
\PassOptionsToClass{a4paper}{article}
% If a file `OnlyDesc' exists in the input path, we just typeset the
% description (i.e., everything until \StopEventually). That's a
% convenient way to get only the user documentation from style files
% that use the ltxdoc class for documentation.
\InputIfFileExists{OnlyDesc}{%
\AtBeginDocument{\OnlyDescription}%
}{}
\endinput
---------------- eof
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:29:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 13:25:40 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081825.NAA21383@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
References: <794684131.907767.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 12:35:31, BNB@math.ams.org wrote:
> david:
> Perhaps it would be sufficient to more strongly document that
>
> texmf/fonts/*/public/cm
>
> Should only consist of the original Knuth fonts, not any extra fonts
> based on cmbase, by Knuth or anyone else.
>
> yes, david. perfect!
>
> re the suggested admonition to authors
I've extended the wording of the description for "typeface" to:
<varlistentry><term><replaceable>typeface</></>
<listitem>
<para>
is the name of the typeface family. <filename>cm</>,
<filename>latex</filename>, <filename>amsfonts</>, <filename>concrete</>,
<filename>bookman</>, and <filename>courier</> are
examples of <replaceable>typeface</>.
</para>
<para>
The names <filename>cm</>, <filename>latex</>, and <filename>amsfonts</>
are very specifically defined. The <filename>cm</> typeface directory
contains precisely the 75 fonts defined in <emphasis>Computers and
Typesetting, Volumes A-E</>. The <filename>latex</> typeface directory
contains only the fonts distributed with &LaTeX; in the <emphasis>base</>
distribution. The <filename>amsfonst</> typeface directory
contains only the fonts distributed by the &AMS;.
</para>
</listitem></varlistentry>
> Don't use any packages that load fonts, unless they have been
> supplied as part of amslatex.
>
> i think it would be wise to expand it:
>
> Don't use any packages that load fonts, \emph{including your
> own}, unless they have been supplied as part of amslatex.
>
> (i know, it's somewhat self-contradictory, but authors will try
> to get away with anything they can. <smile>) then all we have
> to do is get authors to actually read the documentation ...
While I agree that these are things the AMS wants to say, do they really
belong in the TDS spec?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:31:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 13:26:56 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081826.NAA21406@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
References: <950308180801.2241648c@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 18:08:01, Philip Taylor wrote:
> >> if the AMS wants to do us all a favour, they could propose a *real*
> >> base set. what i object to about the "75" is the way we drag around
> >> the baggage of cmdun, cminch, cmf* - when will it end? will be go on
> >> being the laughing stock of the world forever because we stick in
> >> Funny Fibonacci at the drop of a hat?
>
> [...]
>
> But no matter how little you like them, each and every one of the 75
> is documented in Volume E, and therefore `canonical' all the while
> we continue to acknowledge DEK's inalienable right to the system
> called `TeX'. Of course, if you want to re-formulate this group as
> the `Technical Working Group on a LaTeX Directory Structure', you
> can throw most of the 75 out of the window...
>
> [...]
Phil's right. The CM 75 are untouchable. Where ever they go, they *all*
go there.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:32:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 13:28:02 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081828.NAA21442@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <199503081824.TAA19710@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 19:24:20, Joachim Schrod wrote:
> David wrote:
> >
> > > Oh, but wait, are DTX files sources or documentation?
> >
> > Don't know: probably best to do whatever Joachim says, he knowing
> > more about this LitProg stuff:-)
>
> Thanks for the flowers, but I don't know what to do here either.
>
> For me, as somebody who's also writing LaTeX packages, DTX files are
> indispensable as documentation. Since quite some folks write macros,
> they might be in the same situation. Ergo: doc/latex/source/ or
> similar.
>
> On the other hand: DTX _are_ the sources of LaTeX, by definition.
> Ergo: source/latex/base/.
I vote that DTX files are sources. Formatted DTX files (LaTeX (ohh, that's
not allowed is it ;-), HTML, DVI, etc.) are documentation.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:34:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 18:35:03 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081835.AA07676@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
> While I agree that these are things the AMS wants to say, do they really
> belong in the TDS spec?
er, no. I think that was a `side discussion' on how the ams docs should
interface to this stuff...
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:35:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 18:35:59 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950308183559.2241648c@vms.rhbnc.ac.uk>
Subject: RE: New draft...
>> ftp://jasper.ora.com/private/twg-tds/tdsguide.*
Aarrrgggghhhhh: my suggestion concerning `such as' rather than `like'
when comparing different levels of abstraction clearly fell on barren
ground: compare and contrast, if you will, the first two instances of
`like' in the new draft...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:36:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 18:37:15 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081837.AA07681@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
> I vote that DTX files are sources. Formatted DTX files (LaTeX (ohh, that's
> not allowed is it ;-), HTML, DVI, etc.) are documentation.
Seems to be the general view, go for it, before someone objects:-)
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:40:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 18:39:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503081839.AA07686@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
> Phil's right. The CM 75 are untouchable. Where ever they go, they *all*
> go there.
Sad, but true.
Still it seems that we are nearing completion of the draft document?
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:42:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 13:37:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081837.NAA21864@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: New draft...
References: <950308183559.2241648c@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 18:35:59, Philip Taylor wrote:
> >> ftp://jasper.ora.com/private/twg-tds/tdsguide.*
>
> Aarrrgggghhhhh: my suggestion concerning `such as' rather than `like'
> when comparing different levels of abstraction clearly fell on barren
> ground: compare and contrast, if you will, the first two instances of
> `like' in the new draft...
Sorry. Tired ears, perhaps, but not deaf.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 12:46:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 13:42:28 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503081842.NAA21910@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: editorial comments
References: <950307170431.22403472@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 7 March 1995 at 17:04:31, Philip Taylor wrote:
> 1.
> >> Replaceable text, like \replaceable{package},
> ^^^^ `such as', not `like'.
> >> identifies a class of things.
> >> Replaceable text is represented in typewriter
> >> oblique.
Check.
> 2.
> >> In this case, sources include.
> >> things like the source for Web2C (\filename{texmf/source/web2c/}
> ^^^^ -ditto-
> >> and the \filename{dtx} sources for {\LaTeX}
> >> (\filename{texmf/source/latex/base}).
This all got reworded anyway, but thanks...
Cheers,
norm
P.S. I just missed this message as I was going through making corrections.
It got lost between two messages from another list...sorry, again, Phil.
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 13:11:47 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
Date: Wed, 08 Mar 1995 19:05:13 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:067920:950308190622"@cl.cam.ac.uk>
>
> There is no Funny Fibonacci; the `I' of CMFI is `Italic', and there is no
> corespondence whatsoever between CMFI (`funny italic') and CMFIB (`fibonacci')
they should al be called cmsilly...
> But no matter how little you like them, each and every one of the 75 is
> documented in Volume E, and therefore `canonical' all the while we
> continue to acknowledge DEK's inalienable right to the system called `TeX'.
i don't buy this. TeX is TeX, volumes 1 and 2 of C&T, in my view.
as i said, do all Knuths macros also have to be called base?
> Presumably including CMBX, CMTI, CMXBTI, and all the other vital
> members of the CM family which are omitted from the above (IMESHO
> over-simplistic) analysis... **
these are part of the CMR family, by my analysis.
cmbx is a waste of space. have you ever used it? no, dont answer, i
bet you have...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 14:02:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081959.UAA23030@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 20:59:02 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> > a) the martian example uses the texmf/initex/hyphen directory to put
>
> Bloody heck. I ought to just take the martian example out and wait until
> we can put in a real example.
IMO the problem is: We don't necessarily agree what's a good
structure for the distribution of a package.
For instance, Rick proposed some `sparse TDS tree' with the files of
this package. For packages that build up a complete TeX distribution
I agree fully with him (actually, the TDS example distribution is
made exactly this way).
But for a sole package distribution, like it's uploaded on CTAN, I
don't agree. There the directory depth would explode and it would not
be feasible any more for somebody who searches some files on CTAN. At
least, I have to confess that I would be reluctant to organize _my_
macro distributions this way. ;-)
Effectively, that's again the double role of CTAN: It's not only
used for distribution, but also for archival and distribution
purposes.
Anybody else with an opinion of this distinction? Positive, negative?
Or are there many more people who think I'm too direct and unpolite
again, and I should better be quiet on these issues?
Un-humble greetings,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 14:38:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 12:39:10 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503082039.AA21420@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Editorial comments
But for a sole package distribution, like it's uploaded on CTAN, I
don't agree. There the directory depth would explode and it would not
be feasible any more for somebody who searches some files on CTAN.
I never intended that the CTAN store unpacked forms of individual, sparse
trees. Rather, I intend that the CTAN store the Info-Zipped archives of
these trees, along with the "packing list" files. I WOULD like to see a
few "definitive" examples of TDS-compliant installations maintained for
public inspection, but I don't see folks pulling files from these spots.
-Rich
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 14:41:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 08 Mar 1995 15:41:24 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Message-ID: <794695284.861550.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
joachim voices exactly my concern:
IMO the problem is: We don't necessarily agree what's a good
structure for the distribution of a package.
in the ams packages, we have enough files that exploding the
directory structure to mirror the tds structure would cause
what i feel are unnecessary complications. i would prefer to
keep the archive structure compact, and instead provide good
documentation to a user as to where files should be placed in
a for-use environment. (and i sure hope that all the major
tex implementors agree, or we're going to have a dreadful mess
on our hands.) the department budget already has me down for
25% of my time to be spent on support, and there are allocations
for the other two in the department too. (actually, i'm spending
more than that right now, but i think it's going to slack off
as amslatex 1.2 settles down.) since this was barely a trivial
item in my duties until jan 1, when the person who was taking
care of it left for greener pastures, it has rather substantially
affected what i do. (nothing has been removed from the list in
compensation.) i'm interested in not increasing the load.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 14:43:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 1995 15:39:28 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503082039.PAA24409@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <9503082039.AA21420@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 12:39:10, Rich Morin wrote:
> But for a sole package distribution, like it's uploaded on CTAN, I
> don't agree. There the directory depth would explode and it would not
> be feasible any more for somebody who searches some files on CTAN.
>
> I never intended that the CTAN store unpacked forms of individual, sparse
> trees. Rather, I intend that the CTAN store the Info-Zipped archives of
> these trees, along with the "packing list" files. I WOULD like to see a
> few "definitive" examples of TDS-compliant installations maintained for
> public inspection, but I don't see folks pulling files from these spots.
I'm still a fan of having an extension (.tds.zip ?) that does automatic
archiving to taste. Let's say I include a file called "DIRSTRUCT.TDS"
in the distribution, then wuftp "does the right thing" if I try to
"get directory.tds.zip". It's probably hopeless, but I like it ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 16:33:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503081935.UAA23508@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Filename constraints
To: TWG-TDS@SHSU.edu
Date: Wed, 8 Mar 1995 20:35:44 +0100 (MEZ)
Content-Type: text
Karl (some time ago) wrote:
>
> Yes. I think the way we should generate this is by taking an actual
> working (minimal) TDS system and showing all the relevant pieces. I
> think a complete example will be well worth the space. Joachim, can your
> tree be made suitable for that purpose?
I think I have almost all current TDS decisions installed in the
example distribution. I append the directory map to this mail. Btw,
this example distribution is in production usage for some hundred
users at our site.
The directory map, a map that also shows all files is available at
ftp.th-darmstadt.de:/pub/tex/TDS-compliant/. A set of tar.gz files
that make up the example distribution is in the subtree archives/.
Please note: `example' here concerns TDS, not the distribution; i.e.,
I don't consider this distribution as a real-life end-user-oriented
example of a good distribution. It's more a set of bricks where one
can build a real distribution (like teTeX is one) from. Nevertheless,
I know of some admins who fetched the archives and used it.
Known problems in the following map:
-- doc/latex-styles/ will get doc/latex/styles/, eventually.
-- doc/babel/ might get doc/generic/babel/.
Don't know that yet.
-- pk files are stored somewhere else, so only a short example is
visible here. And this example uses an illegal (mixed-case) mode
name... :-)
-- INITEX files for LaTeX are still in directories
{latex,latex209}/initex/, they have to go to base/.
Some specialities I would like to mention:
-- web2c/v6.1/ should be discarded from the list (I thought about
doing it by hand. ;-) I use it to store version-specific files as
I often run several web2c versions in parallel: typically I don't
have the time to update all supported Unix platforms (9 in total),
where I install web2c-based TeX ports, at the same time. But the
TDS tree is accessed from all platforms, via NFS.
Since more people might be in a similar situation, I let the
directory there as it is, as a discussion point.
-- I use tex/latex_2/ as a tree for LaTeX 2.09 styles that run with
2e, but are not officially transformed. TUGboat styles are a good
example of this category: They are almost functional (as long as
one does not use \TUB).
I hope that this subtree will get unnecessary in the near future.
Cheers,
Joachim
---------------- included file:
Directory map of TDS compliant TeX installation
as of Wed Mar 8 19:04:20 GMT 1995
bibtex
bst
doc
babel
bibtex
cm
dc
eplain
fontname
fonts
adobe
bitstream
urw
formate
generic
hyphen
latex
base
styles
latex-styles
latex209
plain
texdraw
tugboat
tugboat-mac
trees
dvips
fonts
afm
adobe
utopia
bitstream
charter
urw
antiqua
grotesk
nimbus
pk
public
thd
CanonCX
src
ams
cyrillic
euler
extracm
symbols
public
cm
concrete
dc
gray
latex
logo
manual
pandora
tfm
adobe
avantgar
bookman
courier
helvetic
ncntrsbk
palatino
symbol
times
utopia
zapfchan
zapfding
ams
cyrillic
euler
extracm
symbols
bh
wingding
bitstream
charter
cg
albertus
atqolive
clarendo
coronet
courier
garamond
lettrgth
marigold
optima
times
univers
monotype
helvetic
symbol
timesnew
public
cm
concrete
dc
latex
logo
manual
pandora
thd
urw
antiqua
grotesk
nimbus
tmp
type1
adobe
utopia
bitstream
charter
urw
antiqua
grotesk
nimbus
vf
adobe
avantgar
bookman
courier
helvetic
ncntrsbk
palatino
times
utopia
zapfchan
bitstream
charter
cg
albertus
atqolive
clarendo
coronet
courier
garamond
lettrgth
marigold
optima
times
univers
monotype
helvetic
timesnew
urw
antiqua
grotesk
nimbus
makeindx
mf
mft
tex
amstex
base
eplain
formate
base
styles
generic
babel
config
misc
hyphen
initex
latex
base
caption
citations
config
dvilj
fancyheadings
graphics
initex
mflogo
mfnfss
misc
ssqquote
tools
latex209
base
cweb
dvips
initex
misc
texdraw
latex_2
misc
tugboat
mft
plain
base
dvips
js
misc
stanford
texdraw
tugboat
texinfo
ttex
web2c
ini
v6.1
---------------- eof
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 16:38:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 08 Mar 1995 23:39:05 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Fonts... /Knuth
To: TWG-TDS@SHSU.edu
Message-ID: <01HNWSIGV4IA99DRWW@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Phil asked me to flesh out the local area. Well, I think the local area I
maintain is so special that I won't recommend it to other installations,
however, here is a short description.
The following `packages' are supported:
Laserjet-35 fonts for ps-nfss1
Laserjet-35 fonts for psnfss2e
vmsps (souvenir and lubalingraph) for latex2e
I have also experimented with:
sil-ipa 3 families of ipa fonts
I have sorted the tfm and vf files for postscript font on the first level
according to the generation method, thus there are directories
[.fonts.afmtotfm], [.vf.afmtotfm], [.fonts.fontinst], and [.vf.fontinst]
(in the traditional style [.fonts] is just a synonym for [.tfm], and [.pk]
is another top level directory in tex_root).
After that, I decided, there aren't many enough fonts to bother for further
subdivisions, so that it is. If I had to subdivide further, the next cut
would go: [.fonts.afmtotfm.lw35] vs. [.fonts.afmtotfm.sil-ipa]
and [.fonts.fontinst.lw35] vs. [.fonts.fontinst.vmsps]
Strictly speaking, the separation between afmtotfm and fontinst tfms and
vfs is not necessary for the lw35 fonts, since the new fontinst names are
that well designed, that there is no overlap in name space. However, the
separation will allow the easy discarding of the obsolescent afmtotfm
fonts some day.
Another remark: In different printers, the lw35 set is supplied by at
least 3 different parties (adobe, itc, pacific page), a distinction by
supplier looks not very sensible in this case.
Again, this not meant for any other installation than the specific one with
its specific needs here. And these specific needs are very heavily
cm-centered (electronic preprint exchange, reuse of old files with slight
changes, etc.), anything else is a nice add-on. Another local area will
probably look completely different and have different needs.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 17:48:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Mar 95 15:48:38 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503082348.AA22109@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
I think that Joachim's directory list, although interesting, provides a
very clear demonstration of the difference between a directory listing
and the kind of figure I generated. Even if Joachim's list were annotated
and put into a tidier (to my taste :-) format, it would still:
1. be too large to be comprehended as a whole
2. not be guaranteed to show all possible parts of the TDS tree
Thus, while I have no problem with someone generating an annotated version
of a list like Joachim's, nor with including it as an appendix to the TDS
document, I don't see it as a substitute for my figure.
Getting back to the TDSI (TDS Implementation) discussion, Norm says:
I'm still a fan of having an extension (.tds.zip ?) that does automatic
archiving to taste. Let's say I include a file called "DIRSTRUCT.TDS"
in the distribution, then wuftp "does the right thing" if I try to
"get directory.tds.zip". It's probably hopeless, but I like it ;-)
I have no particular problem with this, in principle. In practice, I am
concerned that the implementation might get a bit resource intensive,
error-prone, and tedious for the FTP client. If I understand what Norm
is suggesting, the archive's wuftp software would (automagically):
1. unpack the existing archive (foo.tar.gz, bar.zip, or whatever)
into a suitable amount of unused storage space, left conveniently
lying around by Sebastian, et al.
2. Using some sort of script or makefile, move the unpacked files
and directories into an empty directory, building TDS-compliant
sub-directories as needed.
3. Create an archive of this tree, using Info-Zip.
4. Hand it off to the FTP client, presuming the session hasn't timed
out in the meanwhile.
If a makefile were used, and sufficient long-term storage were available,
the process would not be repeated the next time someone asked for the
archive. On the other hand, we would still have to deal with the chance
of two users asking for the same archive at the same time. This could lead
to some *really* trashed-up files getting sent out.
The biggest concern I have, however, is that if anything goes wrong, we have
a random client watching as things crater, possibly without any indication
of what is going on, and certainly without any ability to set things right.
This is *not* my notion of a recipe for a stable, trouble-free server!
Barbara has her own slant, which I will attempt to answer in sections:
in the ams packages, we have enough files that exploding the
directory structure to mirror the tds structure would cause
what i feel are unnecessary complications.
Nobody is saying that the "official" AMS directory structure needs to be
changed in any manner whatsoever. It is clear, however, that *somebody*
will have to figure out how to explode "the directory structure to mirror
the tds structure" or there will never be any AMS distributions found in
TDS-compliant installations.
The question, therefore, is when, how many times, and by whom, the job
should be done. I claim that it is best done early, once, by someone who
understands the AMS distribution and the TDS layout. This person doesn't
have to be Barbara; anyone who has the knowledge and interest would do.
i would prefer to keep the archive structure compact, and instead
provide good documentation to a user as to where files should be
placed in a for-use environment. (and i sure hope that all the
major tex implementors agree, or we're going to have a dreadful
mess on our hands.)
The archive structure (by which *I* mean the internal structure of the
Info-Zip archive), should be a black box to everyone involved. It takes
no additional space, really, to archive a sparse tree of directories and
files than it does to archive a single directory.
Nor is there any reason why a TDS-compliant tree is less understandable
than any other arbitrary layout. If we've done a reasonable job, it is
likely to be *more* understandable than most current layouts.
The question of providing good documentation is misleading. A properly
designed installation kit should *need* no documentation. The user
should only look at documentation to find out how to *use* the package
in question. (Ever installed a MacOS application?)
Finally, I find myself really disturbed by the implications of "hoping
that all the major tex implementors agree". Implementors are free to
disagree or not, but they can't call themselves TDS-compliant unless
they follow the TDS. If the TDS is so loose it allows compliant systems
to get folks into trouble, perhaps we haven't done *our* job right.
-Rich
================================================================================
From BNB@MATH.AMS.ORG Wed, 08 Mar 1995 18:57:54 EST
Return-path: <BNB@MATH.AMS.ORG>
Date: 08 Mar 1995 18:57:42 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Subject: "a bit about myself"
To: norm@ora.com
Bcc: bnb@MATH.AMS.ORG
Content-transfer-encoding: 7BIT
Mail-System-Version: <MultiNet-MM(351)+TOPSLIB(158)+PMDF(4.1)@MATH.AMS.ORG>
for the tds draft:
Beeton, Barbara. Composition systems specialist and member of the
technical support staff, Electronic Products and Services Department,
American Mathematical Society, Providence, RI, U.S.A. Editor, TUGboat;
charter member and Board member, TeX Users Group.
(if you feel it's over-much, feel free to leave off everything
following "editor, tub".)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Mar 1995 18:03:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 09 Mar 1995 01:02:59 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <spieler@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: spieler@linac.ikp.physik.th-darmstadt.de
Message-ID: <0098D141.FC5607E0.2096@linac.ikp.physik.th-darmstadt.de>
Subject: VMS TeX does now partly support subdir searching.
Hello,
Since Phil Taylor has mentioned the subdirectory searching capability
of current VMS TeX beta's, I should add a clarifying statement:
I have now released a new revision of DECUS TeX for VMS, where
the core programs (TeX, Metafont, Web, and the XXware utilities)
support subdirectory searching for input files. This capability has
been archived by using VMS's supplied wildcard searching service.
The VMS wildcard syntax allows specifications of
- single level subdir searching: [path.*]
- multilevel subdir searching: [path...]
- fixed level subdir searching: [path.*.*]
- fixed and multi level subdir searching
with pruning (is this term right?): [path.*.specdir.*]
[path.*.specdir...]
but NOT: [path...specdir] !!!!
The implementation relies on the OS' file system support.
At program level, there is no caching implemented, and it is
not planned to implement any user level file name caching.
The main advantage of this approach is its transparency:
The used syntax for `subdir searching' is not unique for TeX and friend,
but works with all other VMS programs that support wildcard file names,
as the editor, file handling commands (copy, directory, backup, ...).
The main drawback of the new release is that the subdir searching
capability has not yet been implemented in the supplied DVI drivers
DVIPS and XDVI.
This means that, in the current state, this capability can be used
in the macro search path (TEX_INPUTS), only.
In consequence, one has to rely on those VMS specific search lists
to support a TDS compliant directory structure.
Best regards
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 05:39:33 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 10:34:47 +0000 (GMT)
From: David Carlisle <carlisle@cs.man.ac.uk>
Subject: Re: Editorial comments, etc.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
> 1. unpack the existing archive (foo.tar.gz, bar.zip, or whatever)
^^^^^^^^^
The current ctan policy is that wherever possible, distributions are
stored as (sub)directories consisting of individual files. The ftpd
automagically makes up the archives on request.
Thus while making up tds archives on request does have some space/time
cost to the ctan archive machine, it need not be any worse than the
current process of making up ..tar or .zip archives on demand.
I would have thought it would have been sufficient if a package on
ctan had at its top level a file, say install.tds, that just listed the
full tds path name for each file in the distribution in some agreed format.
the ctan ftp could then make an archive based on that tree instead of
the `native' distribution tree.
This feature of ctan of storing individual files has proved very
successful and I would not like to see the TDS leading to a ctan
populated with zip files.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 06:25:07 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 06:12:43 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: Editorial comments, etc.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503091034.AA19661@r8.cs.man.ac.uk>
On 9 March 1995 at 10:34:47, David Carlisle wrote:
>
> > 1. unpack the existing archive (foo.tar.gz, bar.zip, or whatever)
> ^^^^^^^^^
>
> The current ctan policy is that wherever possible, distributions are
> stored as (sub)directories consisting of individual files. The ftpd
> automagically makes up the archives on request.
>
> Thus while making up tds archives on request does have some space/time
> cost to the ctan archive machine, it need not be any worse than the
> current process of making up ..tar or .zip archives on demand.
>
> I would have thought it would have been sufficient if a package on
> ctan had at its top level a file, say install.tds, that just listed the
> full tds path name for each file in the distribution in some agreed format.
>
> the ctan ftp could then make an archive based on that tree instead of
> the `native' distribution tree.
>
> This feature of ctan of storing individual files has proved very
> successful and I would not like to see the TDS leading to a ctan
> populated with zip files.
Storing the files in an unpacked form has definitely been a good thing.
I certainly don't see the TDS encouraging another physical arrangement.
David is echoing precisely what I had in mind. I'll try to bang together
a test implementation on jasper.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 06:28:08 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 12:20:53 +0100 (MEZ)
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Subject: Directory figure (was: Re: Editorial comments, etc.)
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-type: text
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Rich wrote:
>
> I think that Joachim's directory list, although interesting, provides a
> very clear demonstration of the difference between a directory listing
> and the kind of figure I generated. Even if Joachim's list were annotated
> and put into a tidier (to my taste :-) format, it would still:
>
> 1. be too large to be comprehended as a whole
> 2. not be guaranteed to show all possible parts of the TDS tree
>
> Thus, while I have no problem with someone generating an annotated version
> of a list like Joachim's, nor with including it as an appendix to the TDS
> document, I don't see it as a substitute for my figure.
I don't know if including my list will do any good. It was not meant
for inclusion. It was meant to show (the larger part of) a current
production system that utilizes TDS. I use such maps to compare my
understanding of the TDS group's intention with reality. I thought
others might find it useful for similar purposes.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 06:54:59 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 11:46:57 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Subject: Re: Editorial comments, etc.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
re foo.tds files, i wanted to do this some years ago but couldnt work
out the details. can someone suggest how *actually* to do it? eg take
one directoyr hierarchy, zip it up, change the names? one approach is
to maintain symbolic link sets, and then tell ZIP to resolve them,
which tar can do too.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 06:55:15 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 06:48:49 -0500
From: "K. Berry" <kb@cs.umb.edu>
Subject: Re: editorial comments
Sender: owner-twg-tds@SHSU.edu
To: twg-tds@shsu.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
> and the performance of the system is essentially independent of the number
>
> Replace `essentially' with `this',
Huh? You don't mean:
and the performance of the system is this independent...
Do you mean:
and the performance of this system is essentially independent...
I meant `thus', not `this'. Sorry.
> Probably should explain ``8.3''. We know what we mean, but ...
I've added an example, as per Rich's suggestion. Good enough?
Well ... I dunno. *I* know what 8.3 means, *you* know what 8.3 means,
but will some random package designer necessarily know? They might have
never worked on anything but Unix. Or whatever. Text along the lines of `8.3
filenames (i.e., at most one `.' in the name, with at most eight
characters before the . and at most three characters after)'
would make me happier.
> 1) It's Texinfo (all regular roman), not {\TeX}info.
Really? Ok.
Yes, really. Thanks.
> For example, texmf/source/web2c and the \filename{dtx} sources ...
Check. Oh, but wait, are DTX files sources or documentation?
They're both. It's a problem. I don't have a solution.
> Additional text: This does mean \emph{only} those directories must be
> searched: texmf/tex// is a correct path for TeX inputs in a TDS tree.
Did you mean "does not mean only" or am I missing something?
Right, I meant ``does not mean only''. Sorry.
> `feasible' better than `possible', I think. Anything's *possible*.
Anything?! ;-) Check.
Anything. Even pi being 3. (See D. Hofstadter's articles :-)
> 2) we have to explain the meaning of CTAN. I wonder if a URL
> ftp::/\replaceable{CTAN}/... would be better.
A non-specific URL? Ugh. And explanation of CTAN can go in Where are all
these files?
It was just a speculation, I don't care if it's a URL or not, I care if
it's explained somewhere how people can get the files. I'm sure it is
now, in the new section, so I'll wait for the new draft and then get my
red pencil out again :-)
> 4) The path is wrong. Has to start with /tex-archive. Assuming you mean
> `CTAN' is a host name.
I don't, CTAN is a meta-thingy...
Oh. I think that will be confusing to people just glancing through.
I think it'd be more natural to say \meta{ctanhost}:/tex-archive/blah?
> There is no need to ever have GF bitmap font files in a working TeX
> installation, since PK format bitmaps store the same information in less space.
I don't think we're all in agreement on that...
I don't object to specifying the gf/ directory instead of saying ``you
don't need GF files''. But we shouldn't just omit all mention of GF's.
It's really true that there is no reason to ever store GF files, though,
which should be mentioned in the description of the gf/ directory.
> So could say `Placing dpi in front of the resolution is common practice'.
AURGH! Common practice is to place it after. Should we switch to 300dpi
since it's allowed?
It is? I thought emtex and whatever else used `dpi300', not `300dpi'?
Anyway, I don't care. We should do whatever ``common practice'' is.
> New sentence: One possible method of automation is to make the
> distribution TDS-conformant itself, so a simple recursive copy will
> install the package.
> (Or something like that.)
We've talked about this a little bit; didn't we conclude that it's not
feasible to have TDS compliant distributions? Do we really want to
recommend this?
Not feasible? I don't remember concluding that.
Not for small ``single'' (or simple :-) file-type things, but for big,
multi-file-type things ...
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 07:06:11 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 09 Mar 1995 07:04:08 -0500
From: "K. Berry" <kb@cs.umb.edu>
Subject: Re: Question re. MetaPost files
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
I guess I'd vote that "mp" is just a program from the point of view
of the TDS spec. It doesn't seem large enough, or well enough established,
to warrant special treatment yet.
I agree.
I'd say texmf/mp/ and what goes below that is whatever you want.
Why not `metapost' instead of `mp'?
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 07:04:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 08:00:00 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503091300.IAA08724@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
References: <199503091204.AA06671@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 07:04:08, K. Berry wrote:
> I guess I'd vote that "mp" is just a program from the point of view
> of the TDS spec. It doesn't seem large enough, or well enough established,
> to warrant special treatment yet.
>
> I agree.
>
> I'd say texmf/mp/ and what goes below that is whatever you want.
>
> Why not `metapost' instead of `mp'?
Much better!
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 07:34:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091330.OAA22693@spice.iti.informatik.th-darmstadt.de>
Subject: TDS on the fly (was: Re: Editorial comments, etc.)
To: TWG-TDS@SHSU.edu
Date: Thu, 9 Mar 1995 14:30:00 +0100 (MEZ)
Content-Type: text
You wrote:
>
> re foo.tds files, i wanted to do this some years ago but couldnt work
> out the details. can someone suggest how *actually* to do it? eg take
> one directoyr hierarchy, zip it up, change the names? one approach is
> to maintain symbolic link sets, and then tell ZIP to resolve them,
> which tar can do too.
I'm wondering about all your plans. How do you do construct a TDS
distribution package if the files you want to install are not part of
the distribution at all?
That is the case for almost all LaTeX bundles, for example. One has to
create the respective files one wants to install first.
I still hold to my opinion that there is a difference between a
source distribution (which we find on CTAN now) and a
plug&play-`executable'-distribution (what Rich is speaking of). In
this analogy I consider .{sty,ltx} files the `executables' of
.{dtx,doc} files.
I agree with Rich that we need the latter, too. (I even prepared --
and support -- 62 of preliminary versions of such distribution
packages already.) CTAN would be a good place to store definitive
versions of such packages if we arrive at some conclusion of their
structure. I don't agree with Norm that it's feasible (not to speak
of easy) to transform source distribution into the executable
distributions. This opinion comes from my experience in creating and
maintaining my packages. Thomas Esser might report similar things. I
would love to be proven wrong -- it's a lot of work that is spend
here and at least I could invest that in other (better?) places.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 08:06:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 14:59:46 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503091359.AA03607@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: Question re. MetaPost files
Norm wrote:
> On 9 March 1995 at 07:04:08, K. Berry wrote:
> > I guess I'd vote that "mp" is just a program from the point of view
> > of the TDS spec. It doesn't seem large enough, or well enough established,
> > to warrant special treatment yet.
> >
> > I agree.
> >
> > I'd say texmf/mp/ and what goes below that is whatever you want.
> >
> > Why not `metapost' instead of `mp'?
>
> Much better!
Well, in that case I might ask: Why not `metafont' instead of `mf'?
Seriously though: I see Metafont and MetaPost as two companion programs
that deserve similar treatment, especially since they much of the source
code. MetaPost might not yet be well enough established (which in part
is due to the fact that its distribution was restricted in the past),
but this will hopefully change in the future.
Furthermore, MetaPost can operate in a Metafont-compatible way and
searches the MFINPUTS path as well as the MPINPUTS path if it is given
a file with the extension .mf instead of .mp. And then the MetaPost
binary is called `mp' (or `inimp'/`virmp'if you prefer that), so the
name `mp' for the MetaPost macro directory seems well justified,
don't you think.
Cheers,
Ulrik.
P.S. Two administrativa:
(1) As I'm not yet on the mailing list, I didn't get any replies to
my posting, which is what I would have expected. So I had to pull
the latest version of the archive to see what's going on.
(2) There seems to be a problem with the mailing list archive on
gopher://niord.shsu.edu. When there approx. 160 KB yesterday, there
were only 2 KB for the current file this morning. It appears as if
a new archive file was started today without saving the previously
accumulated material elsewhere, so everything from the last 8 days
has disappeared. Could anyone fix that please?
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 09:27:29 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091523.QAA19444@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Question re. MetaPost files
To: TWG-TDS@SHSU.edu
Date: Thu, 9 Mar 1995 16:23:04 +0100 (MEZ)
Content-Type: text
Ulrik wrote:
>
> > > Why not `metapost' instead of `mp'?
> >
> > Much better!
>
> Well, in that case I might ask: Why not `metafont' instead of `mf'?
(IMHO)
Because there is already an established convention of using mf/?
metafont/ would be much better, but many folks would be reluctant to
switch. We shouldn't repeat the same mistake.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:01:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 10:57:21 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503091557.KAA17928@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: TDS by FTP
Reply-To: TWG-TDS@SHSU.edu
As David noted, I threatened an implementation. You can try it out
in
/private/twg-tds/martian
Go to /private/twg-tds and "get martian.tds".
The current implementation does have a fair amount of overhead (it copies
the files rather than building links), so don't bang on it too hard.
The hardest part was getting static versions of everything I needed and
making sure that the stuff in perl wasn't "tainted". It should be a single
perl script, I broke it into two pieces before I discovered the tainting
problem.
FYI, here are the scripts
-%< tdszip %>---------------------------------------------------------------
#!/bin/sh
# We need a place to store temporary files. There is no /tmp
# so use the publicly-writable /incoming directory
TEMPROOT=/pub/temp
TEMPDIR=tdszip.$$
/bin/tdszip.pl $1 $TEMPROOT $TEMPDIR 2>&1
ZIPFILE=$TEMPROOT/zip.$$
ERRFILE=$TEMPROOT/zip.err.$$
trap "rm -rf $TEMPROOT/$TEMPDIR $ZIPFILE $ERRFILE; exit" 0 1 2 15
cd $TEMPROOT
cd $TEMPDIR
/bin/zip -q -r $ZIPFILE texmf > $ERRFILE 2>&1
# Send the zip file to stdout.
cat $ZIPFILE
-%< tdszip %>---------------------------------------------------------------
-%< tdszip.pl %>------------------------------------------------------------
#!/bin/perl -- # -*- Perl -*-
#
$get = shift @ARGV;
$insecureTEMPROOT = shift @ARGV;
$insecureTEMPDIR = shift @ARGV;
$TEMPROOT = $1 if $insecureTEMPROOT =~ /^(.*)$/;
$TEMPDIR = $1 if $insecureTEMPDIR =~ /^(.*)$/;
if (!open (F, "$get/install.tds")) {
print "$get does not include \"install.tds\" which is required\n";
exit 1;
}
%TDS = ();
while (<F>) {
chop;
next if /^\s*\;/;
next if /^\s*\#/;
next if !/(\S+)\s+(.+)$/;
$sourcefile = $1;
next if -d "$get/$sourcefile"; # You can't point to directories!
next if ! -f "$get/$sourcefile"; # You have to point to existing files!
$tdsfiles = $2;
@tdsfiles = split(/,\s*/, $tdsfiles);
foreach $tdsfile (@tdsfiles) {
next if $tdsfile !~ /^texmf\//;
$TDS{$tdsfile} = "$get/$sourcefile";
}
}
close (F);
if (!mkdir("$TEMPROOT/$TEMPDIR", 0777)) {
print "Cannot create $TEMPROOT/$TEMPDIR\n";
exit 1;
}
foreach $file (keys %TDS) {
my(@path) = split(/\//, "$TEMPROOT/$TEMPDIR/$file");
my($path, $bytes);
local(*F, $_);
pop(@path); # Pop the filename off the end
$path = "";
while (@path) {
$_ = shift @path;
next if /^\s*$/;
$path .= "/$_";
if (! -d $path) {
mkdir ($path, 0777) if ! -d $path;
}
}
open (F, $TDS{$file});
open (G, ">$TEMPROOT/$TEMPDIR/$file");
$bytes = read(F, $_, 1024);
while ($bytes > 0) {
print G $_;
$bytes = read(F, $_, 1024);
}
close (F);
close (G);
}
exit 0;
-%< tdszip.pl %>------------------------------------------------------------
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:26:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 11:18:40 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091618.AA08511@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu, vieth@xerxes.thphy.uni-duesseldorf.de
Subject: Re: Question re. MetaPost files
Well, in that case I might ask: Why not `metafont' instead of `mf'?
Seriously though: I see Metafont and MetaPost as two companion programs
that deserve similar treatment, especially since they much of the source
code. MetaPost might not yet be well enough established (which in part
is due to the fact that its distribution was restricted in the past),
but this will hopefully change in the future.
Hmm. Yes, I guess the only counter-argument is historical -- ``everyone
knows'' what mf means, and mf has been used for the top level directory
name for metafont-stuff for ages. I don't see any compelling reason to
change it, though I don't particularly object to doing so, either.
None of that is true for metapost, and I think a spelled-out name is
generally preferable where possible, to avoid confusion. (multiprecision
math? what does that have to do with tex?) So I would still argue that
metapost is the ``right'' name for metapost. If the sense of the
committee is that that implies we should use ``metafont'', not ``mf'',
that's ok with me. I don't mind the inconsistency, though.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:33:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 11:33:42 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091633.AA08600@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
I think that Joachim's directory list, although interesting, provides a
very clear demonstration of the difference between a directory listing
and the kind of figure I generated. Even if Joachim's list were annotated
I think a figure like Rich's is the right thing for tdsguide.tex.
I withdraw my suggestion that the example be a complete tree.
It would probably still be useful to have a separate file in the tds
directory with the complete listing.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:36:35 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on the fly (was: Re: Editorial comments, etc.)
Date: Thu, 09 Mar 1995 16:03:19 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:036790:950309160344"@cl.cam.ac.uk>
>
> I'm wondering about all your plans. How do you do construct a TDS
> distribution package if the files you want to install are not part of
> the distribution at all?
yup. thats the sticking point. it becomes a shell script job, and
you have to make authors supply a makefile, etc etc....
> maintaining my packages. Thomas Esser might report similar things. I
> would love to be proven wrong -- it's a lot of work that is spend
> here and at least I could invest that in other (better?) places.
my experiences over the years are equally negative, if it helps
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:53:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 17:46:41 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503091646.AA03869@thphy.uni-duesseldorf.de>
To: kb@cs.umb.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
Karl wrote:
> Hmm. Yes, I guess the only counter-argument is historical -- ``everyone
> knows'' what mf means, and mf has been used for the top level directory
> name for metafont-stuff for ages. I don't see any compelling reason to
> change it, though I don't particularly object to doing so, either.
> None of that is true for metapost, and I think a spelled-out name is
> generally preferable where possible, to avoid confusion. (multiprecision
> math? what does that have to do with tex?) So I would still argue that
> metapost is the ``right'' name for metapost. If the sense of the
> committee is that that implies we should use ``metafont'', not ``mf'',
> that's ok with me. I don't mind the inconsistency, though.
Well, if historical reasons are the only argument, why not change `mf'
to `metafont' as well? After all, this TDS is meant to introduce
something new anyway, so why do we have to keep the old name then?
In any case, I'd prefer consistency over historical arguments, so why
not let's have texmf/metafont and texmf/metapost.
Cheers,
Ulrik.
P.S. We are lucky, though, that both DEK and John Hobby have chosen
names with exactly 8 letters...
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:55:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 11:55:24 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091655.AA08800@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
texmf/tex/plain/ams is amstex because it's for plain
Say what? amstex is a format, hence I thought it was:
texmf/tex/amstex
Or are you talking about something else?
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 10:56:58 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
Date: Thu, 09 Mar 1995 16:41:29 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:058050:950309164202"@cl.cam.ac.uk>
re MetaPost, surely we dont want to perpetuate the "lib" Unix
anonymousness. i'd say
metapost/troff
would be a nice logical place to put the troff support files...
and i agree with Ulrike that MP should be taken seriously. after all,
Knuth uses it, so that makes it canonical :-} [1]
sebastian
[1] and he even altered the logo.mf file to include the extra letters
so that he could write MP properly. what more do you want?
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 11:32:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 17:32:48 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950309173248.224156c9@vms.rhbnc.ac.uk>
Subject: Re: Question re. MetaPost files
There's been a lot of sensible discussion on this list of late, and I'm
particularly pleased to see Sebastian eschew the terse nomenclature of Unix,
but I do feel that one of Karl's more recent messages was a little bit
sweeping:
>> Hmm. Yes, I guess the only counter-argument is historical -- ``everyone
>> knows'' what mf means, and mf has been used for the top level directory
>> name for metafont-stuff for ages.
Surely only on some systems? The very systems which Sebastian rightly
(IMHO) suggests we eschew. The MetaFont hierarchy here starts at [.MetaFont],
and I'm sure the same is true for many other sites which have chosen right from
the outset to eschew the terseness of Unix nomenclature... So if there is
still sufficient flexibility in the TDS glue to reset MF as MetaFont, I'd
suggest going for it...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 11:43:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091743.SAA15796@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Question re. MetaPost files
To: TWG-TDS@SHSU.edu
Date: Thu, 9 Mar 1995 18:43:38 +0100 (MEZ)
Content-Type: text
Phil wrote:
>
> >> Hmm. Yes, I guess the only counter-argument is historical -- ``everyone
> >> knows'' what mf means, and mf has been used for the top level directory
> >> name for metafont-stuff for ages.
>
> Surely only on some systems? The very systems which Sebastian rightly
> (IMHO) suggests we eschew. The MetaFont hierarchy here starts at [.MetaFont],
I have worked with about 15 different TeX installations in the past 14
years; I think your installation is an exception.
I am in favor of the change, btw. The only other argument I've heard
(off-line) was from a DOS guy who was mumbling `restricted
environment place' or something similar. (To be honest, I don't care
about these kind of DOS restrictions that can be changed in a startup
file.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 11:48:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 17:48:24 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503091748.AA08385@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on the fly (was: Re: Editorial comments, etc.)
Ah, so Sebastian was quoting Joachim (I suspected as much:-).
I agree with Rich that we need the latter, too. (I even prepared --
and support -- 62 of preliminary versions of such distribution
packages already.) CTAN would be a good place to store definitive
versions of such packages if we arrive at some conclusion of their
structure.
Trouble with ctan storing the `tds-plug-and-play' versions
of things is that ctan gets to be twice as big...
On the other hand, ctan already has tar/zip files consisting of
input and font trees: emtex/*/*.zip, web2c's lib.tar, Linux
distributions etc.
If all these OS specific distributions could be cut down to just the
OS-dependant executables, that would free up a lot of space for a fair
number of archives of tds-ready packages, or even a largeish tds.zip
archive making a basic tds tree of plain+latex+basic cm and adobe fonts+...
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 11:53:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 17:14:45 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503091714.AA08370@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on the fly (was: Re: Editorial comments, etc.)
Sebastian, quoting some message I haven't got (yet?)
??>
??> I'm wondering about all your plans. How do you do construct a TDS
??> distribution package if the files you want to install are not part of
??> the distribution at all?
> yup. thats the sticking point. it becomes a shell script job, and
> you have to make authors supply a makefile, etc etc....
Er, well yes. The most I envisioned was moving the files around to a
different tree. If files need to be generated (the famous dtx
example:-) then I don't think it would be very reliable to generate
them at the ftp server, especially if that is a different architecture
from the target machine. However in some cases it could be useful to
generate the tds-zip, for example the latex `unpacked' directory could
be distributed around the tds just leaving the installer to run
initex on latex.ltx to generate the format, and move the fmt file to
the appropriate place.
Or perhaps we should stick with the current plan of asking people to
read the documentation to find out where to put everything, and give
up on the automated idea, if too few packages could use it....
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 12:09:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 12:53:47 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503091753.MAA04842@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Changing directory names
References: <950309173248.224156c9@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
I think there's sufficient support for changing the 'mf' directory to
'metafont'. I vote we go for it.
And since we're changing names, does anyone want to consider changing
the PK DPI directories back to '300dpi' (instead of dpi300) since
apparently that is acceptable on an ISO-9660 disk?
And, I assume that we're all still happy with 'texmf' as the root ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 12:38:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 18:06:40 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950309180640.224156c9@vms.rhbnc.ac.uk>
Subject: Re: Question re. MetaPost files
Joachim:
>> I have worked with about 15 different TeX installations in the past 14
>> years; I think your installation is an exception.
And how many of those fifteen were Unix or close emulations thereof?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 13:10:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 19:10:17 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950309191017.2241a2a0@vms.rhbnc.ac.uk>
Subject: RE: Changing directory names
>> And since we're changing names, does anyone want to consider changing
>> the PK DPI directories back to '300dpi' (instead of dpi300) since
>> apparently that is acceptable on an ISO-9660 disk?
The DPI... convention is hard-wired into some of the drivers which
are still in use here... On the NFS-served system I have [...300]
as an alias for [...DPI300], but I cannot eliminate DPI... completely.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 13:30:56 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 9 Mar 1995 11:31:17 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091931.LAA23459@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
I'm virtually certtain that on our old Tops20 installation the
local directory was .MF, and if there was ever a system free of
inhibiting name-length constraints it was Tops20. On DEK's
SAIL machine, .METAFONT would have been impossible, I suspect
It ain't just Unix.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 13:38:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 9 Mar 1995 11:39:20 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091939.LAA24332@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Changing directory names
I think there's sufficient support for changing the 'mf' directory to
'metafont'. I vote we go for it.
Not much harm in that. Symbolic links will save those of us whose
fingers type mf unbidden as soon as the image springs to mind.
And since we're changing names, does anyone want to consider changing
the PK DPI directories back to '300dpi' (instead of dpi300) since
apparently that is acceptable on an ISO-9660 disk?
Please, no! It's bad enough to have had the job of setting up aoo
this dpi300 stuff in the first place. Legs is legs, and you needn't
alter 'em. Besides, the fact that all those awful dpi000 directories
begin with the same letter sequence can sometimes be useful.
And, I assume that we're all still happy with 'texmf' as the root ;-)
The western Locrians used to have a method of dealing with politicians
who suggested that sort of constitutional amendment. He had to announce
it with a noose around his neck, and if the assembly didn't like the
amendment, they took hold and pulled. Come to think of it . . .
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 13:56:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503091955.UAA22750@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Question re. MetaPost files
To: TWG-TDS@SHSU.edu
Date: Thu, 9 Mar 1995 20:55:37 +0100 (MEZ)
Content-Type: text
[Since this rhetoric question was placed in public, I'd like to answer
publically.]
Phil wrote:
>
> Joachim:
>
> >> I have worked with about 15 different TeX installations in the past 14
> >> years; I think your installation is an exception.
>
> And how many of those fifteen were Unix or close emulations thereof?
2.
I thought I did express myself clear enough, but did not succeed
obviously: I'm not talking of platforms, I'm talking of *different*
TeX _installations_. I.e., all web2c installations are the same and
count only as one installation.
Sincerely,
Joachim
PS: My TeX experience is by far longer than my Unix experience. You
should not forget that we were the third site in Germany that started
to use TeX, back in 1981. E.g., when we did our first Unix port, no
web2c was available. Btw, we also did the first BS2000 port and the
first Atari port world-wide.
PPS: Just in case your question isn't pure rethoric, but you're
really interested (roughly in the order I used them): Siemens BS
2000: ITI TeX, GMD TeX; MVS TeX; VM/CMS TeX; VMS: DECUS TeX; Atari
ST: stTex, ST-TeX, Multi TeX; Amiga: AmigaTeX, PasTeX; DOS PC: PC
TeX, PublicTeX, emTeX, gTeX (but that does not count because it's
web2c); Unix: ITI TeX, web2c TeX. With the exception of the
mainframes, I still have most of those systems available, btw. With
some of them I earned my living during my studies, selling plug&play
TeX distributions. I may be arrogant, but I think I know what I'm
talking about.
PPPS: OK, Phil, that's my background. How many *different* TeX
installations have _you_ worked with, how many have you created and
distributed to thousands of sites & actively supported via phone
hot-line? I.e., what are the systems where [.metafont] is a commonly
used directory name? (Like you, I ignore here the fact that I have
already expressed twice my support for that name change.)
I hate to be called Unix-centric, in particular if it's meant as a
derogative comment about narrow-mindedness. I won't say the same from
you either, so please stop it.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 13:58:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 09 Mar 1995 13:57:15 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <794775435.809048.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
regarding "mf" vs "metafont", joachim stated:
I have worked with about 15 different TeX installations in the past 14
years; I think your installation is an exception.
and phil asked joachim:
And how many of those fifteen were Unix or close emulations thereof?
to butt in, i have just checked the dumper log i kept of the
final tex tree at score, the stanford machine from which the tex
system propagated, and which was the model upon which we based
our installation at ams. this dumper was made on 25 aug 89; the
structure had been reasonably stable since its inception in 1979.
the principal metafont directory was ps:<tex.mf> ; the string
"metafont" does not appear even once in the file.
this is not to be taken as opposition to naming that area "metafont"
in the tds. if the purpose is to be clear to newbies, then the
full name is certainly less obscure.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 14:35:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 12:35:55 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503092035.AA00897@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Editorial comments, etc.
Before I begin, I would like to share last night's fortune cookie message:
People find it difficult to resist your persuasive manner.
So much for oracles... (:-)
==========================================================================
David Carlisle makes an excellent point: files which are not stored in
archives on the CTAN need not be unpacked. On the other hand, I think
I've seen a fair number of archived files on the CTAN, so the question of
unpacking is not entirely moot.
I applaud Norm's submission of a packing script. If the CTAN site is
UNIX-based, the efficiency of the script can be improved dramatically by
creating hard links rather than creating and filling files. This has a
couple of other ramifications, like the fact that the input and scratch
trees must share a file system, but I think the efficiency improvements
would make this worthwhile. Norm, could you document the format of the
control file, possibly including desirable (but not yet implemented)
bells and whistles like wild-carding, etc?
More critically, Joachim brings up the fact that many of the distributions
on the CTAN are not complete "drop-in" sets of files, regardless of their
organization. Can some TeXnocrat summarize the degree of pre-processing
we're looking at? (I'm afraid I'm totally out of my depth here!)
David claims "Trouble with ctan storing the `tds-plug-and-play' versions
of things is that ctan gets to be twice as big...". This may be true if
we insist on storing the drop-in forms in unpacked, uncompressed form. I
see *no* reason to do this, however. If I want a drop-in distribution, I
want to pick it up as a single entity, go to the top of my texmf tree, and
unpack it. Besides, disk space is getting cheaper all the time. If this
is a limiting consideration, I suggest that PTF and a few other companies
that make money off of TeX chip in to help CTAN buy some new disk drives.
David is right on the mark in speaking about the current distributions.
By re-forming them into TDS-compliant form and breaking out the portable
files into "drop-ins", I think we can achieve savings in both space AND
maintenance headaches.
By the way, it is my opinion that any difficulty predicted or encountered
regarding conversion of CTAN-style distributions to "drop-in" form makes a
strong argument FOR an organized mechanism for conversion. I mean, if the
Tex elite can't make things work, how are random TeXnoweenies like myself
supposed to succeed?
If TeX is to maintain and increase its base of users, the current raft of
installation and maintenance problems *have* to get handled in a way that
does not require users to RTFM for each new package. LaTeX2e and the TDS
are big moves in the right direction; let's not quit now!
-Rich
P.S. Actually, I'm quite happy with the responses this topic has received,
so I guess the cookie might not have been too wrong, after all.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 14:43:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 12:43:41 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503092043.AA00924@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: A different perspective on distribution problems
Forgive me if this is too far off the subject, but I thought most of you
would enjoy this.
-r
----- Begin Included Message -----
: : What's the concensus on the AT&T connectors as opposed to coax? I've
: : heard all the Toslink-bashing, but it seems that AT&T would be fairly
: : serious about good fiber connections.
: Quite obviously, coax is the *IDEAL* medium for digital transmission
: because it provides essentially *perfect* rejection of any spurious
: non-digital signals.
: When the size of the coax cable is properly matched to the font of
: the digital source, 1's flow (lengthwise) down the center conductor
: while 0's pass (broadside) down the shield -- and NO other numbers
: can get through.
: Unfortunately, many low-cost A/D converters and CD transports save
: money by using cheap, public-domain fonts in which the 0's are oval
: rather than perfectly round. The resulting null-distortion causes
: unnatural (and easily recognizable) compression of the sound stage.
: This effect can be partially corrected by using specially designed
: coax with a slightly oval cross-section.
: WRT the transmission of 1's, there are two competing bodies of
: opinion. Most purists tend to favor the minimalist approach of
: using a sans serif font with a solid center conductor; however,
: some recent studies suggest that there may be real benefits to
: a twisted center conductor in combination with a slight serif
: at the base of the 1's. Apparently, the serif allows the 1's
: to engage the spiral conductor and impart a stabilizing spin --
: in much the same way that the ogive at the base of an artillery
: shell engages the rifling in the gun barrel.
: hope this helps,
: Mark
: --
: Moderators accept or reject articles based solely on the criteria posted
: in the Frequently Asked Questions. Article content is the responsibility
: of the submittor. Submit articles to ahbou-sub@acpub.duke.edu. To write
: to the moderators, send mail to ahbou-mod@acpub.duke.edu.
----- End Included Message -----
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 14:50:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 1995 15:46:02 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503092046.PAA11034@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503092035.AA00897@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 12:35:55, Rich Morin wrote:
> I applaud Norm's submission of a packing script. If the CTAN site is
> UNIX-based, the efficiency of the script can be improved dramatically by
> creating hard links rather than creating and filling files. This has a
Symbolic links would be ok, too, I think. If zip (like tar) can be
told to follow them. I think it can but I was lazy.
> would make this worthwhile. Norm, could you document the format of the
> control file, possibly including desirable (but not yet implemented)
> bells and whistles like wild-carding, etc?
The format is simple:
name1 tdsname1, tdsname2, tdsname3
name1 is the name of the file in the CTAN structure (relative to ".").
tdsname1 is the name it should have in the TDS.
tdsname2 multiple TDS names (comma separated) imply multiple *copies*
of the file. A bad idea, but useful for "README".
I haven't thought about it enough to imagine bells or whistles. It's
all SMOP from here ;-)
> More critically, Joachim brings up the fact that many of the distributions
> on the CTAN are not complete "drop-in" sets of files, regardless of their
> organization. Can some TeXnocrat summarize the degree of pre-processing
> we're looking at? (I'm afraid I'm totally out of my depth here!)
It's a stone wall, I'm afraid. The *.dtx files for LaTeX, for example,
need to be built locally so that local configuration can occur. But maybe
I'm spouting doom and gloom needlessly.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 15:06:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 09 Mar 1995 16:06:59 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
To: TWG-TDS@SHSU.edu
Message-ID: <794783219.303634.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i've got some questions about "plug&play" forms of packages.
my exposure to different operating systems is rather limited;
the number in which i am illiterate is legion. so please be
gentle with your flames.
i think it's true that a single packed, compressed form will
not be usable on all systems for which tex is now available.
true or not?
if true, then multiple versions will be needed. this gets us
back to the problem of an expanding ctan, if all possible
systems are to be supported. worse, it gets us into the problem
of how to maintain synchronized versions of any package for all
systems. (don't know about the rest of you, but the ams doesn't
have all these systems installed, and even less does it have the
expertise needed to manage all of them. and even for the several
special packages we do offer, we have enough more than trouble
maintaining synchrony and get more mail to our tech-support address
about glitches than i ever want to see.)
i think that "on-the-fly" packing of a tds-compliant package would
be wonderful, but it doesn't seem trivial.
i agree that it's necessary to streamline both installation and
use of tex and friends, but i don't see that it will ever be
possible to get rid of the "fm" for the out-of-the-mainstream
systems. (i *know* we're never going to be able to create, say,
an amstex format file for a cray!)
what am i missing?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 15:51:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 9 Mar 1995 13:51:27 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503092151.NAA09478@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: <texmf>/doc/<format>
Some clarification is requested.
The example in 9 shows a <texmf>/doc/<format>/base directory. Does this
really suggest a complete duplication of <texmf>/tex/<format>/base?
I would regard that as a pretty bad idea. The suggested duplication
<texmf>/doc/plain/martian/read.me == <texmf>/doc/latex/martian/read.me
is harmless because read.me doesn't do anything, it just sits there.
After long experience, however, I am very much against duplication
of what I presume would go in <>/base
But maybe I haven't quite understood.
As a matter of policy, is there any objection to adding preformated
designations to the possibilities in <texmf>/doc/<format> ?
The UnixTeX tape includes a certain amount of precompiled dvi and
ps documentation. For example, the three basic LaTeX2e guides are supplied
in ten-page readymade ps files (usrguide.001 usrguide.002 . . .)
in hopes that even the stingiest laser printer can print them right
off. Dvips and kpathsea are supplied the same way. It seems to me
that these should go in <texmf>/doc/ps/latex/guides and
<texmf>/doc/ps/dvips
In cases where dependence on ps seems inadvisable, <texmf>/doc/dvi/latex/guides
could be supplied.
Rationale:
The stuff in usrguide etc., or the compiled dvips.texi guide is much
too rich to be condensed into an ascii read.me, but it is often useful
to look at it BEFORE making certain decisions about local configuration
etc. This is especially true for dvi interpreters, which have to be installed
before you can really find out the details of how to install them. An
over-complicated read.me simply doesn't get read. and even with the best will
in the world it can't be formatted as effectively as a latex.dtx or
a texi file. I don't think <texmf>/doc/ps and <texmf>/doc/dvi break anything.
but they are a bit different from <texmf>/doc/latex etc.
Or is that what was intended anyway?
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 16:16:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 14:15:15 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503092215.AA00666@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
> Symbolic links would be ok, too, I think. If zip (like tar) can be
> told to follow them. I think it can but I was lazy.
There is also a storage consideration: each symlink occupies one disk
block. For large collection of files, this could be a consideration.
> i think it's true that a single packed, compressed form will
> not be usable on all systems for which tex is now available.
There are actually several questions hidden in here. I don't have the
answers to most of them, but I can open them up for inspection:
1. Assuming that we use Info-zip and a TDS-compliant name space,
all archives should unpack correctly to the desired locations.
Versions of Info-zip are available for essentially all systems.
2. If an unpacked file is ASCII, there is a possible problem with
line termination. UNIX uses LF, MacOS uses CR, MS-DOS uses
CR/LF, and somebody may actually use LF/CR. Some programs are
happy to accept all forms; others are not. My impression is that
most TeX-related software accepts all forms; is this the case?
3. If the file is binary (non-ASCII, really), the question becomes
a bit fuzzier. If the file is a machine-specific executable, no
reasonable translation will be possible. If it is "just" a data
file, and its format is defined in terms of a specific byte order,
it should be portable without problems. Aren't most TeX-related
files defined in this manner?
4. Any file that must be localized to the site that uses it is a real
problem. How much of this exists, and is it really necesary?
-Rich
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 16:41:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 09 Mar 1995 17:41:03 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
To: TWG-TDS@SHSU.edu
Message-ID: <794788863.415633.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
rich has expanded my question about whether a single packed,
compressed format is universally acceptable. (thanks.)
i have an answer to one of his resulting questions:
2. If an unpacked file is ASCII, there is a possible problem with
line termination. UNIX uses LF, MacOS uses CR, MS-DOS uses
CR/LF, and somebody may actually use LF/CR. Some programs are
happy to accept all forms; others are not. My impression is that
most TeX-related software accepts all forms; is this the case?
i think that not all tex-related software by any means accepts
all forms. there are numerous inquiries to comp.text.tex that
complain about overflow of an input buffer (ask your local wizard
to enlarge me). most often this is the result of an end-of-line
code mismatch. so, empirically, the various permutations of cr
and lf are not universally supported at present. but i don't
know which tex implementations are involved.
also a contribution to an answer for another:
3. If the file is binary (non-ASCII, really), the question becomes
a bit fuzzier. If the file is a machine-specific executable, no
reasonable translation will be possible. If it is "just" a data
file, and its format is defined in terms of a specific byte order,
it should be portable without problems. Aren't most TeX-related
files defined in this manner?
font files are binary. on vms machines, they are required to have
fixed-length records; no such requirement under unix. i believe
that .tfm and .pxl files created for vms can be used under unix
conditions, but definitely not vice versa, at least not without
repackaging (for which the software is readily available).
and then there are the emtex font libraries and the textures font
suitcases ... (i'm not an emtex user, and don't know whether
non-packaged .tfm files can also be used. i do know that at ams we
have to package font files differently for textures, because oztex
users keep picking them up 'cause they say "mac" and wondering why
they aren't able to use them.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Mar 1995 17:55:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Mar 95 15:55:54 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503092355.AA01095@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Help?
Guise-
In all the books I've seen on TeX, I've never seen a rundown of the myriad
file types used by TeX-related programs. If someone could point me to a
FAQ or somesuch that explains all (most? some?) of them, I'd be *very*
grateful. Ultimately, I'd like to have a set of notes that explains, for
each file type:
1. purpose - what's it for?
2. origin - how it is created?
3. format - binary, ASCII, machine-specific, etc.
If there is no such list around at present, I'd be happy to start one. It
appears that extensions are generally good clues: could some of you run the
script below over a reasonably large TeX installation, generating a list of
extensions? Email the list(s) to me; I'll collate them and start bugging
folks for explanations (:-).
-Rich
===========================================================================
:
# fee - find examples of extensions, writes list to stdout and fee.out
#
# NB - uses new awk!
#
# Usage: fee <directory> ...
#
# Written by Rich Morin, 1995, Public Domain
for dir in $*; do
du -a $dir |
nawk '
{
ext = $2
sub(/^.*\//, "", ext)
sub(/^.*\./, ".", ext)
if (ext ~ /^\./)
printf("%-10s %s\n", ext, $2)
}
'
done |
sort |
nawk '
{
counts[$1]++
if (counts[$1] == 1)
examples[$1] = $2
}
END {
for (ext in counts)
printf("%-10s %5d %s\n", ext, counts[ext], examples[ext])
}
' |
sort |
tee fee.out
===========================================================================
FYI, here is the list for my (pitiful) texmf tree:
.1037pk 2 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.1037pk
.1244pk 4 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.1244pk
.1493pk 2 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.1493pk
.2 1 /usr/local/lib/texmf/VERSION-6.2
.600pk 35 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.600pk
.657pk 5 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.657pk
.720pk 4 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.720pk
.864pk 6 /usr/local/lib/texmf/fonts/tmp/pk/ljfour/cmbx10.864pk
.afm 12 /usr/local/lib/texmf/fonts/adobe/utopia/afm/putb.afm
.aux 3 /usr/local/lib/texmf/tex/latex/base/sample.aux
.awk 2 /usr/local/lib/texmf/tex/tugboat/kwic-bib.awk
.base 3 /usr/local/lib/texmf/ini/cmmf.base
.bbl 1 /usr/local/lib/texmf/bibtex/doc/btxdoc.bbl
.bib 26 /usr/local/lib/texmf/bibtex/bib/asi.bib
.bst 8 /usr/local/lib/texmf/bibtex/bst/abbrv.bst
.bug 2 /usr/local/lib/texmf/tex/pstricks.d/beta/pst-beta.bug
.cache 1 /usr/local/lib/texmf/tex/pstricks.d/.cache
.cache+ 1 /usr/local/lib/texmf/tex/pstricks.d/.cache+
.chg 1 /usr/local/lib/texmf/tex/tugboat/tugfil.chg
.cmn 1 /usr/local/lib/texmf/tex/tugboat/tugboat.cmn
.con 1 /usr/local/lib/texmf/tex/pstricks/pstricks.con
.d 1 /usr/local/lib/texmf/tex/pstricks.d
.d20 1 /usr/local/lib/texmf/tex/tugboat/makefile.d20
.dat 1 /usr/local/lib/texmf/tex/pstricks.d/doc/filetest.dat
.def 4 /usr/local/lib/texmf/tex/ams/amssym.def
.doc 7 /usr/local/lib/texmf/bibtex/doc/btxbst.doc
.dvi 3 /usr/local/lib/texmf/tex/latex/base/sample.dvi
.fmt 3 /usr/local/lib/texmf/ini/latex.fmt
.ind 1 /usr/local/lib/texmf/tex/pstricks.d/src/pst-user.ind
.ini 1 /usr/local/lib/texmf/tex/ams/amstex.ini
.log 3 /usr/local/lib/texmf/tex/latex/base/sample.log
.ltx 3 /usr/local/lib/texmf/tex/tugboat/kwic.ltx
.map 2 /usr/local/lib/texmf/dvips/psfonts.map
.mf 329 /usr/local/lib/texmf/fonts/ams/cyrillic/src/cyrcsc.mf
.mft 3 /usr/local/lib/texmf/tex/mft/cmbase.mft
.mirror 1 /usr/local/lib/texmf/tex/pstricks.d/.mirror
.pfa 8 /usr/local/lib/texmf/fonts/adobe/utopia/type1/putb.pfa
.pfb 4 /usr/local/lib/texmf/fonts/bitstream/charter/type1/bchb.pfb
.pool 2 /usr/local/lib/texmf/ini/mf.pool
.pro 18 /usr/local/lib/texmf/dvips/color.pro
.ps 9 /usr/local/lib/texmf/dvips/config.ps
.pst 2 /usr/local/lib/texmf/tex/pstricks.d/read-me.pst
.raw 1 /usr/local/lib/texmf/tex/pstricks.d/doc/filetest.raw
.readme 1 /usr/local/lib/texmf/tex/pstricks.d/beta/pstree.readme
.sh 2 /usr/local/lib/texmf/tex/pstricks.d/contrib/pie-data.sh
.sty 63 /usr/local/lib/texmf/tex/ams/amsppt.sty
.tar 1 /usr/local/lib/texmf/fonts/adobe/courier/courier.tar
.tex 86 /usr/local/lib/texmf/bibtex/doc/btxdoc.tex
.tfm 341 /usr/local/lib/texmf/fonts/adobe/avantgarde/tfm/pagd.tfm
.tug 1 /usr/local/lib/texmf/tex/tugboat/00readme.tug
.txt 1 /usr/local/lib/texmf/tex/tugboat/00readme.txt
.unx 1 /usr/local/lib/texmf/tex/tugboat/makefile.unx
.vf 67 /usr/local/lib/texmf/fonts/adobe/avantgarde/vf/pagd.vf
.xua 1 /usr/local/lib/texmf/bibtex/doc/btxdoc.xua
.zipped 7 /usr/local/lib/texmf/tex/pstricks.d/.zipped
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 02:46:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 09:47:34 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Help?
To: TWG-TDS@SHSU.edu
Message-ID: <01HNYT0AJ3JM9865GH@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
The VMS TeX help contains (for a long time now) a topic ``TeX_File_Types'',
where the traditional types are explained (LateX2e has introduced new
endings). If I remember right, the VMS help library is also available as
an info file for gnu's texinfo.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 03:55:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 10:21:45 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503100921.AA04214@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: Question re. MetaPost files
Sebastian wrote:
> re MetaPost, surely we dont want to perpetuate the "lib" Unix
> anonymousness. i'd say
> metapost/troff
> would be a nice logical place to put the troff support files...
Sounds reasonable, but what about something more generic such as
metapost/support
instead? Just consider the case that your troff ist actually groff.
Do you still want to call the directory `troff' then? Probably not.
I think I'll like `metapost/support'. Is that fine with you?
When this is settled the question remains whether we need an additional
functional level below `metapost' to distinguish between support files
and MetaPost macros, before we get to subdirectories for `base' and
possibly other packages. If so, what to call the macros directory?
Should it be `macros' or `inputs' or what? There's no easy answer
to that, I'm afraid. I would like to avoid this by treating `support'
as a reserved package name, resulting in a tree like this
texmf
. metapost
. . base basic MetaPost distribution (e.g. plain.mp)
. . <package> contributed packages (future extensions)
. . support g/troff support files for MetaPost processor
However, this might lead to unnecessary subdirectory searching in the
`support' subdirectory, so maybe we do need a `macros' level, such as
texmf
. metapost
. . macros MetaPost macros (*.mp files)
. . . base basic MetaPost distribution (e.g. plain.mp)
. . . <package> contributed packages (future extensions)
. . support g/troff support files for MetaPost processor
Finally, I remember that there might be some other non-font MetaFont
packages around for drawing labeled figures similar to MetaPost.
Considering that, I think it would be too short-sighted to have only
a flat level below `metafont' without a place to install those packages.
So what about having a similar structure below `metafont' as well?
texmf
. metafont
. . base basic non-font MF files (e.g. plain.mf, modes.mf)
. . <package> other non-font packages (e.g. for drawing figures)
Just another idea that may have been overlooked so far.
> and i agree with Ulrike that MP should be taken seriously. after all,
> Knuth uses it, so that makes it canonical :-} [1]
Right! I'm glad you mention this. In fact, as I recall he is quite
enthusiastic about how much he enjoys using MetaPost.
> [1] and he even altered the logo.mf file to include the extra letters
> so that he could write MP properly. what more do you want?
Yes, and there's a 2e package that already had the MP logo before MetaPost
became publically available. (The next release of that package will
have conforming 8.3 file names, I promise, and it'll easily unpack
into the texmf tree, I hope.)
Cheers,
Ulrik.
Notes:
[1] Concerning Knuth's feelings about MetaPost: Have a look at
http://www.clbooks.com/nbb/knuth.html (Interview with DEK),
if you haven't done so already. I also keep a local copy at
http://xerxes.thphy.uni-duesseldorf.de/~vieth/tex/knuth.html.
[2] Concerning groff: Does anyone know if it has been ported to DOS,
VMS or other non-Unix platforms? If so, it would be good to have
it for people wishing to use MetaPost troff mode. One needs to
have a troff capable of handling PostScript fonts anyhow, and
I guess groff might behave more or less the same across platforms,
whereas this might not be true for all the other troff variants.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:25:22 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
Date: Fri, 10 Mar 1995 10:37:27 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:207640:950310103808"@cl.cam.ac.uk>
if changing "mf" to "metafont" means we get Phil's name and authority
back on the TDS report, then its a small price to pay :-}
curiously, i support this suggestion. metafont even has 8 letters,
which has to be a good omen
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:25:32 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Changing directory names
Date: Fri, 10 Mar 1995 10:48:51 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:212500:950310104934"@cl.cam.ac.uk>
i've had dpi300 for years now, and there must have been some
reason. can everyone swear that directories starting with numbers are
ok on all OSes? atari, acorn, eg? mvs?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:26:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
Date: Fri, 10 Mar 1995 11:09:53 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:224680:950310111406"@cl.cam.ac.uk>
dont forget that some unpacking of .dtx files asks questions, which
have meaningful answers. eg the AMS stuff asks if you have MF-based of
Type1-based fonts. the PSNFSS stuff (currently, sigh) needs to knwo if
you are on a Mac or not.
i dont think we should let this discussion hold up release of the TDS
draft for discussion
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:27:29 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
Date: Fri, 10 Mar 1995 11:15:49 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:226810:950310111814"@cl.cam.ac.uk>
> 2. If an unpacked file is ASCII, there is a possible problem with
> line termination. UNIX uses LF, MacOS uses CR, MS-DOS uses
> CR/LF, and somebody may actually use LF/CR. Some programs are
> happy to accept all forms; others are not. My impression is that
> most TeX-related software accepts all forms; is this the case?
no, definitely not. OzTeX for Mac cant use Unix files straight
off. but most unzippers include an option for converting, no?
> 3. If the file is binary (non-ASCII, really), the question becomes
> a bit fuzzier. If the file is a machine-specific executable, no
> reasonable translation will be possible. If it is "just" a data
> file, and its format is defined in terms of a specific byte order,
> it should be portable without problems. Aren't most TeX-related
> files defined in this manner?
i havent met an exception since the bad old days of VMS TeX systems
which bunged tfm files into fixed size chunks or something. but i
think Phil will reassure us this is no longer true
> 4. Any file that must be localized to the site that uses it is a real
> problem. How much of this exists, and is it really necesary?
i dont think there will be that many...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:27:40 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Help?
Date: Fri, 10 Mar 1995 11:18:13 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:227570:950310111922"@cl.cam.ac.uk>
surely our esteemed chair's book has what Rich needs? its where i'd
point people for answers to questions about what files do what
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:29:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 06:24:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101124.GAA02185@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Help?
References: <9503092355.AA01095@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 15:55:54, Rich Morin wrote:
> In all the books I've seen on TeX, I've never seen a rundown of the myriad
> file types used by TeX-related programs. If someone could point me to a
> FAQ or somesuch that explains all (most? some?) of them, I'd be *very*
> grateful. Ultimately, I'd like to have a set of notes that explains, for
> each file type:
Um, have you looked at app A of my book? ;-) Here's a grep:
\extitem [abf] An Adobe binary screen font file contains a binary encoding
\extitem [afm] Adobe font metrics files are ASCII files distributed with
\extitem [aux] Auxiliary files are built by \LaTeX\ each time it formats
\extitem [bbl] Bibliography files are created by \BibTeX\ from the citations in
\extitem [bdf] Bitmap distribution format files are ASCII files that describe
\extitem [bib] Bibliography databases contain bibliographic information.
\extitem [blg] \BibTeX\ log files record the status of the last run of
\extitem [bst] Bibliography style files are used by \BibTeX\ to define the layout
\extitem [bzr] The GNU fontutils define the BZR format to hold
\extitem [dvi] \TeX\ produces device-independent output in the DVI file.
\extitem [epsf] Encapsulated \ps\ files contain scalable \ps\ images and extra information (such as the size of
\extitem [fig] FIG files are created by the \program{XFig} program (and
\extitem [fli] Font libraries are distributed with \emTeX. They contain a
\extitem [gf] Generic font files contain bitmap data for the characters of a
\extitem [gif] Graphics interchange format is a CompuServe bitmap graphics
\extitem [glo] Glossary files are produced by the \LaTeX\ \verb|\glossary|
\extitem [gsf] Ghostscript fonts are scalable fonts very similar
\extitem [hpgl] Hewlett-Packard GL is a plotter language. Many programs can
\extitem [hptfm] Hewlett-Packard tagged font metric files are a lot like \TeX\
\extitem [idx] Index files are produced automatically when you use the
\extitem [ilg] \program{MakeIndex} log files record the status of the last run of
\extitem [img] The IMG format is a particular bitmapped image
\extitem [ind] Index files are produced by the \program{MakeIndex} and
\extitem [ist] Index specification files are used by \program{MakeIndex} to
\extitem [jpeg] JPEG files are compressed bitmap images. Because JPEG files
\extitem [lof] List of figures files are produced by the \verb|\listoffigures|
\extitem [log] Log files are always produced by \TeX\ and \MF. The LOG file is
\extitem [lot] List of tables files are exactly analogous to LOF files.
\extitem [mf] Just as \TeX\ reads TEX files, which are plain ASCII
\extitem [mfj] MFjob files are plain ASCII files that contain instructions for
\extitem [msp] Microsoft Paint files contain bitmapped graphic images. They
\extitem [pbm] The portable bitmap format is a flexible bitmap
\extitem [pcf] The PCF format is one of several X11 bitmap font formats.
\extitem [pcl] PCL files contain printer commands for HP LaserJet printers.
\extitem [pcx] PCX files contain bitmapped graphic images. They
\extitem [pfa] Printer font ASCII files contain scalable outline data that
\extitem [pfb] Printer font binary files, like PFA files, contain the
\extitem [pfm] Printer font metric files are a Microsoft Windows standard.
\extitem [pk] Most \TeX\ DVI conversion programs read packed bitmap font
\extitem [pl] A property list file contains an ASCII representation of a
\extitem [ps] \ps\ is a page description language. The \ps\ language
\extitem [pxl] This format is obsolete. It has been completely superseded
\extitem [sfl] These files contain HP LaserJet softfonts in landscape
\extitem [sfp] These files contain HP LaserJet softfonts in portrait
\extitem [sfs] Scalable softfonts are HP LaserJet softfonts for the
\extitem [snf] Server native format fonts are another version of X11
\extitem [sty] Style files are used by \LaTeX\ to define the layout of
\extitem [tex] TEX files describe the layout of a typeset document in the
\extitem [tiff] TIFF files contain bitmapped or vector graphic images in a
\extitem [tfm] \TeX\ font metric files contain information about fonts.
\extitem [toc] Table of contents files are produced by the
\extitem [txt] Generic ASCII text.
\extitem [vf] Virtual font files. They are described in more detail in
\extitem [vpl] The virtual property list is a property list file for virtual
\extitem [xbm] X11 bitmap files contain a bitmapped image. X11 icons are
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:35:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 06:31:05 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101131.GAA02239@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Changing directory names
References: <"swan.cl.cam.:212500:950310104934"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 10:48:51, Sebastian Rahtz wrote:
> i've had dpi300 for years now, and there must have been some
> reason. can everyone swear that directories starting with numbers are
> ok on all OSes? atari, acorn, eg? mvs?
It's a dead issue. Pierre wants to hang me for suggesting it, Sebastian
has used it for years, and Karl and Phil both think it should stay.
I never shoulda brought it up.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 05:41:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 06:35:53 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101135.AA27876@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, vieth@xerxes.thphy.uni-duesseldorf.de
Subject: Re: Question re. MetaPost files
Since there's so little experience with Metapost, I'm not sure it's
feasible to try to define the necessary TDS structure right now.
Perhaps we should leave this open in the actual document, possibly throw
in Ulrik's recommendation as ideas, and make a later revision if necessary.
texmf
. metapost
. . base basic MetaPost distribution (e.g. plain.mp)
. . <package> contributed packages (future extensions)
. . support g/troff support files for MetaPost processor
However, this might lead to unnecessary subdirectory searching in the
`support' subdirectory, so maybe we do need a `macros' level, such as
We're not talking about very many files here, are we? I'd prefer to
avoid extra directory levels, for simplicity. One directory here or
there doesn't matter for searching.
Does metapost have impl/system-dependent files analogous to plain.base?
texmf
. metafont
. . base basic non-font MF files (e.g. plain.mf, modes.mf)
. . <package> other non-font packages (e.g. for drawing figures)
Hmm, I think I agree with metafont/base, but plain.mf and modes.mf are
hardly analogous. One is unchanging and done by Knuth; the other is a
relatively recent invention.
Maybe metafont/misc for single-file metafont ``distributions''?
(Probably be wise to reserve metapost/misc as well.)
Hmm, too bad, now we're requiring subdir searching in the metafont/ and
metapost/ trees as well.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 06:05:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
Date: Fri, 10 Mar 1995 11:42:34 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:242330:950310114247"@cl.cam.ac.uk>
> However, this might lead to unnecessary subdirectory searching in the
> `support' subdirectory, so maybe we do need a `macros' level, such as
>
> texmf
> . metapost
> . . macros MetaPost macros (*.mp files)
> . . . base basic MetaPost distribution (e.g. plain.mp)
> . . . <package> contributed packages (future extensions)
> . . support g/troff support files for MetaPost processor
it costs the TDS nothing to put this in, and if it makes Knuth happy,
i agree with Ulrik its sensible.
> Finally, I remember that there might be some other non-font MetaFont
> packages around for drawing labeled figures similar to MetaPost.
> Considering that, I think it would be too short-sighted to have only
> a flat level below `metafont' without a place to install those packages.
> So what about having a similar structure below `metafont' as well?
>
> texmf
> . metafont
> . . base basic non-font MF files (e.g. plain.mf, modes.mf)
> . . <package> other non-font packages (e.g. for drawing figures)
>
> Just another idea that may have been overlooked so far.
i think he's right. i am not sure wher i could put the mfpic stuff,
for instance
> [2] Concerning groff: Does anyone know if it has been ported to DOS,
> VMS or other non-Unix platforms? If so, it would be good to have
> it for people wishing to use MetaPost troff mode. One needs to
> have a troff capable of handling PostScript fonts anyhow, and
> I guess groff might behave more or less the same across platforms,
> whereas this might not be true for all the other troff variants.
i am sure i have seen a DOS groff on an ftp archive somewhere, but
dont have a precise pointer.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 07:32:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 08:33:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101333.AA20476@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: <texmf>/doc/<format>
The UnixTeX tape includes a certain amount of precompiled dvi and
ps documentation.
Pierre, how about having the dvi/ps files to be in the directory where
the source to the doc is, instead of segregated by format? Then the user
poking around hoping for help with latex only has to look under one
directory.
I can understand wanting to put a set of preformatted
basic-introduction-read-all-this-first stuff somewhere; for that,
I'd suggest texmf/doc/unixtex or texmf/doc/intro or some such, with
links (or copies or pointers to) the documentation in the various
texmf/doc/packages.
Does this make sense?
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 08:35:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 10 Mar 1995 09:34:58 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Help?
To: TWG-TDS@SHSU.edu
Message-ID: <794846098.65616.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
uh, since the name tugboat or ams seem to be associated with several
of the files that rich has listed whose extensions don't appear
in norm's list, i guess i should tackle those. ...
suggestions welcome.
by the way, there are quite a few files in rich's list that don't
conform to the 8+3 convention; whatever their other deficiencies,
the ams and tugboat files have tried to stay within that limit
(in fact, some of the older ones, like tugfil.chg, were named to
stay within the sail 6+3 limit), hence are in some cases much
less graceful than one would like.
-- bb
--------------------
.awk 2 /usr/local/lib/texmf/tex/tugboat/kwic-bib.awk
a script in the unix awk language (this one's from nelson beebe)
.chg 1 /usr/local/lib/texmf/tex/tugboat/tugfil.chg
this was an ad hoc name for a list of changes to files associated
with tug/tugboat; scrap it, please -- i intend to.
.cmn 1 /usr/local/lib/texmf/tex/tugboat/tugboat.cmn
this is a file that contains macros common to both the plain and
latex tugboat styles. it used to be called .com, but there were
strong objections to that on account of .com being "reserved" in
ms-dos. anybody got a suggestion for a substitute? (maybe .def --
see below; i reject .sty, also explained below.)
.d20 1 /usr/local/lib/texmf/tex/tugboat/makefile.d20
probably a script for some particular machine; never seen it before,
but "makefile" seems an obvious giveaway.
.def 4 /usr/local/lib/texmf/tex/ams/amssym.def
a file containing macros (definitions) for a particular purpose,
but not a complete style; ordinarily several .def files can be
put together to do useful things within or "on top of" a style.
this is an ams convention, predating the latex change of "master"
.sty to .cls, but approximately equivalent to what is now a latex
.sty="sub-style". (.mac was also used in this context at one time,
but since on dec machines .mac implies source for the macro
programming language, an alternative was needed and .def seemed as
simple and descriptive as anything else proposed.) i don't like
to use .sty for something that isn't acceptable by latex; too
confusing. for that same reason, i also distinguish latex input
to tugboat by using .ltx instead of .tex, and .lte for latex input
that requires latex2e; i'll probably change that convention soon
to .lt2 for a file that can't be processed with latex2e. (yes,
virginia, there are some such in tugboat.)
.ini 1 /usr/local/lib/texmf/tex/ams/amstex.ini
an initex input file that will read in various macro files and
then \dump to create a format file. probably idiosyncratic, but
has anybody got a better idea? (unlike scripts, this one isn't
system specific.)
.ltx 3 /usr/local/lib/texmf/tex/tugboat/kwic.ltx
input to latex, can't be processed by plain tex; useful distinction
when plain and latex input files are mixed in the same directory.
(see disquisition above under .def.)
.mf 329 /usr/local/lib/texmf/fonts/ams/cyrillic/src/cyrcsc.mf
this is in norm's list.
.sty 63 /usr/local/lib/texmf/tex/ams/amsppt.sty
in norm's list -- though this one happens to be ams-tex, not
ams-latex. mike spivak adopted the name from the latex concept
when there was still some hope that the original ams-tex and latex
might converge. a good idea at the time, but now confusing.
(and this is better than anything else i could have thought of to
support my contention that .../ams/... is *not* a good name in a
directory tree.)
.tug 1 /usr/local/lib/texmf/tex/tugboat/00readme.tug
an ad hoc extension meant to identify this particular file when mixed
in with possibly dozens of other readme files.
.txt 1 /usr/local/lib/texmf/tex/tugboat/00readme.txt
an ascii text file; in norm's list.
.unx 1 /usr/local/lib/texmf/tex/tugboat/makefile.unx
(not one of mine!) a system-specific script, unix.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 09:47:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 14:22:21 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503101322.AA04774@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: Question re. MetaPost files
K. Berry wrote:
> Does metapost have impl/system-dependent files analogous to plain.base?
Yes, it does. They're called .mem files. It also has a .pool file,
as you might have guessed by now. In my web2c patches I put them into
`texmf/ini' together with the other *.pool, *.fmt and *.base files,
but this is definitely system-dependent. On my Linux box with teTeX,
I've put them into /usr/local/tex/web2c/lib/mems outside the texmf
tree, for instance.
So far, there are two MetaPost .mem files: plain.mp and mfplain.mp.
The latter includes additional stuff for MetaFont compatibilty.
You could say
mp &mfplain logo10.mf
to get a series of PostScript files logo10.65 .. logo10.84 each
containing a single character. The output looks similar to what
you get from gftodvi incidently. (I just tried it.)
> Hmm, too bad, now we're requiring subdir searching in the metafont/ and
> metapost/ trees as well.
Well subdir searching is needed for the fonts tree anyway, so what's
the problem to search the metafont/ tree as well? After all, there
aren't really that many files in there.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 10:31:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101631.RAA19260@spice.iti.informatik.th-darmstadt.de>
Subject: Re: <texmf>/doc/<format>
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 17:31:55 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> Pierre, how about having the dvi/ps files to be in the directory where
> the source to the doc is, instead of segregated by format? [...]
> & texmf/doc/unixtex or texmf/doc/intro or some such [...]
>
> Does this make sense?
For me, yes.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 10:51:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101649.RAA22676@spice.iti.informatik.th-darmstadt.de>
Subject: No metafont subdirectories, please (was: Re: Question re. MetaPost files)
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 17:49:39 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> texmf
> . metafont
> . . base basic non-font MF files (e.g. plain.mf, modes.mf)
> . . <package> other non-font packages (e.g. for drawing figures)
>
> Hmm, I think I agree with metafont/base, but plain.mf and modes.mf are
> hardly analogous. One is unchanging and done by Knuth; the other is a
> relatively recent invention.
>
> Maybe metafont/misc for single-file metafont ``distributions''?
> (Probably be wise to reserve metapost/misc as well.)
Hmm. My TDS installation has 5 files in texmf/metafont/:
from DEK:
plain.mf
null.mf
expr.mf
io.mf
from KB:
modes.mf
Do you really think we should introduce two subdirectories for these
few files? I haven't seen any other non-font MF input files yet.
I'd say: Don't change the draft at this place. texmf/metafont/, and we
shouldn't bother that one file therein is not from the Grand Wizard.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:03:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101703.SAA18617@spice.iti.informatik.th-darmstadt.de>
Subject: File formats (was Re: Help?)
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 18:03:30 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> In all the books I've seen on TeX, I've never seen a rundown of the myriad
> file types used by TeX-related programs. If someone could point me to a
> FAQ or somesuch that explains all (most? some?) of them, I'd be *very*
> grateful. Ultimately, I'd like to have a set of notes that explains, for
> each file type:
>
> 1. purpose - what's it for?
Norm already pointed out the (really great) list from his book.
If you want to read a more verbose, though slightly out-of-date
(doesn't cover LaTeX2e), overview over most file types that TeX &
auxilliary programs uses, you can have a look at my paper ``Components
of TeX''. It's on CTAN somewhere (I believe, in info/). No coverage of
MF & drivers therein.
> 2. origin - how it is created?
This paper also features a diagram about the interconnection of tools
& files. That'll answer this question partly.
> 3. format - binary, ASCII, machine-specific, etc.
I have a draft of a LaTeX document that describes the following file
formats from the TeX domain: DVI, TFM, PL, GF, PK, VF, VPL, PXL. Most
subdocuments were extracted from WEB programs that featured the
definition; the PXL description is a re-tagged TUGboat article.
(barbara might remember this stuff.) It's missing editorial remarks,
otherwise it's complete.
I can make the draft available by anonymous ftp if many folks are
interested. Btw, the subdocuments about DVI, TFM, GF, and PK are
already available, as part of the DVI Driver Standard (Level 0).
A description of the TeX file format is in preparation. (That
sentence is meant seriously.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:13:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 12:08:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101708.MAA22560@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <199503071241.NAA11487@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 7 March 1995 at 13:41:34, Joachim Schrod wrote:
> sebastian wrote:
> > 4. p7. ams and pstricks are bad examples; there is no package called
> > ams! and pstricks is generic. "babel" and "fancyheadings" might be
> > better.
>
> babel is generic, too...
> amslatex is a good LaTeX package example.
> And `tools' if I think about it. That might make it clear that the
> term _package_ in this context is something different than a LaTeX2e
> _package_.
What do you mean by 'tools'? I'm confused...
> > b) is it also quite clear that .dtx files should go in doc? or should
> > they?
>
> I thought they go in source/latex/base/ ?
Yes. We've decided, right?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:20:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101719.SAA18639@spice.iti.informatik.th-darmstadt.de>
Subject: Portability of files
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 18:19:53 +0100 (MEZ)
Content-Type: text
[There were already some responses, but I hope I help by adding some
principle explanations.]
Rich wrote:
>
> 2. If an unpacked file is ASCII, there is a possible problem with
> line termination. UNIX uses LF, MacOS uses CR, MS-DOS uses
> CR/LF, and somebody may actually use LF/CR. Some programs are
> happy to accept all forms; others are not. My impression is that
> most TeX-related software accepts all forms; is this the case?
It was already noted: No.
TeX reads each input line at once into a buffer of fixed length. Then
it parses that line. If the line termination is not recognized by the
run time system, TeX will get most probably an input buffer overflow.
But even if the line will fit, TeX will go havroc: It's processing is
line-oriented, it will discard blanks at the end of a line, adds one
CR there, and then tokenizes the line until the _first_ CR appears.
I.e., if you take a MacOS file on a Unix system, and if that file
is short enough that the input buffer will not overflow, then only the
first line of the file will be processed, the rest will be ignored.
> 3. If the file is binary (non-ASCII, really), the question becomes
> a bit fuzzier. If the file is a machine-specific executable, no
> reasonable translation will be possible. If it is "just" a data
> file, and its format is defined in terms of a specific byte order,
> it should be portable without problems. Aren't most TeX-related
> files defined in this manner?
Almost. Some operating systems want blocking, and then the file must
be properly padded by a padding character that's defined in the file
format (not by the OS!). That typically implies that you can move
files without changes from a block-oriented OS to a stream-oriented
one, but not the other way round.
> 4. Any file that must be localized to the site that uses it is a real
> problem. How much of this exists, and is it really necesary?
In LaTeX 2e I know of 6 config files, there might be more in the
future. For dvips: psfonts.map, config.ps, as you'll never know the
printer configuration.
Then, all FMT files, and yes, that is really necessary. (Not all TeX
users use (only) English.) But this is not part of TDS proper, and may
not be a good comment for your question. I added it because I think we
talk about plug&play packages.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:29:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 12:25:41 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101725.MAA24606@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Documentation subdirectories
References: <199503081608.RAA22261@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 17:08:35, Joachim Schrod wrote:
> Norm wrote:
> > Well, I can see your point. I'd be tempted to say that single
> > documentation files go in the "misc" package, but then how does a
> > user find the docs? Is that not confusing?
>
> That's why I didn't like the name misc/.
>
> > If we say everything goes in texmf/doc/latex/styles, what about styles
> > with several documentation files (a readme, doc.tex, example, and something
> > else)?
>
> Make a subdirectory in doc/latex/styles/. As this tree is looked at by
> humans, not be speed-hungry algorithms, we can mix files and
> subdirectories therein.
Ok, it seems that we feel that the documentation files shouldn't mirror
the macros tree. Makes sense to me, too. Would someone summarize
what they think the doc tree should look like? Maybe with some concrete
examples?
I've got another hundred mail messages to go through and just feel too
rushed to do it myself...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:32:29 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101732.SAA19179@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 18:32:08 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> > [package names]
> >
> > babel is generic, too...
> > amslatex is a good LaTeX package example.
> > And `tools' if I think about it. That might make it clear that the
> > term _package_ in this context is something different than a LaTeX2e
> > _package_.
>
> What do you mean by 'tools'? I'm confused...
I mean the files that are on CTAN in macros/latex/packages/tools/.
{verbatim,array,multicol}.sty, etc.
The point here is:
-- The TDS document uses the term `package' in its usual sense: As a
unit of distribution and maintenance.
-- The LaTeX team in their great wisdom[*] uses the term `package'
for macro modules. Once, I proposed the term `bundle' for a
distribution unit in that domain.
I.e., `TDS package' \ne `LaTeX2e package'.
I still think, somewhere should be footnote that points out this
distinction. I expect that LaTeX users without any knowledge of TeX's
inner working will get confused by this mixup when they read the TDS
document.
Cheers,
Joachim
[*] That sarcasm was not meant towards team members in general; I
know the story behind that naming decision.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 11:57:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 12:53:05 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101753.MAA28279@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Misc. edits
References: <9503082039.AA21427@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
> Version 0.64 nits & notes
> =========================
>
> I tend to like commas better than most folks do, so take my comma additions
> with a grain of sale.
>
> 1. this role, however, they do not. ...
> this role, but this is not the case. ...
check.
>
> 2. ... in conflict as you ...
> ... in conflict, as you ...
>
check.
> 4. Shouldn't METAFONT gain a dash when it is split across two lines?
Probably...I wonder why TeX isn't giving it one?
> 5. I used the convention <foo> to indicate that "foo" is replaceable
> text. You should fix either the Conventions section or my figure.
Check.
> 6. But then explicitly ...
check.
> Also, installing or ...
check.
> One option was ...
>
> These are real run-on sentences. I would say that a sentence that
> takes more than two lines in this format is suspect, and that any
> sentence that takes more than three is TOO LONG! Break them up.
>
> 7. it it still ...
> it is still ...
I think these went away...
>
> 8. This TWG ...
> The TWG ...
check.
>
> 9. searching nis imperative ...
> searching is imnperative ...
check.
>
> 10. above, two files ... leads to ambiguity.
> above, the presence of two identically-named files in a search
> path leads to ambiguity.
check.
>
> 11. in the search order as needed.
> in the desired search order.
check.
>
> 12. ... is monocase names because ...
> ... is the use of monocase names. For example, ...
check
>
> 13. ... and Macintosh filesystems ...
> ... and MacOS, filesystems ...
check
>
> 14. not case-sensitive, therefore ...
> not case-sensitive. Consequently, ...
check
>
> 15. ... ``link farm'' is ...
> ... ``link farm'' (at 1 KB per link) may be ...
check
>
> 16. I think you need to discuss the strong possibility of multiple,
> parallel TDS trees. For instance, a given user might reference:
>
> a. a tree of personal files
> b. a tree of project-related files
> c. a system-level tree
> d. a network-wide tree
> e. a CD-ROM-based tree
>
> I realize you cover this in 2.4, but I think it could be fleshed
> out a bit, and that a small amount of hand-waving in Section 2.3
> wouldn't hurt. You should also recommend that all trees follow
> the TDS layout!
todo.
> 17. tex for ...
>
> I think the use of running heads here (pp. 5-6) is ugly, and
> should be replaced by some sort of table. I would also sort
> the entries alphabetically.
I don't have 0.62 anymore. You mean the "Top Level Directories"?
You're probably right. You just want to make me implement CALS table
model filtering in my DocBook -> LaTeX filter, don't you!? ;-)
> 18. sparc-sunos4.1.3
>
> This is *not* ISO-9660 compliant. Either pick a name that is
> compliant or explain that using longer names is a local option.
check.
>
> 19. Three format names are reserved:
>
> Shouldn't you indent the following three paragraphs?
check
>
> 20. , manmac.
>
> The trailing period should not be in typewriter font.
check?
>
> 21. ... For example, TeXinfo goes in ... and not ...
> ... For example, TeXinfo goes in ..., not ...
check
>
> 22. ... filenames, (see Section 4) the ...
> ... filenames (see Section 4), the ...
check
>
> 23. Analogously for gsftopk.
> gsftopk is handled analogously.
check
>
> 24. ... other formats
> ... other formats,
>
> 25. ... fonts and macros directories ...
>
> "fonts" and "macros" should be in typewiter font.
>
> 26. For formats for TeX, ...
> In the case of TeX formats, ...
>
> Say this aloud, then fix it...
I can't find 24-26 in 0.64
>
> 27. I'm nervous about opening up the misc category to allow
> "a small number of independent files". This asks for a
> judgment call, and could easily lead to a mess.
Doc is being reworked anyway...
> 28. The Summary could include a complete list from a real system,
> but it should ALSO include a definitive list showing where
> everything is supposed to go, according to the definition.
> This will allow folks to know how to name a directory for
> something they haven't previously encountered.
>
> I also think the directory level notation serves a purpose,
> by reminding folks of how many levels they have to play with.
todo
>
> 29. ... and fonts for example are ...
> ... and fonts, for example, are ...
check
>
> 30. I would like to see a section added, discussing implementation
> issues of the sort I noted in my recent TDS posting.
Between discussions of CDs, TUG'95, and everything else, I'm not sure
which you meant for this section. Refresh my memory, please?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:03:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 12:59:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101759.MAA29055@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503082348.AA22109@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 8 March 1995 at 15:48:38, Rich Morin wrote:
> I think that Joachim's directory list, although interesting, provides a
> very clear demonstration of the difference between a directory listing
> and the kind of figure I generated. Even if Joachim's list were annotated
> and put into a tidier (to my taste :-) format, it would still:
>
> 1. be too large to be comprehended as a whole
> 2. not be guaranteed to show all possible parts of the TDS tree
>
> Thus, while I have no problem with someone generating an annotated version
> of a list like Joachim's, nor with including it as an appendix to the TDS
> document, I don't see it as a substitute for my figure.
Yes, I think we need both.
> I'm still a fan of having an extension (.tds.zip ?) that does automatic
> archiving to taste. Let's say I include a file called "DIRSTRUCT.TDS"
> in the distribution, then wuftp "does the right thing" if I try to
> "get directory.tds.zip". It's probably hopeless, but I like it ;-)
>
> I have no particular problem with this, in principle. In practice, I am
> concerned that the implementation might get a bit resource intensive,
> error-prone, and tedious for the FTP client. If I understand what Norm
> is suggesting, the archive's wuftp software would (automagically):
>
> 1. unpack the existing archive (foo.tar.gz, bar.zip, or whatever)
> into a suitable amount of unused storage space, left conveniently
> lying around by Sebastian, et al.
Things aren't usually packed up...
> 2. Using some sort of script or makefile, move the unpacked files
> and directories into an empty directory, building TDS-compliant
> sub-directories as needed.
>
> 3. Create an archive of this tree, using Info-Zip.
>
> 4. Hand it off to the FTP client, presuming the session hasn't timed
> out in the meanwhile.
Er, yeah ;-)
> The biggest concern I have, however, is that if anything goes wrong, we have
> a random client watching as things crater, possibly without any indication
> of what is going on, and certainly without any ability to set things right.
> This is *not* my notion of a recipe for a stable, trouble-free server!
Too true.
> Finally, I find myself really disturbed by the implications of "hoping
> that all the major tex implementors agree". Implementors are free to
> disagree or not, but they can't call themselves TDS-compliant unless
> they follow the TDS. If the TDS is so loose it allows compliant systems
> to get folks into trouble, perhaps we haven't done *our* job right.
Rich brought this up before. Who's going to test "TDS compliance"?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:12:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:08:45 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101808.NAA00398@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: editorial comments
References: <199503091148.AA06632@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 06:48:49, K. Berry wrote:
> > Probably should explain ``8.3''. We know what we mean, but ...
>
> I've added an example, as per Rich's suggestion. Good enough?
>
> Well ... I dunno. *I* know what 8.3 means, *you* know what 8.3 means,
> but will some random package designer necessarily know? They might have
> never worked on anything but Unix. Or whatever. Text along the lines of `8.3
> filenames (i.e., at most one `.' in the name, with at most eight
> characters before the . and at most three characters after)'
>
> would make me happier.
check.
> > For example, texmf/source/web2c and the \filename{dtx} sources ...
>
> Check. Oh, but wait, are DTX files sources or documentation?
>
> They're both. It's a problem. I don't have a solution.
>
> > Additional text: This does mean \emph{only} those directories must be
> > searched: texmf/tex// is a correct path for TeX inputs in a TDS tree.
>
> Did you mean "does not mean only" or am I missing something?
>
> Right, I meant ``does not mean only''. Sorry.
i think i put it in the right place...
> > `feasible' better than `possible', I think. Anything's *possible*.
>
> Anything?! ;-) Check.
>
> Anything. Even pi being 3. (See D. Hofstadter's articles :-)
Keep yer hexagons to yourself...
> > 4) The path is wrong. Has to start with /tex-archive. Assuming you mean
> > `CTAN' is a host name.
>
> I don't, CTAN is a meta-thingy...
>
> Oh. I think that will be confusing to people just glancing through.
> I think it'd be more natural to say \meta{ctanhost}:/tex-archive/blah?
But what about CTAN sites that don't start with /tex-archive?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:18:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:13:45 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101813.NAA01053@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Filename constraints
References: <199503091655.AA08800@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 11:55:24, K. Berry wrote:
> texmf/tex/plain/ams is amstex because it's for plain
>
> Say what? amstex is a format, hence I thought it was:
> texmf/tex/amstex
>
> Or are you talking about something else?
Just a bad example on my part, probably.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:21:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:17:05 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101817.NAA01420@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <794783219.303634.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 16:06:59, BNB@math.ams.org wrote:
> i think it's true that a single packed, compressed form will
> not be usable on all systems for which tex is now available.
> true or not?
Maybe I misunderstand. A packed, compressed form isn't usable
by any TeX system, right? If you are asking if there exists
a packed, compressed form that can be *extracted* on any system,
then I think the answer is that there is. Probably several.
> if true, then multiple versions will be needed. this gets us
> back to the problem of an expanding ctan, if all possible
> systems are to be supported. worse, it gets us into the problem
> of how to maintain synchronized versions of any package for all
> systems. (don't know about the rest of you, but the ams doesn't
> have all these systems installed, and even less does it have the
> expertise needed to manage all of them. and even for the several
> special packages we do offer, we have enough more than trouble
> maintaining synchrony and get more mail to our tech-support address
> about glitches than i ever want to see.)
What sort of synchrony are you trying to maintain? TeX is TeX. ;-)
Or do you mean synchrony of distributions?
> i think that "on-the-fly" packing of a tds-compliant package would
> be wonderful, but it doesn't seem trivial.
It's not. It's probably impossible in the general case.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:23:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:19:02 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101819.NAA01636@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503092215.AA00666@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 9 March 1995 at 14:15:15, Rich Morin wrote:
> > Symbolic links would be ok, too, I think. If zip (like tar) can be
> > told to follow them. I think it can but I was lazy.
>
> There is also a storage consideration: each symlink occupies one disk
> block. For large collection of files, this could be a consideration.
In my script, the symlinks, like the copied files, would be temporary
so it hardly matters.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:31:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:27:20 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101827.NAA01834@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
References: <9503100921.AA04214@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 10:21:45, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> texmf
> . metapost
> . . base basic MetaPost distribution (e.g. plain.mp)
> . . <package> contributed packages (future extensions)
> . . support g/troff support files for MetaPost processor
>
> However, this might lead to unnecessary subdirectory searching in the
> `support' subdirectory, so maybe we do need a `macros' level, such as
One extra subdir doesn't worry me too much.
Should I add a larger description of MetaPost to the TDS draft?
> Finally, I remember that there might be some other non-font MetaFont
> packages around for drawing labeled figures similar to MetaPost.
> Considering that, I think it would be too short-sighted to have only
> a flat level below `metafont' without a place to install those packages.
> So what about having a similar structure below `metafont' as well?
>
> texmf
> . metafont
> . . base basic non-font MF files (e.g. plain.mf, modes.mf)
> . . <package> other non-font packages (e.g. for drawing figures)
>
> Just another idea that may have been overlooked so far.
Ulrik's got a point. What sayest the rest of you?
> [2] Concerning groff: Does anyone know if it has been ported to DOS,
> VMS or other non-Unix platforms? If so, it would be good to have
> it for people wishing to use MetaPost troff mode. One needs to
> have a troff capable of handling PostScript fonts anyhow, and
> I guess groff might behave more or less the same across platforms,
> whereas this might not be true for all the other troff variants.
To DOS and OS/2, at least. Linux trivially.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
From BNB@MATH.AMS.ORG Fri, 10 Mar 1995 13:22:09 EST
Return-path: <BNB@MATH.AMS.ORG>
Date: 10 Mar 1995 13:21:48 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Subject: re: twg-tds, metafont logo
To: norm@ora.com
Bcc: bnb@MATH.AMS.ORG
Content-transfer-encoding: 7BIT
Mail-System-Version: <MultiNet-MM(351)+TOPSLIB(158)+PMDF(4.1)@MATH.AMS.ORG>
i highly recommend this definition for the metafont logo:
\ifx\MF\undefined
\ifx\manfnt\undefined
\font\manfnt=logo10
\fi
\ifx\manfntsl\undefined
\font\manfntsl=logosl10
\fi
\def\MF{{\ifdim\fontdimen1\font>0pt \let\manfnt = \manfntsl \fi
{\manfnt META}\-{\manfnt FONT}}\spacefactor1000 }%
\fi
(from the file texnames.sty compiled by nelson beebe.)
-- bb
================================================================================
From norm@ora.com Fri, 10 Mar 1995 14:03:31 EST
Return-path: <norm@ora.com>
Date: 10 Mar 1995 13:46:25 -0500
From: norm@ora.com (Norman Walsh)
Subject: re: twg-tds, metafont logo
To: bbeeton <BNB@MATH.AMS.ORG>
Reply-to: norm@ora.com
Content-transfer-encoding: 7BIT
References: <794859708.256535.BNB@MATH.AMS.ORG>
On 10 March 1995 at 13:21:48, BNB@math.ams.org wrote:
> i highly recommend this definition for the metafont logo:
Thanks, Barbara.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:36:27 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Mar 1995 10:36:46 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101836.KAA04722@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: <texmf>/doc/<format>
Pierre, how about having the dvi/ps files to be in the directory where
the source to the doc is, instead of segregated by format? Then the user
poking around hoping for help with latex only has to look under one
directory.
Makes a lot of sense because the source directory ought to be the first place
people look. The only trouble is the LaTeX manuals. The rules are
pretty absolute about what can be in LaTeX source directories
PS: Norm, it was the suggestion that texmf might be in question
that I really had in mind, and I don't know whether the
West Locrians ever went quite to the point of stringing the
poor guy up. But wouldn't it ginger up the Congress?
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:37:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 09:45:40 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503101745.AA03188@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
SR> i dont think we should let this discussion hold up release of the TDS
SR> draft for discussion
No argument there, but it appears that the assorted discussions are
co-existing rather peacefully, at present.
SR> surely our esteemed chair's book has what Rich needs?
NW> Um, have you looked at app A of my book? ;-) ...
JS> Norm already pointed out the (really great) list from his book.
Yes indeed, there is a very nifty "Filename Extension Summary",
stashed away as Appendix A. Mea Maxima Stupido!
KB> I think Joachim's components-of-tex paper explains a lot of them.
KB> It's on CTAN. And you can copy it, unlike Norm's book!
Norm, is there *any* chance that your appendix could be freed up for
public domain use? It looks like you have a good start on the kind of
documentation I have in mind, and I'd hate to have to recapitulate it!
It sounds like Joachim's work will fit right in, as well. Even if it
doesn't reach FTP, I'd like a copy!
In any event, it looks like I have some reading and thinking to do
before I can create anything useful. (I also have a release to get out,
in my other life!) So, keep those cards and letters coming in, but do
not expect any earth-shattering results from me Real Soon...
Thanx to all, Rich
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:41:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:37:17 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101837.NAA02027@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Question re. MetaPost files
References: <"swan.cl.cam.:242330:950310114247"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 11:42:34, Sebastian Rahtz wrote:
> > However, this might lead to unnecessary subdirectory searching in the
> > `support' subdirectory, so maybe we do need a `macros' level, such as
> >
> > texmf
> > . metapost
> > . . macros MetaPost macros (*.mp files)
> > . . . base basic MetaPost distribution (e.g. plain.mp)
> > . . . <package> contributed packages (future extensions)
> > . . support g/troff support files for MetaPost processor
> it costs the TDS nothing to put this in, and if it makes Knuth happy,
> i agree with Ulrik its sensible.
You got it, then. Karl was in favor too, so I'll assume everyone will ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:44:27 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: No metafont subdirectories, please (was: Re: Question re. MetaPost files)
Date: Fri, 10 Mar 1995 17:16:55 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:116530:950310171719"@cl.cam.ac.uk>
i (gasp) disagree with Joachim. modes.mf is a distinct maintained
package, which should end up in its own directory or directories (does
it have docs?), not mixed in with immutables like plain.mf. we have
directories for everythjing else, dont stop now. i say
metafont/base and metafont/<package> ie metafont/modes. mfpic, for
instance, should be in metafont/mfpic, shoudnt it?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:44:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 10 Mar 1995 13:44:48 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
To: TWG-TDS@SHSU.edu
Message-ID: <794861088.42535.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
norm:
On 9 March 1995 at 16:06:59, BNB@math.ams.org wrote:
> i think it's true that a single packed, compressed form will
> not be usable on all systems for which tex is now available.
> true or not?
Maybe I misunderstand. A packed, compressed form isn't usable
by any TeX system, right? If you are asking if there exists
a packed, compressed form that can be *extracted* on any system,
then I think the answer is that there is. Probably several.
correct, extractable on any system.
maybe i'm just more heavily subject to murphy's law than most
folks, but in the past month i have received at least two
allegedly uuencoded files that couldn't be uudecoded by our
supposedly canonical version, and even more files identified
by ".zip" or a synonym that couldn't be unzipped by any one of
the several version of (g)unzip that we have here. much time
wasted. much frustration. (tugboat is delayed even longer.)
so i despair.
re synchrony, i mean between a package-archived-as-all-separate-pieces
and the same package-archived-in-packed-up-form. at ams, on e-math
we offer the amsfonts .pk files for the most popular resolutions
both as separate files, and as a single tar file per resolution.
even with the tar file packed up by a script, as often as not we
end up with the result not being identical to what someone would
get by retrieving all the separate pieces. i marvel that the
ctan managers are able to avoid glitches as well as they do.
i simply don't like multiple versions of the same thing -- single
file or package -- in the same structure, because of too many bad
experiences. (hmmm. the more i think about it, the more i agree
with joachim about needing new/different terminology.)
i guess i'll just have to trust those who have more experience
than i do in these areas and hope that what is decided doesn't
add to the complications of maintaining the ams packages.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:55:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:51:29 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101851.NAA02256@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503101745.AA03188@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 09:45:40, Rich Morin wrote:
> Norm, is there *any* chance that your appendix could be freed up for
> public domain use? It looks like you have a good start on the kind of
> documentation I have in mind, and I'd hate to have to recapitulate it!
I think I can swing it. At least for inclusion in selected documents;
I don't know if I can get wholesale permission.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:56:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101856.TAA15650@spice.iti.informatik.th-darmstadt.de>
Subject: Next round (0.64)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Fri, 10 Mar 1995 19:56:02 +0100 (MEZ)
Content-Type: text
Version 0.64
============
--------------------
logos.sty:
\def\iniMF{\program{iniMF}}
\def\iniTeX{ini\TeX}
Replace by
\def\iniMF{\program{INIMF}}
\def\iniTeX\iniMF{\program{INITEX}}
That's the way DEK writes them.
And use that style file. :-) Then METAFONT will get a hyphen, too.
--------------------
intro.sgm:
<para>
In this document, ``/'' is used to separate filename components (as in
texmf/fonts/…). This is the &unix; convention but
the ideas are in no way &unix;-specific.
</para>
Tag the slash. (<literal> or <character> might fit, I think.)
Tag the directory name (<filename>).
--------------------
basics.sgm:
<para>
Even if your &TeX; implementation does not support subdirectory
searching, you may still find it useful to adopt the structure if you
do not use many fonts or packages. For instance, if you only use
Computer Modern and &AMS; fonts, it it still possible to set them in the
>> ^^^^^
>> Really? The logo here, too?
&tds; structure, and list the directories individually in configuration
>> ^^^^^^^^^
>> discard, already in TDS
files or enviornment variables
>> ^^
>> ro
</para>
[...]
on slower machines. Nevertheless, we feel that subdirectory searching
nis imperative to a well organized &tds;, for the reasons stated above.
>> ^^^
>> is
[...]
(e.g., ``FILENAME.EXT'')
<filename>filename.ext</>
--------------------
macros.sgm:
<para>
The <replaceable>format</> directory <filename>config</> is reserved for
configuration files. Configuration files are used by several
formats including, for example, &LaTeX; and the Babel styles.
</para>
That was not what I intended with my proposal: Now I have to add yet
another tree to the search path. IMO, config/ should be a reserved
<package> name.
<para>
The <filename>plain</> directory is intended for files which are
only useful with the Plain &TeX; format:
>> ^^^^
>> discard. Files should be usable with other plain-based formats
>> (like AmS-TeX), too.
<filename>fontchart.tex</>, <filename>testfont.tex</>,
<filename>story.tex</filename>, <filename>manmac.tex</>,
<filename>webmac.tex</>, etc., as well as <filename>plain.tex</>
itself. The <filename>generic</> directory, by contrast, contains
files which can be used with &LaTeX; and/or &AMS;&TeX; as well as
>> ^ ^^^ ^^^^^^^^^^
>> also discard
>> AmS-TeX has an hyphen
>> don't you have an entity?
Plain: <filename>path.sty</>,
<filename>texnames.sty</>, <filename>null.tex</>, etc.
</para>
[...]
<filename>babelr</>
>> ^
>> discard
[...]
New Standard &LaTeX;
Why the capitalization here?
[...]
&TeX;info
There's still the logo.
--------------------
fonts.sgm:
<varlistentry><term><filename>pk</></>
<listitem><para><filename role=ext>PK</> files</para>
</listitem></varlistentry>
Append
<varlistentry><term><filename>gf</></>
<listitem><para><filename role=ext>GF</> files</para>
</listitem></varlistentry>
[...]
300dpi, 10pt
Insert a spatium (`\,').
Since the &tds; cannot assume long filenames,
(see <xref linkend=constraints>)
Move comma after parenthesis.
--------------------
bibtex.sgm:
still no logo in the title
--------------------
example.sgm:
. doc/ user documentation
. . <format>/ name of a format file (e.g., plain)
>> ^^^^
>> discard
same in tex/<format>/.
--------------------
Issue \appendix before ``Where are All the Files?''
Hope we get closer to a final document...
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 12:59:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:54:44 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101854.NAA02359@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: No metafont subdirectories, please (was: Re: Question re. MetaPost files)
References: <"swan.cl.cam.:116530:950310171719"@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 17:16:55, Sebastian Rahtz wrote:
> i (gasp) disagree with Joachim. modes.mf is a distinct maintained
> package, which should end up in its own directory or directories (does
> it have docs?), not mixed in with immutables like plain.mf. we have
> directories for everythjing else, dont stop now. i say
> metafont/base and metafont/<package> ie metafont/modes. mfpic, for
> instance, should be in metafont/mfpic, shoudnt it?
Yes.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:02:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 19:02:30 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503101902.AA09287@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
bb> i guess i'll just have to trust those who have more experience
bb> than i do in these areas and hope that what is decided doesn't
bb> add to the complications of maintaining the ams packages.
Well, I think people are going to demand some form of plug-and-play
(stupid expression) so I suspect we just need to proceed with fingers
crossed. I am sure that there will be some instances of `restructured'
distributions being out of sync, or at least not obviously in sync,
with the `canonical' latex or ams* distributions, but what can we do??
Actually `real' ready-installed systems are not so bad, eg an emtex
style zip file that just falls into place, with ready made formats.
The problems will arise if the `TDS' style distributions can not fully
automate the install process, as they are trying to work across a
range of machines. In that case the user may only have to make the
`final easy' steps of the installation, unfortunately (s)he might not
know this, as the canonical installation coming with from L3 team or
AMS describes the installation procedure from a different starting
point.
Hopefully, once things settle down, it will be sufficient for the
LaTeX install docs to say `If you obtained LaTeX in a TDS
distribution, jump straight to step 99' (or something..)
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:02:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 13:58:10 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101858.NAA02424@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <794861088.42535.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 13:44:48, BNB@math.ams.org wrote:
> Maybe I misunderstand. A packed, compressed form isn't usable
> by any TeX system, right? If you are asking if there exists
> a packed, compressed form that can be *extracted* on any system,
> then I think the answer is that there is. Probably several.
>
> correct, extractable on any system.
> maybe i'm just more heavily subject to murphy's law than most
> folks, but in the past month i have received at least two
> allegedly uuencoded files that couldn't be uudecoded by our
> supposedly canonical version, and even more files identified
> by ".zip" or a synonym that couldn't be unzipped by any one of
> the several version of (g)unzip that we have here. much time
> wasted. much frustration. (tugboat is delayed even longer.)
> so i despair.
Ahh, I said there were several, I didn't say that that god forsaken
mess known as uuencoding was one of them ;-)
I'm surprised, however, that you've had trouble with ZIP files.
Unless they were UUencoded and mailed to you, in which case I blame
uuencoding (or a mailer).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:03:29 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101903.UAA15689@spice.iti.informatik.th-darmstadt.de>
Subject: Re: No metafont subdirectories, please (was: Re: Question re. MetaPost
To: TWG-TDS@SHSU.edu
Date: Fri, 10 Mar 1995 20:03:41 +0100 (MEZ)
Content-Type: text
> On 10 March 1995 at 17:16:55, Sebastian Rahtz wrote:
> > i (gasp) disagree with Joachim. modes.mf is a distinct maintained
> > package, which should end up in its own directory or directories (does
> > it have docs?), not mixed in with immutables like plain.mf. we have
> > directories for everythjing else, dont stop now. i say
> > metafont/base and metafont/<package> ie metafont/modes. mfpic, for
> > instance, should be in metafont/mfpic, shoudnt it?
>
> Yes.
OK, I'm convinced. Well ... partly. ;-)
metafont/modes/ or metafont/misc/? modes.mf is a single file.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:17:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 14:12:54 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101912.OAA02685@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Next round (0.64)
References: <199503101856.TAA15650@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 19:56:02, Joachim Schrod wrote:
> Version 0.64
> ============
> --------------------
> logos.sty:
> [...]
> And use that style file. :-) Then METAFONT will get a hyphen, too.
Ooops. logos.sty isn't used, I probably just snarfed it from my MTW
directory for something. bb supplied a macro that'll break MF.
> --------------------
> intro.sgm:
>
> <para>
> In this document, ``/'' is used to separate filename components (as in
> texmf/fonts/…). This is the &unix; convention but
> the ideas are in no way &unix;-specific.
> </para>
>
> Tag the slash. (<literal> or <character> might fit, I think.)
check
> Tag the directory name (<filename>).
check
> --------------------
> basics.sgm:
>
> <para>
> Even if your &TeX; implementation does not support subdirectory
> searching, you may still find it useful to adopt the structure if you
> do not use many fonts or packages. For instance, if you only use
> Computer Modern and &AMS; fonts, it it still possible to set them in the
> >> ^^^^^
> >> Really? The logo here, too?
Barbara?
> &tds; structure, and list the directories individually in configuration
> >> ^^^^^^^^^
> >> discard, already in TDS
> files or enviornment variables
> >> ^^
> >> ro
> </para>
check.
> [...]
>
> on slower machines. Nevertheless, we feel that subdirectory searching
> nis imperative to a well organized &tds;, for the reasons stated above.
> >> ^^^
> >> is
check.
>
> [...]
>
> (e.g., ``FILENAME.EXT'')
>
> <filename>filename.ext</>
check.
> --------------------
> macros.sgm:
>
> <para>
> The <replaceable>format</> directory <filename>config</> is reserved for
> configuration files. Configuration files are used by several
> formats including, for example, &LaTeX; and the Babel styles.
> </para>
>
> That was not what I intended with my proposal: Now I have to add yet
> another tree to the search path. IMO, config/ should be a reserved
> <package> name.
Ahh, you're right. I put it in the wrong section. I think it should be
texmf/latex/config and texmf/plain/config
not
texmf/config/latex
or whatever
> <para>
> The <filename>plain</> directory is intended for files which are
> only useful with the Plain &TeX; format:
> >> ^^^^
> >> discard. Files should be usable with other plain-based formats
> >> (like AmS-TeX), too.
check.
> <filename>fontchart.tex</>, <filename>testfont.tex</>,
> <filename>story.tex</filename>, <filename>manmac.tex</>,
> <filename>webmac.tex</>, etc., as well as <filename>plain.tex</>
> itself. The <filename>generic</> directory, by contrast, contains
> files which can be used with &LaTeX; and/or &AMS;&TeX; as well as
> >> ^ ^^^ ^^^^^^^^^^
> >> also discard
> >> AmS-TeX has an hyphen
> >> don't you have an entity?
check
> <filename>babelr</>
> >> ^
> >> discard
check
> [...]
>
> New Standard &LaTeX;
>
> Why the capitalization here?
i thought it wa supposed to be that way. David, Alan?
> [...]
>
> &TeX;info
>
> There's still the logo.
check
> --------------------
> fonts.sgm:
>
> <varlistentry><term><filename>pk</></>
> <listitem><para><filename role=ext>PK</> files</para>
> </listitem></varlistentry>
>
> Append
>
> <varlistentry><term><filename>gf</></>
> <listitem><para><filename role=ext>GF</> files</para>
> </listitem></varlistentry>
>
> [...]
check
>
> 300dpi, 10pt
>
> Insert a spatium (`\,').
ok
> Since the &tds; cannot assume long filenames,
> (see <xref linkend=constraints>)
>
> Move comma after parenthesis.
check
> --------------------
> bibtex.sgm:
>
> still no logo in the title
Still can't make it work :-(
> --------------------
> example.sgm:
>
> . doc/ user documentation
> . . <format>/ name of a format file (e.g., plain)
> >> ^^^^
> >> discard
>
> same in tex/<format>/.
check
> --------------------
>
> Issue \appendix before ``Where are All the Files?''
>
check
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:21:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 14:17:10 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101917.OAA02753@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503101745.AA03188@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 09:45:40, Rich Morin wrote:
> Norm, is there *any* chance that your appendix could be freed up for
> public domain use? It looks like you have a good start on the kind of
> documentation I have in mind, and I'd hate to have to recapitulate it!
Ask and ye shall receive. I can reproduce App A in the TDS. I've
attached it below. Rich, if you could add the new bits ;-)
But first, here's the definition of iplist, 'cause you'll need that
to format it. LaTeX gurus who wish to laugh at my style are requested
to do it quietly ;-)
----
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% An IP list is a configurable ``description'' like environment. The
% width of the first column is set by a parameter.
%
\def\iplabel#1{\hbox{\labeltextfont{#1}}\hss}
\newdimen\ipindent
\def\ipitem[#1]{%
\item[#1]
\setbox0=\hbox{#1}%
\ifdim\wd0>\ipindent\leavevmode\par\fi%
}
\def\ip@list[#1]#2{\list{}{\labelwidth#2 \itemindent\z@ \leftmargin#2
\advance\leftmargin\labelsep
\ipindent=#2\relax
\let\labeltextfont=#1\relax
\let\makelabel\iplabel}}
\def\iplist{\@ifnextchar [% ]
{\ip@list}{\ip@list[\textbf]}}
\let\endiplist\endlist
\let\wrapipitem=\item
----
\chapter{Filename Extension Summary}
\RCSID$Id: ap01.tex 2.10 1994/07/28 15:04:21 deutsch Exp norm $
\label{chap:fileext}
\def\extitem[#1]{%
{\fontsize{11}{13pt}\selectfont%
\ipitem [ \textit{\textbf{\uppercase{#1}}} ]
}
}
\ifincludechapter\else\endinput\fi
This chapter summarizes many common filename extensions. The extensions
are listed in alphabetical order. All extensions can be shortened
to three letters for consistency with operating systems that do not allow
longer file extensions. On other file systems, they may be slightly
different. For example, \ext{EPS} files are sometimes called
\ext{EPSF} files on \Unix\ systems, which allow longer filenames.
\begin{iplist}{.25in}
\extitem [abf] An Adobe binary screen font file contains a binary encoding
of a BDF (bitmap distribution format) file. Binary encoding makes the
files smaller, but it also makes
them less portable and unintelligible to humans. The binary format is
described in Adobe's ABF Format Specification~\cite{abffiles}.
BDF files are described below.
\extitem [afm] Adobe font metrics files are ASCII files distributed with
\ps\ Type~1 fonts. Type~1 fonts are the linearly scalable fonts that
\ps\ printer users are most familiar with. Bounding boxes, an encoding
vector (what characters go where),
kerning,
and
ligature
information
are among the things described in this file. The AFM file format is
described completely in Adobe's AFM Format
Specification~\cite{afmfiles}.
\ps\ fonts (available through commercial vendors or from the
Internet) are supplied with AFM files. Generally, the only occasion
that you would have to modify an AFM file would be to change the
encoding vector.
\extitem [aux] Auxiliary files are built by \LaTeX\ each time it formats
a document. \LaTeX\ writes information about cross references, citations,
etc., to the auxiliary file for post-processing by other tools, or
for \TeX\ processing the next time this document is formatted.
\newpage
\extitem [bbl] Bibliography files are created by \BibTeX\ from the citations in
your document, the bibliography databases (BIB) that you specify, and the
bibliography style (BST) you use. \BibTeX\ writes the resulting
bibliography to the BBL file, which is automatically included in your \LaTeX\
document at the place where you define the bibliography.
\extitem [bdf] Bitmap distribution format files are ASCII files that describe
a bitmap font. They are frequently used to distribute bitmap versions of
scalable fonts in screen resolution at common sizes. They are resolution
specific, but they are portable from one architecture to another. The BDF
file format is described completely in Adobe's BDF Format
Specification~\cite{bdffiles}.
Some fonts packages are distributed with BDF files.
Other BDF files are created as part of the conversion process from native
format to X11 format. It is unlikely that you would ever create one purely
by hand.
\extitem [bib] Bibliography databases contain bibliographic information.
These are generally handwritten and may contain bibliographic information
for all of the sources that you are (ever) likely to cite. The \BibTeX\
program reads information about each work that you \verb|\cite{}| from
the BIB file. Consult the documentation for \BibTeX\ for more information
about the format of BIB files.
\extitem [blg] \BibTeX\ log files record the status of the last run of
\BibTeX.
\extitem [bst] Bibliography style files are used by \BibTeX\ to define the layout
of the citations. \BibTeX\ produces \LaTeX\ commands in the BBL file that
define the citations in the format specified by the BST file.
You may eventually write or modify a bibliography style file, but it is less
common than modifying \LaTeX\ style files because bibliographies
have a more rigidly defined format. Consult the documentation for \BibTeX\ for
more information about the format of BST files.
\extitem [bzr] The GNU fontutils define the BZR format to hold
generic scalable font data. The file actually contains the specification
for a series of bezier curves. The BZR file format is defined in
the \TeXinfo\ pages that accompany the GNU fontutils.
The GNU fontutils create BZR files.
\newpage
\extitem [dvi] \TeX\ produces device-independent output in the DVI file.
This file describes the \TeX{}ed document in a simple stack language that can
be rendered on any device. The format of DVI files is described in the
\web\ documentation for \program{DVItype}, or in {\em The DVI Drivers
Standard}~\cite{dvi:standard}.
\TeX\ (and some \program{MFware} utilities) produces DVI files.
\hyphenation{encap-sulated}
\extitem [epsf] Encapsulated \ps\ files contain scalable \ps\ images and extra information (such as the size of
the image's bounding box) that is necessary to scale the image appropriately
for printing, unlike generic \ps. Using encapsulated \ps\ images in your \TeX\ document
requires a DVI driver that understands \ps\ \verb|\special|s. How to include
pictures and figures via encapsulated PostScript is described
in detail in Chapter~\ref{chap:pictures}, {\it \nameref{chap:pictures}}.
You are unlikely to create encapsulated \ps\ files by hand, but many
drawing and drafting programs can create them for you.
\extitem [fig] FIG files are created by the \program{XFig} program (and
possibly other programs). The scalable representation of a collection of
graphics objects is stored in ASCII form in FIG files. The
\program{transfig} program can translate FIG files into a number of
other formats including EPSF, HPGL, and a variety of \LaTeX\ environments.
\extitem [fli] Font libraries are distributed with \emTeX. They contain a
collection of PK files. Font libraries have several advantages over
a directory full of PK files: they are easier to maintain (because you
don't have to deal with hundreds of files); they are faster to search (because
they are indexed more efficiently than a directory); they are smaller
(because {\em each} PK file wastes an average of half a cluster of
disk space); and the name of each font is not limited to eight characters as
it is under MS-DOS file naming conventions.
Note: \program{dvips} can also use \emTeX\ FLI files.
\extitem [gf] Generic font files contain bitmap data for the characters of a
font. The GF format is very simple, and many \TeX\ related programs that
create fonts produce GF files. The disadvantage of GF files is that they are
very large (because no compression is performed). The format of GF files is
described in the \web\ documentation for \program{GFtoPK} (or any of the
GF-related \program{MFware} programs).
\MF\ is the primary source for GF files. Some other programs (some
of the GNU fontutils, for example) also produce GF files.
\extitem [gif] Graphics interchange format is a CompuServe bitmap graphics
standard. GIF files are very popular, and a number of converters (e.g.,
\program{BM2FONT}) can translate GIF files into a format usable by \TeX.
\extitem [glo] Glossary files are produced by the \LaTeX\ \verb|\glossary|
command. They are analogous to the IDX files produced by the \verb|\index|
commands. The glossary is inserted in your document wherever the
\verb|\makeglossary| command occurs.
\extitem [gsf] Ghostscript fonts are scalable fonts very similar
to \ps\ Type~1 fonts. Theoretically, \program{Ghostscript} can
use \ps\ Type~1 fonts directly, although I have never tried.
Several GSF fonts are distributed with \program{Ghostscript}.
\extitem [hpgl] Hewlett-Packard GL is a plotter language. Many programs can
produce vector graphics in HPGL format.
\extitem [hptfm] Hewlett-Packard tagged font metric files are a lot like \TeX\
TFM files. It is unfortunate that both files have the extension TFM
because they are completely incompatible. You can generate \TeX\ TFM files
from HPTFMs with the \program{HPTFM2PL} program.
\extitem [idx] Index files are produced automatically when you use the
\verb|\index| commands in \LaTeX. The IDX file contains raw indexing data
that will be used by the \program{MakeIndex} program to build an index for
your document. You must include the \filename{makeidx} style in your
\verb|documentstyle| command, and you must turn on indexing with
\verb|\makeindex| in the preamble of your document if you wish to (re)build
the index. See the entry for IND files below for more information.
\extitem [ilg] \program{MakeIndex} log files record the status of the last run of
\program{MakeIndex}.
\extitem [img] The IMG format is a particular bitmapped image
format used by the GEM Window System (a PC-based windowed desktop
interface product). The GNU fontutils read IMG files as their default
format.
The \program{PBMplus} utilities\footnote{The
\program{PBMplus} utilities are a collection of programs that allow conversion between
different graphic formats by using the PBM format as a transition step.}
can convert between many graphics file formats, including IMG.
\newpage
Some scanning software produces IMG files directly. Other IMG files
are distributed by the Free Software Foundation as part of an ongoing
project to produce high-quality, free typefaces.
\extitem [ind] Index files are produced by the \program{MakeIndex} and
automatically get included into your \LaTeX\ document wherever you
put the \verb|\printindex| command. The \verb|\index| commands in your
\LaTeX\ document write raw indexing data to the IDX file. \program{MakeIndex}
reads the IDX file, sorts and formats the index according to the IST file,
and produces an IND file for your document.
\extitem [ist] Index specification files are used by \program{MakeIndex} to
format the index file. Consult the documentation for \program{MakeIndex}
for more information.
\extitem [jpeg] JPEG files are compressed bitmap images. Because JPEG files
use a ``lossy'' compression algorithm, they are frequently much smaller
than other formats.
\extitem [lof] List of figures files are produced by the \verb|\listoffigures|
command in \LaTeX. After seeing \verb|\listoffigures|, \LaTeX\ writes
figure captions to the LOF file. The next time the document is formatted,
\LaTeX\ will insert the LOF file at the point where you issue the
\verb|\listoffigures| command.
\extitem [log] Log files are always produced by \TeX\ and \MF. The LOG file is
generally uninteresting. Status and warning messages deemed too trivial (or
too detailed) for the display are written to the log file (all messages
written to the display are also written to the log).
\extitem [lot] List of tables files are exactly analogous to LOF files.
\extitem [mf] Just as \TeX\ reads TEX files, which are plain ASCII
descriptions of a typeset document, \MF\ reads MF files, which are plain
ASCII descriptions of a typeface. \MF\ and MF files are the topic of
Knuth's \MFbook~\cite{kn:mfbook}. Unlike \ps\ fonts, \MF\ fonts are
not linearly scaled.\footnote{Linear versus non-linear scaling is a typographic
issue better discussed elsewhere. I mention it here just for
completeness.}
The standard \TeX\ distribution contains the MF files for the Computer
Modern fonts. Knuth has produced several more MF files to demonstrate \MF.
The American Mathematical Society has extended Computer Modern with several
more. The \program{MFpic} macro package produces MF files from a picture-like
environment in \TeX. \TheMFbook\ describes how to create your own fonts
with \MF.
The {\em List of MetaFonts}~\cite{lreq:metafonts} is posted
occasionally to the newsgroups \path|comp.text.tex| and \path|comp.fonts|.
Chapter~\ref{chap:mf}, {\it \nameref{chap:mf}}, describes \MF\ in more detail.
The \TeX\ fonts available in \MF\ format are listed in
Chapter~\ref{chap:fonts}, {\it \nameref{chap:fonts}}.
\extitem [mfj] MFjob files are plain ASCII files that contain instructions for
\program{MFjob}, an \emTeX\ program that builds groups of
\MF\ fonts. MFJ files can be created by hand to automate the process of
building a set of fonts. They are also created by the \emTeX\ DVI drivers if
automatic font generation is being used.
\extitem [msp] Microsoft Paint files contain bitmapped graphic images. They
can be included in a \TeX\ document with \verb|\special| commands recognized
by the \emTeX\ DVI drivers.
\extitem [pbm] The portable bitmap format is a flexible bitmap
representation introduced by the \program{PBMplus} package. The \program{PBMplus}
utilities allow for the conversion of PBM format files to and from
almost anything else. The PBM format (and all the utilities) are
described in the manpages that accompany the \program{PBMplus} toolkit
distribution.
The PBM toolkit and many other X11 graphics utilities can read and
write PBM files (e.g. XV).
\extitem [pcf] The PCF format is one of several X11 bitmap font formats.
Architecture-specific versions of X11 use PCF files. Other architectures use
one of a number of other architecture-specific formats (e.g., SNF). PCF files
are used by at least the DEC versions of the X11 server. The X11
distribution for your architecture includes a program that will convert BDF
files to the standard adopted for your architecture.
PCF files are almost invariably created from some other source.
It is unlikely that you will ever create one by hand.
\extitem [pcl] PCL files contain printer commands for HP LaserJet printers.
DVI drivers for HP LaserJet printers create PCL files. It is possible to
get information out of some PCL files with \program{pcltomsp}.
\extitem [pcx] PCX files contain bitmapped graphic images. They
can be included in a \TeX\ document with \verb|\special| commands recognized
by the \emTeX\ DVI drivers.
\extitem [pfa] Printer font ASCII files contain scalable outline data that
describes each character in a Type~1 font. A large portion of this file is
encrypted, so it is an ASCII file only in the sense that the binary portion
is represented as a string of hexadecimal ASCII digits. This is
traditional \ps\ because it is pure ASCII. See PFB below.
Type~1 outline fonts are created by special font editing programs or
conversion tools (e.g. the GNU fontutils).
\extitem [pfb] Printer font binary files, like PFA files, contain the
outline data for \ps\ Type~1 fonts. The binary format was adopted to save
space (they are generally about half the size of their PFA
counterparts).\footnote{The proof is left as an exercise to the reader (I
always wanted to say that).}
Because they are binary files, it is more difficult to transfer them from
one architecture to another (endian-ness, binary transmission, etc.). \ps\
purists are apt to disparage them.
\extitem [pfm] Printer font metric files are a Microsoft Windows standard.
They are encountered frequently in archives that contain Type~1 fonts.
Unfortunately, these archives occasionally fail to include AFM files,
which are more standard outside of the Windows community. Even more
unfortunately, PFM files do not contain all of the information that is
in an AFM file. However, the \program{PFM2AFM} program can construct a
partial AFM file. I believe that the PFM file format is described
in a Microsoft technical note; however, I have never seen it.
Unless you use Microsoft Windows, PFM files are likely to be
useless. If you need PFM files, the MS-DOS program \program{Refont} can
create them from AFM files.
\extitem [pk] Most \TeX\ DVI conversion programs read packed bitmap font
files. The PK font format defines a clever scheme that allows
bitmap fonts to be compressed significantly. The format of PK files is
described in the \web\ documentation for \program{PKtype} (or any of the
PK-related \program{MFware} programs).
You are unlikely to create PK files by hand, per se, but there are a number
of utility programs that ultimately create PK files (e.g., \program{GFtoPK},
\MF, \program{MFpic}, \program{PS2PK}).
\extitem [pl] A property list file contains an ASCII representation of a
binary file. The property list format was created during \TeX\ development to
allow binary files (specifically TFM files) to be hand-coded. Most users have
no reason to create PL files; however, some programs create PL files that must
be converted into TFM files with the \TeX{}ware program \program{PLtoTF}. The
PL format is described in the \web\ documentation for \program{PLtoTF}.
If you need to edit \TeX\ font metric information for a particular
font, you will almost certainly do so by editing the PL file. You can create
a PL file from a TFM file with the \program{TFtoPL} utility.
\extitem [ps] \ps\ is a page description language. The \ps\ language
is described in a series of volumes from Adobe Systems. PS is a
common extension for \ps\ files.
Unless you are inclined to enter the Obfuscated \ps\ Contest, you
are unlikely to create \ps\ files by hand. \ps\ files are created by many
common tools.
\extitem [pxl] This format is obsolete. It has been completely superseded
by the PK format. If you still have PXL files, you can convert
them to PK format with the \program{PXtoPK} program. If you are still
using a DVI driver that needs PXL files, you need an upgrade.
\extitem [sfl] These files contain HP LaserJet softfonts in landscape
orientation. LaserJet softfonts are device specific bitmap representations of
a typeface. The bitmap versions are described thoroughly in the {\em LaserJet
Technical Reference Manual\/}~\cite{pcl5:techref} for each of the HP LaserJet
printers. Newer laser printers can perform automatic rotation of fonts (in 90
degree increments, at least), so the distinction between landscape and portrait
font files is disappearing.
\extitem [sfp] These files contain HP LaserJet softfonts in portrait
orientation. See the entry for SFL files, above.
\extitem [sfs] Scalable softfonts are HP LaserJet softfonts for the
new (HPLJ III and higher) LaserJet printers. These are really in AGFA
IntelliFont Scalable format~\cite{intellifont}.
\extitem [snf] Server native format fonts are another version of X11
bitmap font. See the entry for PCF files, above, for more information.
\extitem [sty] Style files are used by \LaTeX\ to define the layout of
a \LaTeX\ document (by redefining the meaning of commands like
\verb+\section{}+, for example). They are also used commonly to extend
\LaTeX. See the \LaTeX{} manual~\cite{ll:latexbook} for more information.
Style files are really just \TeX\ files that perform specific tasks. You
will eventually write or modify a style file, but it isn't something you
are likely to do every day.
\newpage
\extitem [tex] TEX files describe the layout of a typeset document in the
\TeX\ programming language,\footnote{You already knew this, didn't you?}
as defined by {\em The \TeX{}book}~\cite{kn:texbook}. Most
people use some form of macro package on top of \TeX\ to make the language
easier to swallow. If a \TeX\ file begins with \verb+\documentstyle{}+ or has
\verb+\begin{document}+ somewhere near the top, it is probably a \LaTeX\
document. Otherwise, look for the \verb+\input+ commands to see what macro
packages are being included.
Documents that do not appear to be \LaTeX\ documents and do not appear to
\verb|\input| special macro packages may be using a special {\em format}.
Formats are fast-loading precompiled macro packages. If you know the name
of the format file, you can tell \TeX\ to use it by typing \&{\em
format-name\/} as a parameter to \TeX.
\extitem [tiff] TIFF files contain bitmapped or vector graphic images in a
very flexible form. The ``T'' in TIFF stands for ``tagged.'' All of the
different kinds of information (regarding number of colors, compression,
etc.) that might appear in a TIFF file are given unique tags that allow
a TIFF file reader to skip over information that it does not
understand.
\extitem [tfm] \TeX\ font metric files contain information about fonts.
\TeX\ doesn't know anything about the intrinsic shape of the
characters that it lays down on the page. \TeX\ deals entirely with boxes.
Every character is described by the rectangular box that (usually)
surrounds it. The TFM file for a font describes the size of each
character's box, as well as ligature and kerning information for the font.
A human-readable version of a
TFM file can be produced with the \program{TFtoPL} program. The format of
TFM files is described thoroughly in the \web\ documentation for
\program{TFtoPL}.
If you have reason to modify a TFM file, you will almost certainly do
so by converting it to PL format first. You can convert it back into a TFM
file with the \program{PLtoTF} utility.
See also HPTFM files.
\extitem [toc] Table of contents files are produced by the
\verb|\tableofcontents| command in \LaTeX. After seeing
\verb|\tableofcontents|, \LaTeX\ writes chapter, section, subsection, etc.,
names to the TOC file. The next time the document is formatted, \LaTeX\ will
insert the TOC file at the point where you issue the \verb|\tableofcontents|
command.
\extitem [txt] Generic ASCII text.
\extitem [vf] Virtual font files. They are described in more detail in
Chapter~\ref{chap:fonts}, {\it\nameref{chap:fonts}}. In short, a virtual
font maps a character to an arbitrary sequence of \ext{DVI} file commands.
This may be another character in a different font, a different character
in the same font, or something else entirely.
\extitem [vpl] The virtual property list is a property list file for virtual
fonts (as opposed to being some sort of property list file that was itself
virtual ;-). VPL files serve the same purpose for VF files that PL files
serve for TFM files. The VPL format is defined in the \web\ documentation
for \program{VPtoVF}.
\extitem [xbm] X11 bitmap files contain a bitmapped image. X11 icons are
frequently stored in XBM files. They also occur in {\tt .icon} files and
files without extensions (e.g., in \filename{/usr/include/X11/bitmaps}). I mention them here only because I like to use
icons on my X11 desktop, and I have used \program{PKtoBM} to create several
nice ones from \TeX\ PK files.
X11 bitmap files are used for all bitmap displays in the X11 server
(not just icons). Because they are ASCII and not binary, they are
architecture independent, which makes them very portable.\par
\end{iplist}
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:27:40 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Mar 1995 11:27:57 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503101927.LAA11668@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
I don't think ZIP or anything else can get around the problem
of conflicting notions of line-end and bigendian/smallendian
binaries. Since ZIP tends to be used cross-platform I suspect
that may be where the problems arise. Versions of uuencode
with guard characters at the head of the line and NO SPACES
usually get through even most stupid mailers. There was a
rather better btoa/atob coding, but it never caught on widely
enough.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:29:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 10 Mar 1995 14:27:47 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Next round (0.64)
To: TWG-TDS@SHSU.edu
Message-ID: <794863667.670035.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
norm/joachim:
> basics.sgm:
>
> <para>
> Even if your &TeX; implementation does not support subdirectory
> searching, you may still find it useful to adopt the structure if you
> do not use many fonts or packages. For instance, if you only use
> Computer Modern and &AMS; fonts, it it still possible to set them in the
> >> ^^^^^
> >> Really? The logo here, too?
i'd be just as happy to see just plain "ams" here, not the logo.
> <para>
> The <filename>plain</> directory is intended for files which are
> only useful with the Plain &TeX; format:
> >> ^^^^
> >> discard. Files should be usable with other plain-based formats
> >> (like AmS-TeX), too.
how 'bout rephrasing as
The <filename>plain</> directory is intended for files which are
usable with the Plain &TeX; format and others compatible with Plain:
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 13:38:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 14:34:17 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503101934.OAA03146@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Next round (0.64)
References: <794863667.670035.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 14:27:47, BNB@math.ams.org wrote:
> norm/joachim:
> > basics.sgm:
> >
> > <para>
> > Even if your &TeX; implementation does not support subdirectory
> > searching, you may still find it useful to adopt the structure if you
> > do not use many fonts or packages. For instance, if you only use
> > Computer Modern and &AMS; fonts, it it still possible to set them in the
> > >> ^^^^^
> > >> Really? The logo here, too?
>
> i'd be just as happy to see just plain "ams" here, not the logo.
You got it.
> > <para>
> > The <filename>plain</> directory is intended for files which are
> > only useful with the Plain &TeX; format:
> > >> ^^^^
> > >> discard. Files should be usable with other plain-based formats
> > >> (like AmS-TeX), too.
>
> how 'bout rephrasing as
> The <filename>plain</> directory is intended for files which are
> usable with the Plain &TeX; format and others compatible with Plain:
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 14:21:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 1995 15:16:46 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503102016.PAA03986@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Draft 0.66
Reply-To: TWG-TDS@SHSU.edu
I just put 0.66 up. I think the last one I put up was 0.64, but I
couldn't remember so I bumped it up again.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 15:31:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 11:53:00 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503101953.AA03871@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
NW> Who's going to test "TDS compliance"?
Unfortunately, the users, but by registering the packages, we at least
have someone to contact when things break! Seriously, this is a real
problem, but I see no real chance that anyone other than the developer
is going to take much time to play at being a tester, in terms of the
actual functionality of a package. The end user will thus get stuck,
as usual, with being the real Beta (Alpha?) tester for the item.
One of my hopes for the registration process, however, is that the
"TDS Usage" entries can be used to steer clear of outright directory
and file name clashes. So, even if the new package doesn't function,
it won't trash any existing ones.
I would also like to see one or more sites take on the task of loading
up any and all examples of TDS compliant packages, and possibly running
an included test case or two. I'm hoping PTF will be in a position to
do some of this, and I would expect that the O'Reilly crew will do a
bit of it, as well. Finally, there seem to be some sites that install
everything that shows up, as a matter of course. Between all of us, we
may be able to detect a FEW bugs before the general public gets trashed.
It may also be that we will want to recommend certain pre-processing
to TDS-compliant distributions (e.g., convert binary files to fixed-
length format for VMS compliance or ASCII files to CR/LF format). To
the extent that we can create "commonly readable" files, we reduce the
combinatorics that will otherwise swamp us. But ALL of the file format
issues are still unclear, at least to me, so I am NOT making any real
proposals at this time.
NW> I think I can swing it. At least for inclusion in selected documents;
NW> I don't know if I can get wholesale permission.
===
NW> Ask and ye shall receive. I can reproduce App A in the TDS. I've
NW> attached it below. Rich, if you could add the new bits ;-)
Great! And because the TDS is a reproducible document (I presume!), the
material will be generally available for use and redistribution. I will
take a hack at folding in some of the new pieces and parts I see, then
send the results to a few folks (off-line) for a first look. Once it is
reasonably clean, Norm is free to include it.
I have a small fantasy, BTW, of creating an HTML document that would let
someone crawl around descriptions of files, filters, and such, tracking
how everything ties together. (I thought about doing an input-output
table, but they don't sell paper that large! :-). I think that kind of
roadmap would be really useful on the CTAN, and could also be shipped as
part of products like TeXcetera.
-Rich
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 17:27:01 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 10 Mar 1995 15:27:20 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503102327.PAA09866@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: <texmf>/doc/<format>
Karl wrote:
>
> Pierre, how about having the dvi/ps files to be in the directory where
> the source to the doc is, instead of segregated by format? [...]
> & texmf/doc/unixtex or texmf/doc/intro or some such [...]
>
> Does this make sense?
For me, yes.
Joachim
Still leaves the question about the LaTeX documentation.
I have a feeling that it is not considered right for just
any old body to put extra files in the LaTeX 2e directories.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Mar 1995 18:52:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Mar 95 16:52:56 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503110052.AA04892@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: nits & notes on 0.66
Norm-
I see other folks using the TDS alias for this, and I guess it serves a
purpose by keeping all of us from reporting the same problems, so here
goes...
1. Section 2.2:
The second paragraph is misleading and hard to read. My version
(below) is a bit verbose, but I think it is important that the
readers of the document have a clear and unambiguous explication:
=================================================================
One use of the TDS will be the creation of mountable, generic
TeX-related distributions on CD-ROM. The only universally
acceptable file system format for CD-ROMs is ISO-9660. ISO-9660
is portable and efficient, but it imposes strict limitations on
file and directory names:
* File and directory names may not exceed eight characters.
* File names may have extensions of up to three characters.
If a file has no name, it *must* have an extension.
* Names and extensions may *only* be made up of the
character set [A-Z0-9_]. Note that any alphabetic
characters must be in UPPER-CASE.
* A period is used to separate the file name from the
extension. It will always be present, even if the
name or extension is missing (e.g., FILENAME., .EXT).
* A version number, ranging from 1-32767, will be found
at the end of the file extension, separated by a semi-
colon (e.g., FILENAME.EXT;1, FILENAME.;32767).
* Only eight levels of directories are allowed, including
the top-level (mounted) directory. Thus, the longest
legal TDS path is:
<texmf>/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
Note: Many UNIX systems (e.g., SunOS) modify the displayed
format of ISO-9660 names, mapping alphabetic characters to
lower-case, removing extensions and trailing periods, etc.
Naturally, this does not affect the format of names on the CD-ROM.
=================================================================
2. Section 2.4, in and following description of bin/system:
for a Sun workstation TeX system
for a TeX system on a Sun workstation
... Or TeX administrators ...
... Some TeX administrators ...
Although designed to be ...
Although the TDS is designed to be ...
... Sites are
... Consequently, to avoid possible name collisions, sites are
3. Section 3:
... into a single directory (or a few directories) ...
... into a small number of directories ...
... example, TeXinfogoes in ...
... example, TeXinfo goes in ...
4. Section 4, in and after description of supplier:
... The public serves ...
... The public directory serves ...
... The amsfonst
... The amsfonts
It is necessary to place dpi ...
Really? Examples, or are you just hand-waving here???
5. I find it difficult to distinguish typewriter oblique from plain
typewriter font, particularly when they are mixed together, as in
the layout figure. Could you look into using a different font,
or perhaps an explicit notation such as <texmf>?
6. The formatting of the layout figure got trashed, somehow.
Yours, Rich
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 09:56:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 1995 15:48:48 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950313154848.22425448@vms.rhbnc.ac.uk>
Subject: An open apology to Joachim Schrod
As I seem to have offended Joachim in public, it is only right that I should
apologise to him in public as well (albeit at the expense of the patience of
the other members of this list). In asking ``how many of the fifteen were Unix
or close emulations thereof'', I was not seeking to offend, but sincerely
believed that the answer would be ``the majority''; Joachim makes it plain that
this was not the case, and I therefore stand corrected and apologise to him
unreservedly. I will endeavour to eliminate any further ad hominem arguments
from subsequent communications to the group.
** Phil.
P.S. Christian Spieler is better placed than I to advise on the current
generation of, or need for, fixed-512 records in VMS TeX; but here
at least, where we use some commercial drivers, there will continue
to be a need for fixed-512 records in DVI, TFM and PK files.
P.P.S Unzip -a is useful for `correcting' the line-endings of non-native
text files.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 11:09:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
Date: Sat, 11 Mar 1995 12:40:37 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:294070:950311124050"@cl.cam.ac.uk>
norm asks what "tools" are - the LaTeX package called that, is the
point, consists of lots of little
things. ctan:macros/latex/packages/tools
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 11:38:14 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503111311.OAA12079@spock.iti.informatik.th-darmstadt.de>
Subject: Re: nits & notes on 0.66
To: TWG-TDS@SHSU.edu
Date: Sat, 11 Mar 1995 14:11:28 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> I see other folks using the TDS alias for this, and I guess it serves a
> purpose by keeping all of us from reporting the same problems
Yes, and to get an archive of open and closed problems.
> One use of the TDS will be the creation of mountable, generic
> TeX-related distributions on CD-ROM. The only universally
> acceptable file system format for CD-ROMs is ISO-9660. ISO-9660
> is portable and efficient, but it imposes strict limitations on
> file and directory names:
> [...]
> * Names and extensions may *only* be made up of the
> character set [A-Z0-9_]. Note that any alphabetic
> characters must be in UPPER-CASE.
> [...]
> Note: Many UNIX systems (e.g., SunOS) modify the displayed
> format of ISO-9660 names, mapping alphabetic characters to
> lower-case, removing extensions and trailing periods, etc.
> Naturally, this does not affect the format of names on the CD-ROM.
The description is very good, and I would like to see it in the
document. An appendix would be good place for it, we could then
shorten the `Constraints' section with a pointer to that appendix.
But then we have to clarify that TDS cannot be specified with respect
to all these restrictions. In particular, we have to emphasize even
more that mixed case file names are *needed* by TeX. We rely on the
operating system to map requests with these official names to the
uppercase name on the CD. If that's not done properly (e.g., on Unix
systems) we have to use external methods for that mapping (e.g., link
farms).
The above description leads to the impression that the TDS specifies
the use of uppercase file names. It must not, as this is unfunctional,
and therefore unacceptable.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 11:39:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503111250.NAA16655@spock.iti.informatik.th-darmstadt.de>
Subject: Re: <texmf>/doc/<format>
To: TWG-TDS@SHSU.edu
Date: Sat, 11 Mar 1995 13:50:10 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> Still leaves the question about the LaTeX documentation.
>
> I have a feeling that it is not considered right for just
> any old body to put extra files in the LaTeX 2e directories.
I have to say I don't understand that remark. Perhaps it'll help if I
summarize my view of the discussion result:
Documentation of the LaTeX2e basic distribution goes into
doc/latex/base/. [*] This documentation are at least all TeX files
they supply. At the discretion of the distributor for some or all of
these files other representations (e.g., DVI or PS versions) may stay
there, too.
Documentation of LaTeX2e styles goes into doc/latex/<style>/. If the
documentation consists of only one file, we use `styles' for
<style>.[**] If there are more representations of this single file,
they are all stored in styles/. I.e., the decision if we use an own
directory or styles/ is document-based, not file-based.
Or did I misunderstand you?
Joachim
[*] I hope end users will find it there. Will have to do usability
tests.
[**] styles/ is therefore analogous to misc/, but a better name in a
subtree that's searched by humans.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 12:11:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Mar 1995 12:02:20 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503111702.MAA17101@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
References: <9503101953.AA03871@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 11:53:00, Rich Morin wrote:
> NW> I think I can swing it. At least for inclusion in selected documents;
> NW> I don't know if I can get wholesale permission.
> ===
> NW> Ask and ye shall receive. I can reproduce App A in the TDS. I've
> NW> attached it below. Rich, if you could add the new bits ;-)
>
> Great! And because the TDS is a reproducible document (I presume!), the
> material will be generally available for use and redistribution. I will
> take a hack at folding in some of the new pieces and parts I see, then
> send the results to a few folks (off-line) for a first look. Once it is
> reasonably clean, Norm is free to include it.
I should point out that someone here is going to insist on dropping in
some boilerplate as a footnote or introductory paragraph explaining that
the text is (C) ORA and available in a book, etc., etc., etc., but I
assume no one is going to object to that.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 14:54:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 1995 15:50:25 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503132050.PAA10595@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: ISO-9660 and case sensitivity
References: <199503111311.OAA12079@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 11 March 1995 at 14:11:28, Joachim Schrod wrote:
> But then we have to clarify that TDS cannot be specified with respect
> to all these restrictions. In particular, we have to emphasize even
> more that mixed case file names are *needed* by TeX. We rely on the
> operating system to map requests with these official names to the
> uppercase name on the CD. If that's not done properly (e.g., on Unix
> systems) we have to use external methods for that mapping (e.g., link
> farms).
I had a funny thought along these lines. It's my understanding that most
Unix systems understand the Rock Ridge extensions (aka High Sierra).
In those casea link farm isn't even required because the CD can contain
(virtual) mixed case names! Cool, eh?!
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 15:32:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 1995 14:32:33 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503131932.AA06198@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments, etc.
As long as anyone can freely copy/print/redistribute the
tdsguide.tex file, I can't imagine any objection
to including some text copyright ORA. It can't simply
say ``All rights reserved'', is the point.
If it's a problem, I (or someone) can write new descriptions.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 16:17:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 95 13:55:15 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503132155.AA26507@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Cool, but no cigar...
I had a funny thought along these lines. It's my understanding that most
Unix systems understand the Rock Ridge extensions (aka High Sierra).
In those casea link farm isn't even required because the CD can contain
(virtual) mixed case names! Cool, eh?!
Unfortunately, (a) only a few UNIX systems support RRIP as yet, despite the
fact that the standard has been out for YEARS, and (b) some systems actually
get confused when presented with the RRIP extensions. (If the system thinks
it "owns" the System Use area, it can be confused when it sees unexpected
bits in it. I think MacOS and HP-UX were noted as having this problem; I am
not sure when (or if!) they cleared this up.)
More to the point, you have to be a bit careful when trying to create and
document a disc than can have two separate, parallel file systems pointing
to the same files. If you limit everything except alphabetic case to fit
ISO-9660, you can explain things fairly easily. Otherwise, it could be a
real mess!
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 16:17:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 95 12:26:57 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503132026.AA26112@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: nits & notes on 0.66
I have no problem with the ISO-9660 description going into an appendix, if
it is too long to be included in the main body of the text. I think an
abbreviated form might still serve a purpose on the main text, however, if
we can agree on one. Here's a first cut at one:
=================================================================
One use of the TDS will be the creation of mountable, generic
TeX-related distributions on CD-ROM. The only universally
acceptable file system format for CD-ROMs is ISO-9660. ISO-9660
is portable and efficient, but it imposes strict limitations on
file and directory names.
Briefly, file and directory names may not exceed eight characters,
but file names may have up to a three character extension, set off
from the name by a period. File names are always followed by a
version number (e.g., ";1"). All names and extensions must be made
up from the characters A-Z (*not* a-z), 0-9, and underscore (_).
Thus, typical file and directory names look like "FILENAME.EXT;1"
and "DIR_NAME", respectively. Some systems modify the displayed
format of ISO-9660 names. Naturally, this does not affect the
format of names on the CD-ROM. See Appendix ...
=================================================================
I'm not sure what Joachim means by:
But then we have to clarify that TDS cannot be specified with respect
to all these restrictions. In particular, we have to emphasize even
more that mixed case file names are *needed* by TeX.
Unless I'm missing something crucial, mixed case file names are very nice
to have, but cannot be allowed to be necessary. That is, if mixed case
is needed to disambiguate between names, any ISO-9660 CD-ROM will fail.
We rely on the operating system to map requests with these official
names to the uppercase name on the CD. If that's not done properly
(e.g., on Unix systems) we have to use external methods for that
mapping (e.g., link farms).
Aside from the value judgement implied by "properly", I'm in sync here.
The above description leads to the impression that the TDS specifies
the use of uppercase file names. It must not, as this is unfunctional,
and therefore unacceptable.
As I would put it, the TDS must specify that names of "registered TDS
paths" must not conflict, even when case distinctions are ignored. This
leaves room for individual sites and unregistered packages to get into
trouble, but that's beyond our control, in any case.
-Rich
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 16:37:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 1995 17:32:49 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503132232.RAA28425@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: ORA Copyright...
References: <199503131932.AA06198@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 March 1995 at 14:32:33, K. Berry wrote:
> As long as anyone can freely copy/print/redistribute the
> tdsguide.tex file, I can't imagine any objection
> to including some text copyright ORA. It can't simply
> say ``All rights reserved'', is the point.
>
> If it's a problem, I (or someone) can write new descriptions.
It'll be fine. We've done it before. The Majordomo mailing
list software, for example, comes with a chapter of the
MIIS book.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Mar 1995 23:09:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Mar 95 10:35:25 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503130935.AA05836@thphy.uni-duesseldorf.de>
To: norm@ora.com, twg-tds@shsu.edu
Subject: Editorial comments on draft 0.66
Here are some editorial comments on draft 0.66. Most of them are
minor corrections, etc. However, there's one new suggestion below
that I want to put forward for general consideration:
What about a top-level texmf/html directory for hypertext online
documentation produced by utilities like texi2html or latex2html?
I think it would be preferable to keep those kind of documents under
a separate top-level directory for the following reasons:
1. Converters like texi2html tend to produce a huge number of small
.html files requiring separate subdirectories for each document.
Having those subdirectories somewhere under texmf/doc is likely
to clutter up that tree considerably, which would complicate
matters for users moving around the tree manually.
2. HTML documents are intended to be read by programs (WWW browers)
and not by humans directly. The other files below texmf/doc such
as preformatted .dvi or .ps files (whatever is more appropriate)
can be accessed individually by invoking a viewer on the command
line, whereas HTML documents rely on the links between files and
cannot easily be accessed indvidually without a front-end.
3. The contents of the texmf/html tree is likely going to mirror the
contents of the texmf/info tree, which is also a separate top-level
directory by itself. In fact the same document could show up in
three different places:
- as a small number of medium-sized .info files in texmf/info,
- as a huge number of small .html files somewhere below texmf/html,
- and as a single -- possibly large -- .dvi file below texmf/doc.
(BTW, where do the .texi files go? texmf/doc or texmf/source?)
Having those different representations of the same document in
different places (one for each method of accessing information)
seems to make more sense than having both a couple of .dvi files
and a couple of subdirectories of .html files in the same place.
In particular, this would be quite unlike the rest of the TDS tree
where directories usually contain either subdirectories or files,
but not both at the same level.
Does this suggestion make sense to you? (Of course, this doesn't mean
that there shouldn't be any .html files in the texmf/doc tree. In fact,
it would be very useful to have index.html files in the subdirectories
below texmf/doc to make it easy to navigate around all the .dvi and .ps
files using a nice front-end.)
So much for this suggestion. Now, for the editorial comments
I promised above...
* global:
Use \acronym instead of \textsc for TDS, also for TWG, CTAN, ...
Check usage of \path|...| vs. \literal{...} for reserved directories.
* sec. 1.2:
> In this document, ``{\TeX}'' generally means ``the {\TeX} system, including
> {\protect\MF}, \path|DVI| drivers, utilities, etc.,'' not just the {\TeX}
^ Maybe insert {\protect\MP} here as well?
Not sure if we want to give it that much prominence!
> program itself.
(If you use my LaTeX 2e package for \MF and \MP, you don't need
\protect anymore for those logos!)
* sec. 1.2:
> \item[\command{command}]
> Commands are typeset in italics.
> \item[\application{application}]
> Applications, like commands, are typeset in italics.
What's exactly the difference between commands and applications?
> \item[\literal{literal}]
> Literal text is typeset in typewriter type.
Unfortunately, this is used quite inconsistently with \path|literal|.
* sec. 2.1:
> This feature is already supported by many implementations of
> {\TeX} tools including, but not limited to, em{\TeX} (and its drivers),
^^^^^^^^
> Public{\TeX}, \application{Web2C}, Y\&Y{\TeX}, \command{dvips(k)},
^^^^^^^^^^^^
> \command{xdvi(k)}, and DECUS {\TeX} for VMS.
^^^^^ ^^^
Maybe \application{em{\TeX}} and \application{PubliC~{\TeX}}?
(I think it's two words and `PubliC' with uppercase C -> PC.)
Also use \acronym for DECUS and VMS here, it's already used
for VMS elsewhere.
* sec. 2.3:
> The root of the \textsc{TDS} should be a directory containing only
> {\TeX}-related
> materials. In this document, we shall designate this directory
> \path|texmf|, but the exact name
> of the directory is up to the installer. On PC networks, for example,
^^ Use \acronym{PC}?
> this could map to a logical drive specification such as \path|T:|.
* sec. 2.3:
> The name \path|texmf| was chosen for several reasons:
> it reflects the fact that the directory contains files to an entire
> {\TeX} system, (including {\protect\MF}, {\protect\BibTeX}, etc.,
^ Again the question whether to
insert {\protect\MP} here?
Perhaps not, if we keep texmf!
> and not just {\TeX} itself) and it is
> descriptive of a generic installation rather than a particular
> implementation (such as \path|emtex|, or \path|pctex|).
* sec. 2.4:
> \item[\path|metafont|]
> for the (non-font) input files used by {\protect\MF} (see \xref{Section 5,
> {Non-font {\protect\MF} Inputs}}).
> \item[\path|metapost|]
> for \application{MetaPost} files.
^^^^^^^^^^^^^^^^^^^^^^ {\protect\MP}
Add the sentence: (see \xref{Section 6, {\protect\MP} Files})
* sec. 2.4:
\item[\replaceable{program}]
> for {\TeX} applications. It may be convenient to store
> implementations (em{\TeX}, PC{\TeX}, etc.) as well as utilities
^^^^^^^^ ^^^^^^^^ \application
> (dvips, MakeIndex, etc.) in their own directories. Implementations
^^^^^ ^^^^^^^^^ \application
> can store configuration files, compiled format files, {\protect\MF}
^ Insert: {\TeX}
> bases, DLLs, etc. in their own directory. Utilities can store
^ Insert: {\protect\MP} mems,
> configuration files, input files, etc. in their own directory.
* sec. 2.4:
> \item[\path|man|]
> for manual pages (Unix-style documentation).
> \item[\path|info|]
> for processed Texinfo documents.
Maybe add the following item?
! \item[\path|html|]
! for hypertext documentation, produced e.g. by \application{texi2html}
! or \application{latex2html}.
* sec. 2.4:
> \item[\path|source|]
> for sources. For example \path|texmf/source/web2c|
> and the \path|dtx| sources for {\LaTeX}.
These are two quite different types of sources, aren't they?
Maybe elaborate a bit that dtx files are also documentation sources?
* sec. 3:
> The \replaceable{format} directory \path|hyphen| is reserved for
> hyphenation patterns. Thes are used only by ini{\TeX} when a new
^^^^^^^^^ \application{INITEX}?
> format file is being built.
* sec. 3:
> The \path|plain| directory is intended for files which are
> useful with the Plain {\TeX} format and others compatible with Plain:
> \path|fontchart.tex|, \path|testfont.tex|,
> \path|story.tex|, \path|manmac.tex|,
^^^^^^^^^^^^^^^^
> \path|webmac.tex|, etc., as well as \path|plain.tex|
> itself. The \path|generic| directory, by contrast, contains
> files which can also be used with {\LaTeX} or \AMSTeX as well as
^^^^^^^ use: {\AMSTeX}
> Plain: \path|path.sty|,
> \path|texnames.sty|, \path|null.tex|, etc.
Concerning story.tex: This is the canonical TeXbook example, but
I doubt if it will be of any use for ``other formats compatible with
Plain''. Maybe this (and io.mf) really belong into the doc tree?
Or maybe in both places, so that users still can run it. (The same
applies for the canonical LaTeX examples small2e.tex and sample2e.tex.)
* sec. 3:
> \item[\replaceable{package}]
> is the name of a package.
> \path|amstex|, \path|amslatex|, \path|babel|,
^^^^^^^^^^^^^
> and \path|fancyheadings| are examples of \replaceable{packages}.
Isn't that a format as it was stated before?
* sec. 3:
> The package name \literal{base} is reserved for the base
> distribution for each format. Files used by ini{\TeX} to construct
^^^^^^^^^ \application{INITEX}?
> format files should also be stored in the \literal{base} directory.
> For example, in the new standard {\LaTeX} distribution, the
> \path|*.ltx| files created during the build process should be
^^^^^^^^^^^^ cf. \path |dtx| sources, should it be: \path|ltx| files?
> stored in the \literal{base} directory along with the distribution.
* sec. 3:
> \item
> The \replaceable{format} directory \path|config| is reserved for
^^^^^^ package!
> configuration files. Configuration files are used by several
> formats including, for example, {\LaTeX} and the Babel styles.
* sec. 4:
> \item[\path|vf|]
> virtual font metrics
^^^^^^^
Why metrics? I thought that vf files contained only typesetting
instructions in some sort of symbolic DVI code, but they still
used TFM files as font metrics taken from the raw fonts. (Alan?)
* sec. 4:
> \item[\replaceable{supplier}]
> is the name of the font supplier or \path|public|.
> The \path|public| serves a practical
> purpose; it designates fonts for which there are no licensing problems
> if/when they are redistributed.
> \path|adobe|, \path|amsfonts|,
^^^^^^^^^^^^^^^
> \path|monotype|, and \path|public| are
> examples of \replaceable{supplier}.
Why `amsfonts' here? I'd say the supplier is `ams' as an organization.
* sec. 4:
> \item[\replaceable{typeface}]
> is the name of the typeface family. \path|cm|,
> \path|latex|, \path|amsfonts|, \path|concrete|,
^^^^^^^^^^^^^^^
> \path|bookman|, and \path|courier| are
> examples of \replaceable{typeface}.
There is no such typeface `amsfonts'. `ams' is a supplier for serveral
typefaces such as `euler', `symbols', `cyrillic'. BTW, what about
typefaces consisting of a single file such as dummy.tfm? Where does
that go? (Barbara?)
* sec. 4:
> The names \path|cm|, \path|latex|, and \path|amsfonts|
^^^^^^^^^^^^^^^ see above
> are very specifically defined. The \path|cm| typeface directory
> contains precisely the 75 fonts defined in \emphasis{Computers and
^^^^^^^^^ \doctitle?
> Typesetting, Volumes A-E}. The \path|latex| typeface directory
^^^^^^^^^^^^ only Volume E is relevant for this!
> contains only the fonts distributed with {\LaTeX} in the \emphasis{base}
> distribution. The \path|amsfonst| typeface directory
> contains only the fonts distributed by the {\AmS}.
^^^^^^ why the logo here?
* sec. 5--6 rewritten completely (see elsewhere)
* sec. 8:
> There are two reserved categories:
> \path|help| for metainformation, such as \acronym{FAQ}'s,
^^^^^^^^^^^^^^^ meta-information (with a hyphen)?
> David Jones' macro index, etc., and \path|general| for standalone
stand-alone (with a hyphen)? ^^^^^^^^^^
> documents not part of any package: Michael Doob's
> \emphasis{A Gentle Introduction to {\TeX}},
^^^^^^^^^ \doctitle?
> Joachim Schrod's \emphasis{Components of {\TeX}},
^^^^^^^^^ \doctitle
> \path|texbook.tex| and \path|mfbook.tex|, etc.
What about the canonical examples: story.tex, io.mf, etc.? Do they
go here as well, or better in the relevant format/base subdirectory?
Maybe texbook.tex (and story.tex) belong into texmf/doc/tex/plain/base
instead, whereas mfbook.tex (and io.mf) belong into texmf/doc/mf/base?
* sec. 8:
> Files below the \replaceable{package} level are determined by the
> documentation author. The documentation directory may contain {\TeX}
> sources, \path|DVI| files, text files, or whatever form
^ Maybe add \path|PS| files here as well?
> of documentation will best explain the package.
* sec. 9:
> texmf/fonts/martian/source/martian.mf
> texmf/fonts/martian/source/mart10.mf
> texmf/fonts/martian/tfm/mart10.tfm
Hmmm, hasn't that been changed into:
texmf/fonts/source/martian/martian.mf
texmf/fonts/source/martian/mart10.mf
texmf/fonts/tfm/martian/mart10.tfm
And shouldn't there be a supplier as well as a typeface name,
so maybe it's really:
texmf/fonts/source/public/martian/martian.mf
texmf/fonts/source/public/martian/mart10.mf
texmf/fonts/tfm/public/martian/mart10.tfm
* sec. 10:
The figure currently misses the new directories below metafont/
and metapost/. It also misses tex/hyphen/, tex/generic/ and
tex/format/config. I've provided an updated version (see elsewhere).
So long,
Cheers,
Ulrik.
P.S. It seems we are nearing a final version. Perhaps we should bump
the version number to 0.90 and set a target such as 0.99 for a public
release. (If that fails, we could still go to version 0.999999, though!)
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 04:29:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Mar 95 13:02:25 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503111202.AA05407@thphy.uni-duesseldorf.de>
To: twg-tds@SHSU.edu
Subject: MetaPost section of draft
Just a short note:
I've seen that draft 0.66 leaves a number of points open in the
MetaFont and MetaPost section. I volunteer to write up a draft
of these sections for inclusion into the TDS draft. Just give
me time until monday, I'll post it here then.
Cheers,
Ulrik. (writing this over a modem line)
P.S. What about specifying metapost/modes as a directory for the
quasi-canonical modes.mf as well as other local modes files.
Does this sound reasonable?
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:26:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 06:26:56 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141126.AA14846@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: MetaPost section of draft
P.S. What about specifying metapost/modes as a directory for the
quasi-canonical modes.mf as well as other local modes files.
Does this sound reasonable?
Do you mean metafont/modes?
Or are you saying metapost takes metafont input files?
I'm confused.
At any rate, I'm opposed to metafont/modes for the single file modes.mf.
Following everywhere else in the tree, I think it should
go in metafont/misc.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:31:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141130.MAA19186@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments on draft 0.66
To: TWG-TDS@SHSU.edu
Date: Tue, 14 Mar 1995 12:30:55 +0100 (MEZ)
Content-Type: text
Ulrik wrote:
>
> What about a top-level texmf/html directory for hypertext online
> documentation produced by utilities like texi2html or latex2html?
Yes.
> [editorial comments]
> Maybe add the following item?
>
> ! \item[\path|html|]
> ! for hypertext documentation, produced e.g. by \application{texi2html}
> ! or \application{latex2html}.
... for hypertext documentation in \acronym{HTML} format ...
> > The \replaceable{format} directory \path|hyphen| is reserved for
> > hyphenation patterns. Thes are used only by ini{\TeX} when a new
> ^^^^^^^^^ \application{INITEX}?
The canonical way to represent INITEX is by \texttt{INITEX}. See the
TeXbook and/or tugboat.cmn.
> Concerning story.tex: This is the canonical TeXbook example, but
> I doubt if it will be of any use for ``other formats compatible with
> Plain''. Maybe this (and io.mf) really belong into the doc tree?
Since they do not contain macros, I agree with Ulrik that it should
go to the doc/ tree. Same with io.mf.
> Or maybe in both places, so that users still can run it. (The same
> applies for the canonical LaTeX examples small2e.tex and sample2e.tex.)
No. Please don't put these files below tex/. This muddies the water,
there *are* TeX files that belong there (e.g., lablst.tex).
> P.S. It seems we are nearing a final version. Perhaps we should bump
> the version number to 0.90 and set a target such as 0.99 for a public
> release. (If that fails, we could still go to version 0.999999, though!)
Please no. Use a `normal' numbering scheme. Better yet, use some
revision management system like CVS. You'll need it if we go real
public with this draft, when comments dripple in to arbitrary version
you don't have available any more. (Btw, a backlog of all distributed
versions is at my ftp site.) By using rcs.sty, one can also add
revision numbers automatically; one might even want to typeset the
revision log...
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:33:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 06:28:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503141128.GAA14951@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: MetaPost section of draft
References: <9503111202.AA05407@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 11 March 1995 at 13:02:25, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> I've seen that draft 0.66 leaves a number of points open in the
> MetaFont and MetaPost section. I volunteer to write up a draft
> of these sections for inclusion into the TDS draft. Just give
> me time until monday, I'll post it here then.
You got it! ;-)
> P.S. What about specifying metapost/modes as a directory for the
I assume you mean metafont/modes
> quasi-canonical modes.mf as well as other local modes files.
> Does this sound reasonable?
Not really. The only file in there would be "modes.mf" (local modes,
like other local files, go in a separate tree). Single files go in
"misc".
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:36:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 06:36:24 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141136.AA14904@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: norm@ora.com, twg-tds@shsu.edu
Subject: Editorial comments on draft 0.66
What about a top-level texmf/html directory for hypertext online
documentation produced by utilities like texi2html or latex2html?
The idea of a separate html directory seems completely analogous to info/.
Sounds good.
But, I propose that both html/ and info/ be moved under doc/ -- shades
of Pierre's previous messages about .dvi/.ps/etc., I know. But I think
we all know what the differences are.
Putting them at the top level somehow seems conceptually wrong to me,
because these collections of documentations are hardly as basic to the
TeX system as, say, .tex or .mf files.
Hmm, though, a counterargument is that we have the other
application-specific directories at the top level, and so the
html-reading and info-reading applications might make it conceptually ok.
Now I'm not sure if moving html and info to under doc/ is a good idea.
Either way. I guess I'll toss it out there.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:39:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 11:39:05 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950314113905.2242a709@vms.rhbnc.ac.uk>
Subject: Re: nits & notes on 0.66
[Need for mixed-case]
JS> But then we have to clarify that TDS cannot be specified with respect
JS> to all these restrictions. In particular, we have to emphasize even
JS> more that mixed case file names are *needed* by TeX.
RM> Unless I'm missing something crucial, mixed case file names are very nice
RM> to have, but cannot be allowed to be necessary. That is, if mixed case
RM> is needed to disambiguate between names, any ISO-9660 CD-ROM will fail.
I would agree with Rich here: I cannot see why Joachim argues that ``mixed
case file names are *needed* by TeX''; if that were true, I would be unable
to use TeX, since both of my OS/s of choice (VMS, MS/DOS) are case-insensitive.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:40:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 06:40:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141140.AA14916@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: story.tex/io.mf
> Concerning story.tex: This is the canonical TeXbook example, but
> I doubt if it will be of any use for ``other formats compatible with
> Plain''. Maybe this (and io.mf) really belong into the doc tree?
Since they do not contain macros, I agree with Ulrik that it should
go to the doc/ tree. Same with io.mf.
I'm confused. story.tex and io.mf are, as Ulrich says, the canonical examples.
So surely they must go in the tex/ and mf/ directories?
Otherwise, someone reading the TeXbook will type `tex story'
on the wonderful new TDS-compliant installation and be very perplexed.
tex/plain/misc and mf/misc?
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:43:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 06:43:46 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141143.AA14931@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: initex typesetting
> > The \replaceable{format} directory \path|hyphen| is reserved for
> > hyphenation patterns. Thes are used only by ini{\TeX} when a new
> ^^^^^^^^^ \application{INITEX}?
The canonical way to represent INITEX is by \texttt{INITEX}. See the
TeXbook and/or tugboat.cmn.
But maybe the TDS guide should be consistent with itself, and typeset
all program names the same way (in italics).
Since different program authors have different preferences (e.g., mine
is for `Web2c' in all roman), if the tds tries to please everyone, the
result will be inconsistent.
So, I think I agree with Ulrik here about the use of \application. (I'm
not sure I agree with `INITEX'; rather `initex'?)
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:48:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141148.MAA20744@spice.iti.informatik.th-darmstadt.de>
Subject: Re: nits & notes on 0.66
To: TWG-TDS@SHSU.edu
Date: Tue, 14 Mar 1995 12:48:30 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> I'm not sure what Joachim means by:
>
> But then we have to clarify that TDS cannot be specified with respect
> to all these restrictions. In particular, we have to emphasize even
> more that mixed case file names are *needed* by TeX.
What I meant was: There are files in standard TeX applications (e.g,
in LaTeX) that have mixed-case file names. They are read in by TeX;
i.e., somewhere is an "\input MixedCase.tex". The request for this
file must be resolved, i.e., mixed-case file names must be supported.
> Unless I'm missing something crucial, mixed case file names are very nice
> to have, but cannot be allowed to be necessary. That is, if mixed case
> is needed to disambiguate between names, any ISO-9660 CD-ROM will fail.
An ISO-9660 CD-ROM for Unix TeX without any further additional
installations (Rock Ridge, link farms) *will* fail.
> We rely on the operating system to map requests with these official
> names to the uppercase name on the CD. If that's not done properly
> (e.g., on Unix systems) we have to use external methods for that
> mapping (e.g., link farms).
>
> Aside from the value judgement implied by "properly", I'm in sync here.
I didn't want to imply a value judgement (please remember, I'm not a
native English speaker ;-). What I wanted to say was: There are
operating systems that can resolve requests for files with mixed-case
names by files they find on the CD-ROM. Examples are MS-DOS and VMS.
Other OSes don't do that. The most prominent example here is Unix.
(Are MacOS names case sensitive?)
> The above description leads to the impression that the TDS specifies
> the use of uppercase file names. It must not, as this is unfunctional,
> and therefore unacceptable.
>
> As I would put it, the TDS must specify that names of "registered TDS
> paths" must not conflict, even when case distinctions are ignored. This
> leaves room for individual sites and unregistered packages to get into
> trouble, but that's beyond our control, in any case.
Hmm, again we agree (almost), but that's another topic. Perhaps I have
to go into `blunt mode':
-- I'm against a TDS that _demands_ uppercase file names for each and
every TeX installations. If we add the ISO-9660 explanation to the
section `Constraints' that impression may occur.
-- I'm for a TDS that points out that CD-ROM distributions will most
probably use uppercase file names due to ISO-9660 and that there
must be some way to map the requests for mixed-case filenames (as
made by TeX) to the CD-ROM name space.
-- I'm against including the topic of registration in the TDS as it
stands now. Except if somebody steps forward and agrees to handle
this registration -- then I'm all in favor for it. I.e., we should
first find the guys who do the work before we spent the time to
specify the work.
Hope I was clearer this time,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 05:52:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141152.MAA18212@spice.iti.informatik.th-darmstadt.de>
Subject: Re: story.tex/io.mf
To: TWG-TDS@SHSU.edu
Date: Tue, 14 Mar 1995 12:52:50 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> I'm confused. story.tex and io.mf are, as Ulrich says, the canonical examples.
> So surely they must go in the tex/ and mf/ directories?
> Otherwise, someone reading the TeXbook will type `tex story'
Umpf, I forgot that this is really mentioned there (p.25). Forget my
comment.
> tex/plain/misc and mf/misc?
Why not base/? They belong to the basic stuff, distributed by DEK.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 06:04:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 11:55:42 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950314115542.2242a709@vms.rhbnc.ac.uk>
Subject: RE: Editorial comments on draft 0.66
[Ulrik Vieth writes:]
>> 2. HTML documents are intended to be read by programs (WWW browers)
>> and not by humans directly. The other files below texmf/doc such
>> as preformatted .dvi or .ps files (whatever is more appropriate)
>> can be accessed individually by invoking a viewer on the command
>> line, whereas HTML documents rely on the links between files and
>> cannot easily be accessed indvidually without a front-end.
I cannot honestly see the distinction here; neither DVI nor PS nor
HTML files can be meaningfully `read' without the use of a special
viewer; what is the essential difference between an DVI viewer,
a PostScript viewer, and an HTML `front-end'?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 06:34:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 95 13:03:47 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503141203.AA08433@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re-write of MetaPost section offered
I'm trying to send this again on a different route as we seem to have
some mailer problems here. (At least it didn't show up in the archives
even though our sendmail log claims to have delivered it successfully.)
Please ignore if you already received this.
----
As I'm the one responsible for bringing up this discussion about
metapost and metafont directory structure, I've volunteered to do a
re-write of the relevant sections that were left open in draft 0.66.
It may have ended up a bit verbose for the purpose of the TWG-TDS
because I have tried to explain what MetaPost is, what it does and
what files that involves, but that is just needed. You're welcome
to edit, rearrange or rewrite it as you feel appropriate.
I have also tried to update the overview figure to reflect the recent
changes for the metafont and metapost subdirectories, also adding a
few reserved directories such as texmf/hyphen and texmf/generic that
were missing in that figure.
I'll send editorial comments concerning the rest of the draft in a
separate message.
Cheers,
Ulrik.
P.S. I've also thrown in the latest version of my LaTeX 2e package
for the MF and MP logos, packaged using the filecomments environment.
If you already have an old version somewhere in your input path these
will not get unpacked. Perhaps it would be nice to have a variant of
filecomments that only looks in the current directory but not in the
rest of the input path when checking if a file exists. (David?)
Now, here it comes. Let's hope the long lines (>80 characters) in the
overview figure travel well...
%%% ====================================================================
%%% @TeX-file{
%%% author = "Ulrik Vieth",
%%% version = "0.666",
%%% date = "11 March 1995",
%%% time = "20:15:38 MET",
%%% filename = "tds-mp.tex",
%%% address = "",
%%% telephone = "",
%%% FAX = "",
%%% checksum = "61187 303 1637 12871",
%%% email = "vieth@thphy.uni-duesseldorf.de",
%%% codetable = "ISO/ASCII",
%%% keywords = "",
%%% supported = "",
%%% abstract = "This file contains a proposed re-write
%%% of the sections referring to METAFONT and
%%% METAPOST input files for the TWG-TDS draft.
%%% Feel free to rewrite it as you please.
%%% It might be a bit longer than absolutely
%%% necessary for the TWG-TDS draft because
%%% I have tried to explain what METAPOST is
%%% and what it does and what kinds of files
%%% it needs.",
%%% docstring = "The checksum field above contains a CRC-16
%%% checksum as the first value, followed by the
%%% equivalent of the standard UNIX wc (word
%%% count) utility output of lines, words, and
%%% characters. This is produced by Robert
%%% Solovay's checksum utility.",
%%% }
%%% ====================================================================
%% First, here are the latest versions of the |\MF| and |\MP| logos.
%%
%% Changes compared to the last released version involve using
%% |\DeclareRobustCommand| and |\DeclareTextFontCommand|
%% and fixing the space factor after the logos by adding |\@|.
%%
%% I haven't found time to rewrite the documentation for a public
%% release yet. Sorry!
\begin{filecontents}{mflogo.sty}
\NeedsTeXFormat{LaTeX2e}[1994/06/01]
\ProvidesPackage{mflogo}
[1994/12/26 v1.4b LaTeX package for METAFONT and METAPOST logos]
\DeclareRobustCommand\logofamily{%
\not@math@alphabet\logofamily\relax
\fontencoding{U}\fontfamily{logo}\selectfont}
\DeclareTextFontCommand{\textlogo}{\logofamily}
\def\MF{\textlogo{META}\-\textlogo{FONT}\@}
\def\MP{\textlogo{META}\-\textlogo{POST}\@}
\endinput
\end{filecontents}
\begin{filecontents}{Ulogo.fd}
\ProvidesFile{Ulogo.fd}
[1994/12/26 v1.4b LaTeX font defs for METAFONT and METAPOST logos]
\DeclareFontFamily{U}{logo}{}
\DeclareFontShape{U}{logo}{m}{n}{
<8> <9> gen * logo
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logo10
}{}
\DeclareFontShape{U}{logo}{m}{it}{
<8> <9> gen * logosl
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logosl10
}{}
\DeclareFontShape{U}{logo}{m}{sl}{
<-> ssub * logo/m/it
}{}
\DeclareFontShape{U}{logo}{sbc}{n}{
<8> <9> sub * logo/m/n
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logobf10
}{}
\DeclareFontShape{U}{logo}{b}{n}{
<8> <9> sub * logo/m/n
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logod10
}{}
\DeclareFontShape{U}{logo}{bx}{n}{
<-> ssub * logo/b/n
}{}
\endinput
\end{filecontents}
\documentclass{ltxguide}
\usepackage{alltt,path}
\usepackage{mflogo} % <- this must come before tdsguide.sty!
\usepackage{tdsguide}
\def\PS{Post\-Script} % <- maybe add this logo to tdsguide.sty?
\def\doctitle#1{\textit{#1}} % used instead of \emphasis below
%% Editorial notes: I've mostly tried to follow the markup
%% of tdsguide.tex, however I have a few questions:
%%
%% Why is it \textsc{TDS} instead of \acronym{TDS}?
%%
%% Why is it TWG instead of \textsc{TWG} or \acronym{TWG}?
%%
%% Why is it \emphasis{Document Title} and not a special tag
%% like \doctitle or some such thing?
%%
%% Why is it \application{Web2C}, but \command{dvips(k)}?
%% (I've used \application throughout in the following.)
\begin{document}
\setcounter{section}{4}
\section{Non-font {\MF} files}
Most {\MF} input files are fonts, however a few non-font input files
do exist (\path|null.mf|, \path|expr.mf|, and \path|modes.mf|, for
example).
The \acronym{TDS} specifies that these files shall be stored in:
\begin{quote}
\path|texmf/metafont/|\replaceable{package}\path|/|\replaceable{files}
\end{quote}
\replaceable{package} is the name of a group of related non-font
{\MF} files. There aren't many such files besides the standard
distribution, but some picture-drawing packages like \path|mfpic|
do exist that need to have a place in the \acronym{TDS} as well.
The following \replaceable{package} names are reserved:
\begin{itemize}
\item
\literal{base} is reserved for the standard {\MF} macros as described
in \doctitle{The {\MF}book}, such as \path|plain.mf|, \path|expr.mf|,
or the canonical example \path|io.mf|.
\item
\literal{misc} is reserved for {\MF} packages consisting of only
a single file or a small number of files.
\item
\literal{modes} is reserved for files containing {\MF} mode
descriptions for output devices, such as the quasi-canonical
\path|modes.mf| and any local mode definition files that might
be included by \application{INIMF} when dumping \ext{.base}
files containing preloaded macro definitions.
\end{itemize}
\replaceable{files} are the names of individual {\MF} files like
\path|plain.mf| or \path|null.mf|.
\section{{\MP} files}
{\MP} is a picture-drawing language developed by John Hobby that is
very much like Knuth's {\MF} except that it outputs {\PS} instead
of bitmaps. It is particularly well-suited for producing technical
figures for inclusion into {\TeX} or \application{troff} documents
to be printed on {\PS} printers. It provides easy access to all
major features of the {\PS} language and it has facilities for
integrating typeset text and graphics. Knuth says he loves it.
Textual material in labels is handled by invoking a shell script
that, in turn, relies on either {\TeX} or \application{troff} and
some utility programs based on \application{dvitype} to produce
a low-level {\MP} representation of the typeset text.%
\footnote{In the past {\MP} used to be available only under
non-disclosure agreement from \acronym{AT\&T}, but it was placed in
the public domain with the beginning of this year. It is currently
available only on Unix platforms using the \application{Web2C}
implementation, but it is hoped that it will be ported to other
platforms as well, so that it will eventually become a standard
utility.}
{\MP} uses the extension \ext{.mp} for its input files and \ext{.mpx}
for the generated low-level input files representing included textual
material. It outputs a series of PostScript files, one for each
figure, that can easily be included into {\TeX} documents via
\application{dvips}.
The \acronym{TDS} specifies that the {\MP} input files and the support
files for {\MP}-related utilities shall be stored in:
\begin{quote}
\path|texmf/metapost/|\replaceable{package}\path|/|\replaceable{files}
\end{quote}
\replaceable{package} is the name of a group of related {\MP} files.
At the moment there aren't any besides the standard distribution,
but the \acronym{TWG} thought it wise to leave room for contributed
packages that might be written in the future.
The following \replaceable{package} names are reserved:
\begin{itemize}
\item
\literal{base} is reserved for the standard macros that come with
{\MP} as described in the documents \doctitle{A User's Manual
for MetaPost} and \doctitle{Drawing Graphs with MetaPost} by
John Hobby,%
\footnote{Both documents are available as CSTR~162 and~164
from \path|ftp.netlib.att.com|. They are also included
as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
distribution.}
such as \path|plain.mp|, \path|mfplain.mp|, \path|boxes.mp|,
\path|graph.mp|, \path|string.mp|, etc.
This includes files used by \application{INIMP} when dumping
\ext{.mem} files containing preloaded macro definitions.
\item
\literal{misc} is reserved for {\MP} packages consisting of only
a single file or a small number of files.
\item
\literal{support} is reserved for some special files required by the
{\MP} utility programs when operating in \application{troff} mode.
These include things like a font map, a character adjustment table
and a subdirectory containing low-level {\MP} programs for rendering
some special characters.
Strictly speaking, these files are used only by the
\application{troff} support programs, so they needn't be searched
for by {\MP} directly. However, the \acronym{TWG} concluded that it
wouldn't be worth introducing another subdirectory level just to
make a distinction between {\MP} macro files and support files. The
overhead for searching this directory unnecessarily seems negligible
compared to the running time of {\MP}, especially when this involves
invoking {\TeX} in a sub-process for typesetting labels.
\end{itemize}
\replaceable{files} are the names of individual {\MP} files like
\path|plain.mp| or \path|null.mp| (once that is written). {\MP} can
also process {\MF} input files and searches the {\MF} input paths
as well when invoked on a {\MF} file such as \path|logo10.mf|.
\setcounter{section}{9}
\section{Summary}
Here's an overview figure summarizing the \acronym{TDS} tree.
(A longer directory listing from a real but small system should
presumably go into the very last appendix.)
%% Changes:
%%
%% * added new subdirectories below metafont/ and metapost/
%%
%% * added tex/hyphen/ and tex/generic/ that were missing
%%
%% * added tex/format/config that was also missing
%%
%% * added more examples in comments, also some corrections
%%
%% * realigned indentation levels (perhaps a bit too much?)
%%
%% * made figure \small to avoid breaking it across pages
%%
%% * new top-level texmf/html/ directory for hypertext docs
%% is that OK? if so, it should be added to sec. 2.4 as well!
\begin{small}
\begin{alltt}
\replaceable{texmf}/ top-level directory for TDS tree
. bibtex/ BibTeX input files
. . bib/ databases of common interest
. . bst/ style files
. bin/*/ binaries, by system type
. doc/ user documentation
. . \replaceable{format}/ name of a format (e.g., plain, eplain, amstex, latex)
. . . base/ documentation of base distribution for format
. . . misc/ documentation of single-file packages
. . . \replaceable{package}/ doucmentation of packages (e.g., graphics, amslatex)
. . general/ standalone documents
. . help/ meta-information (FAQs, etc.)
. . \replaceable{program}/ TeX applications, by name (e.g., makeindx)
. fonts/ font-related files
. . \replaceable{type}/ file type (e.g., pk, vf, source, type1)
. . . \replaceable{supplier}/ name of a font supplier (e.g., adobe, ams, public)
. . . . \replaceable{typeface}/ name of a typeface (e.g., cm, euler, latex, times)
. . . . . \replaceable{mode}/ type of output device (type pk and gf only)
. . . . . . \replaceable{dpi}/ font resolution (type pk and gf only)
. html/ hypertext docs (produced by e.g., texi2html or latex2html)
. info/ processed Texinfo documents
. man/ Unix-style manual pages
. metafont/ METAFONT (non-font) input files
. . base/ base distribution
. . misc/ single-file packages
. . modes/ mode definition files (e.g., modes.mf, local modes)
. . \replaceable{package}/ name of a package (e.g., mfpic)
. metapost/ METAPOST input and support files
. . base/ base distribution
. . misc/ single-file packages
. . \replaceable{package}/ name of a package (for future use)
. . support/ support files for METAPOST-related utiltities
. \replaceable{program}/ TeX applications, by name (e.g., makeindex)
. source/ program source code
. tex/ TeX input files
. . \replaceable{format}/ name of a format (e.g., plain, eplain, amstex, latex)
. . . base/ base distribution for format
. . . config/ configuration files for format
. . . misc/ single-file packages
. . . \replaceable{package}/ name of a package (e.g., graphics, amslatex)
. . generic/ format-independent packages
. . . misc/ single-file format-independent packages
. . . \replaceable{package}/ name of a package (e.g., babel, german)
. . hyphen/ hyphenation patterns
. . . \replaceable{language}/ name of a language
\end{alltt}
\end{small}
\end{document}
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 07:52:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 08:47:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503141347.IAA16795@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Re-write of MetaPost section offered
References: <9503141203.AA08433@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 13:03:47, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> %% Editorial notes: I've mostly tried to follow the markup
> %% of tdsguide.tex, however I have a few questions:
Ulrik,
The TeX document is not the source for the tdsguide. The *real* source
is the SGML files. The variations you note in tdsguide.tex are the
(mostly) result of different filtering:
> %% Why is it \textsc{TDS} instead of \acronym{TDS}?
No good reason; I just filtered it that way
> %% Why is it TWG instead of \textsc{TWG} or \acronym{TWG}?
Oversight on my part.
> %% Why is it \emphasis{Document Title} and not a special tag
> %% like \doctitle or some such thing?
Because I wanted italics and I knew that \emphasis would do it :-(
> %% Why is it \application{Web2C}, but \command{dvips(k)}?
> %% (I've used \application throughout in the following.)
I generally use \command{} for things that you can actually type at
a prompt and application{} for a larger suite. In MS-DOS terms, for
example, I would say \application{WordPerfect} and \command{wp}.
Cheers,
norm
P.S. I'll integrate your contribution into the next draft.
---
Norman Walsh <norm@ora.com> | A successful tool is one that was used to do
Production Tools Specialist | something undreamed of by its author. -- S. C.
O'Reilly & Associates, Inc. | Johnson
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 08:08:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 95 13:03:47 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503141203.AA08433@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re-write of MetaPost section offered
I'm trying to send this again on a different route as we seem to have
some mailer problems here. (At least it didn't show up in the archives
even though our sendmail log claims to have delivered it successfully.)
Please ignore if you already received this.
----
As I'm the one responsible for bringing up this discussion about
metapost and metafont directory structure, I've volunteered to do a
re-write of the relevant sections that were left open in draft 0.66.
It may have ended up a bit verbose for the purpose of the TWG-TDS
because I have tried to explain what MetaPost is, what it does and
what files that involves, but that is just needed. You're welcome
to edit, rearrange or rewrite it as you feel appropriate.
I have also tried to update the overview figure to reflect the recent
changes for the metafont and metapost subdirectories, also adding a
few reserved directories such as texmf/hyphen and texmf/generic that
were missing in that figure.
I'll send editorial comments concerning the rest of the draft in a
separate message.
Cheers,
Ulrik.
P.S. I've also thrown in the latest version of my LaTeX 2e package
for the MF and MP logos, packaged using the filecomments environment.
If you already have an old version somewhere in your input path these
will not get unpacked. Perhaps it would be nice to have a variant of
filecomments that only looks in the current directory but not in the
rest of the input path when checking if a file exists. (David?)
Now, here it comes. Let's hope the long lines (>80 characters) in the
overview figure travel well...
%%% ====================================================================
%%% @TeX-file{
%%% author = "Ulrik Vieth",
%%% version = "0.666",
%%% date = "11 March 1995",
%%% time = "20:15:38 MET",
%%% filename = "tds-mp.tex",
%%% address = "",
%%% telephone = "",
%%% FAX = "",
%%% checksum = "61187 303 1637 12871",
%%% email = "vieth@thphy.uni-duesseldorf.de",
%%% codetable = "ISO/ASCII",
%%% keywords = "",
%%% supported = "",
%%% abstract = "This file contains a proposed re-write
%%% of the sections referring to METAFONT and
%%% METAPOST input files for the TWG-TDS draft.
%%% Feel free to rewrite it as you please.
%%% It might be a bit longer than absolutely
%%% necessary for the TWG-TDS draft because
%%% I have tried to explain what METAPOST is
%%% and what it does and what kinds of files
%%% it needs.",
%%% docstring = "The checksum field above contains a CRC-16
%%% checksum as the first value, followed by the
%%% equivalent of the standard UNIX wc (word
%%% count) utility output of lines, words, and
%%% characters. This is produced by Robert
%%% Solovay's checksum utility.",
%%% }
%%% ====================================================================
%% First, here are the latest versions of the |\MF| and |\MP| logos.
%%
%% Changes compared to the last released version involve using
%% |\DeclareRobustCommand| and |\DeclareTextFontCommand|
%% and fixing the space factor after the logos by adding |\@|.
%%
%% I haven't found time to rewrite the documentation for a public
%% release yet. Sorry!
\begin{filecontents}{mflogo.sty}
\NeedsTeXFormat{LaTeX2e}[1994/06/01]
\ProvidesPackage{mflogo}
[1994/12/26 v1.4b LaTeX package for METAFONT and METAPOST logos]
\DeclareRobustCommand\logofamily{%
\not@math@alphabet\logofamily\relax
\fontencoding{U}\fontfamily{logo}\selectfont}
\DeclareTextFontCommand{\textlogo}{\logofamily}
\def\MF{\textlogo{META}\-\textlogo{FONT}\@}
\def\MP{\textlogo{META}\-\textlogo{POST}\@}
\endinput
\end{filecontents}
\begin{filecontents}{Ulogo.fd}
\ProvidesFile{Ulogo.fd}
[1994/12/26 v1.4b LaTeX font defs for METAFONT and METAPOST logos]
\DeclareFontFamily{U}{logo}{}
\DeclareFontShape{U}{logo}{m}{n}{
<8> <9> gen * logo
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logo10
}{}
\DeclareFontShape{U}{logo}{m}{it}{
<8> <9> gen * logosl
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logosl10
}{}
\DeclareFontShape{U}{logo}{m}{sl}{
<-> ssub * logo/m/it
}{}
\DeclareFontShape{U}{logo}{sbc}{n}{
<8> <9> sub * logo/m/n
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logobf10
}{}
\DeclareFontShape{U}{logo}{b}{n}{
<8> <9> sub * logo/m/n
<10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> logod10
}{}
\DeclareFontShape{U}{logo}{bx}{n}{
<-> ssub * logo/b/n
}{}
\endinput
\end{filecontents}
\documentclass{ltxguide}
\usepackage{alltt,path}
\usepackage{mflogo} % <- this must come before tdsguide.sty!
\usepackage{tdsguide}
\def\PS{Post\-Script} % <- maybe add this logo to tdsguide.sty?
\def\doctitle#1{\textit{#1}} % used instead of \emphasis below
%% Editorial notes: I've mostly tried to follow the markup
%% of tdsguide.tex, however I have a few questions:
%%
%% Why is it \textsc{TDS} instead of \acronym{TDS}?
%%
%% Why is it TWG instead of \textsc{TWG} or \acronym{TWG}?
%%
%% Why is it \emphasis{Document Title} and not a special tag
%% like \doctitle or some such thing?
%%
%% Why is it \application{Web2C}, but \command{dvips(k)}?
%% (I've used \application throughout in the following.)
\begin{document}
\setcounter{section}{4}
\section{Non-font {\MF} files}
Most {\MF} input files are fonts, however a few non-font input files
do exist (\path|null.mf|, \path|expr.mf|, and \path|modes.mf|, for
example).
The \acronym{TDS} specifies that these files shall be stored in:
\begin{quote}
\path|texmf/metafont/|\replaceable{package}\path|/|\replaceable{files}
\end{quote}
\replaceable{package} is the name of a group of related non-font
{\MF} files. There aren't many such files besides the standard
distribution, but some picture-drawing packages like \path|mfpic|
do exist that need to have a place in the \acronym{TDS} as well.
The following \replaceable{package} names are reserved:
\begin{itemize}
\item
\literal{base} is reserved for the standard {\MF} macros as described
in \doctitle{The {\MF}book}, such as \path|plain.mf|, \path|expr.mf|,
or the canonical example \path|io.mf|.
\item
\literal{misc} is reserved for {\MF} packages consisting of only
a single file or a small number of files.
\item
\literal{modes} is reserved for files containing {\MF} mode
descriptions for output devices, such as the quasi-canonical
\path|modes.mf| and any local mode definition files that might
be included by \application{INIMF} when dumping \ext{.base}
files containing preloaded macro definitions.
\end{itemize}
\replaceable{files} are the names of individual {\MF} files like
\path|plain.mf| or \path|null.mf|.
\section{{\MP} files}
{\MP} is a picture-drawing language developed by John Hobby that is
very much like Knuth's {\MF} except that it outputs {\PS} instead
of bitmaps. It is particularly well-suited for producing technical
figures for inclusion into {\TeX} or \application{troff} documents
to be printed on {\PS} printers. It provides easy access to all
major features of the {\PS} language and it has facilities for
integrating typeset text and graphics. Knuth says he loves it.
Textual material in labels is handled by invoking a shell script
that, in turn, relies on either {\TeX} or \application{troff} and
some utility programs based on \application{dvitype} to produce
a low-level {\MP} representation of the typeset text.%
\footnote{In the past {\MP} used to be available only under
non-disclosure agreement from \acronym{AT\&T}, but it was placed in
the public domain with the beginning of this year. It is currently
available only on Unix platforms using the \application{Web2C}
implementation, but it is hoped that it will be ported to other
platforms as well, so that it will eventually become a standard
utility.}
{\MP} uses the extension \ext{.mp} for its input files and \ext{.mpx}
for the generated low-level input files representing included textual
material. It outputs a series of PostScript files, one for each
figure, that can easily be included into {\TeX} documents via
\application{dvips}.
The \acronym{TDS} specifies that the {\MP} input files and the support
files for {\MP}-related utilities shall be stored in:
\begin{quote}
\path|texmf/metapost/|\replaceable{package}\path|/|\replaceable{files}
\end{quote}
\replaceable{package} is the name of a group of related {\MP} files.
At the moment there aren't any besides the standard distribution,
but the \acronym{TWG} thought it wise to leave room for contributed
packages that might be written in the future.
The following \replaceable{package} names are reserved:
\begin{itemize}
\item
\literal{base} is reserved for the standard macros that come with
{\MP} as described in the documents \doctitle{A User's Manual
for MetaPost} and \doctitle{Drawing Graphs with MetaPost} by
John Hobby,%
\footnote{Both documents are available as CSTR~162 and~164
from \path|ftp.netlib.att.com|. They are also included
as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
distribution.}
such as \path|plain.mp|, \path|mfplain.mp|, \path|boxes.mp|,
\path|graph.mp|, \path|string.mp|, etc.
This includes files used by \application{INIMP} when dumping
\ext{.mem} files containing preloaded macro definitions.
\item
\literal{misc} is reserved for {\MP} packages consisting of only
a single file or a small number of files.
\item
\literal{support} is reserved for some special files required by the
{\MP} utility programs when operating in \application{troff} mode.
These include things like a font map, a character adjustment table
and a subdirectory containing low-level {\MP} programs for rendering
some special characters.
Strictly speaking, these files are used only by the
\application{troff} support programs, so they needn't be searched
for by {\MP} directly. However, the \acronym{TWG} concluded that it
wouldn't be worth introducing another subdirectory level just to
make a distinction between {\MP} macro files and support files. The
overhead for searching this directory unnecessarily seems negligible
compared to the running time of {\MP}, especially when this involves
invoking {\TeX} in a sub-process for typesetting labels.
\end{itemize}
\replaceable{files} are the names of individual {\MP} files like
\path|plain.mp| or \path|null.mp| (once that is written). {\MP} can
also process {\MF} input files and searches the {\MF} input paths
as well when invoked on a {\MF} file such as \path|logo10.mf|.
\setcounter{section}{9}
\section{Summary}
Here's an overview figure summarizing the \acronym{TDS} tree.
(A longer directory listing from a real but small system should
presumably go into the very last appendix.)
%% Changes:
%%
%% * added new subdirectories below metafont/ and metapost/
%%
%% * added tex/hyphen/ and tex/generic/ that were missing
%%
%% * added tex/format/config that was also missing
%%
%% * added more examples in comments, also some corrections
%%
%% * realigned indentation levels (perhaps a bit too much?)
%%
%% * made figure \small to avoid breaking it across pages
%%
%% * new top-level texmf/html/ directory for hypertext docs
%% is that OK? if so, it should be added to sec. 2.4 as well!
\begin{small}
\begin{alltt}
\replaceable{texmf}/ top-level directory for TDS tree
. bibtex/ BibTeX input files
. . bib/ databases of common interest
. . bst/ style files
. bin/*/ binaries, by system type
. doc/ user documentation
. . \replaceable{format}/ name of a format (e.g., plain, eplain, amstex, latex)
. . . base/ documentation of base distribution for format
. . . misc/ documentation of single-file packages
. . . \replaceable{package}/ doucmentation of packages (e.g., graphics, amslatex)
. . general/ standalone documents
. . help/ meta-information (FAQs, etc.)
. . \replaceable{program}/ TeX applications, by name (e.g., makeindx)
. fonts/ font-related files
. . \replaceable{type}/ file type (e.g., pk, vf, source, type1)
. . . \replaceable{supplier}/ name of a font supplier (e.g., adobe, ams, public)
. . . . \replaceable{typeface}/ name of a typeface (e.g., cm, euler, latex, times)
. . . . . \replaceable{mode}/ type of output device (type pk and gf only)
. . . . . . \replaceable{dpi}/ font resolution (type pk and gf only)
. html/ hypertext docs (produced by e.g., texi2html or latex2html)
. info/ processed Texinfo documents
. man/ Unix-style manual pages
. metafont/ METAFONT (non-font) input files
. . base/ base distribution
. . misc/ single-file packages
. . modes/ mode definition files (e.g., modes.mf, local modes)
. . \replaceable{package}/ name of a package (e.g., mfpic)
. metapost/ METAPOST input and support files
. . base/ base distribution
. . misc/ single-file packages
. . \replaceable{package}/ name of a package (for future use)
. . support/ support files for METAPOST-related utiltities
. \replaceable{program}/ TeX applications, by name (e.g., makeindex)
. source/ program source code
. tex/ TeX input files
. . \replaceable{format}/ name of a format (e.g., plain, eplain, amstex, latex)
. . . base/ base distribution for format
. . . config/ configuration files for format
. . . misc/ single-file packages
. . . \replaceable{package}/ name of a package (e.g., graphics, amslatex)
. . generic/ format-independent packages
. . . misc/ single-file format-independent packages
. . . \replaceable{package}/ name of a package (e.g., babel, german)
. . hyphen/ hyphenation patterns
. . . \replaceable{language}/ name of a language
\end{alltt}
\end{small}
\end{document}
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 08:09:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 14 Mar 1995 09:09:24 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments on draft 0.66
To: TWG-TDS@SHSU.edu
Message-ID: <795190164.853367.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
some responses to ulrik's questions ...
* sec. 4:
> \item[\replaceable{supplier}]
> is the name of the font supplier or \path|public|.
> The \path|public| serves a practical
> purpose; it designates fonts for which there are no licensing problems
> if/when they are redistributed.
> \path|adobe|, \path|amsfonts|,
^^^^^^^^^^^^^^^
> \path|monotype|, and \path|public| are
> examples of \replaceable{supplier}.
Why `amsfonts' here? I'd say the supplier is `ams' as an organization.
in this context, yes, it's probably better to say `ams'.
* sec. 4:
> \item[\replaceable{typeface}]
> is the name of the typeface family. \path|cm|,
> \path|latex|, \path|amsfonts|, \path|concrete|,
^^^^^^^^^^^^^^^
> \path|bookman|, and \path|courier| are
> examples of \replaceable{typeface}.
There is no such typeface `amsfonts'. `ams' is a supplier for serveral
typefaces such as `euler', `symbols', `cyrillic'. BTW, what about
typefaces consisting of a single file such as dummy.tfm? Where does
that go? (Barbara?)
how about `name of the typeface family or collection'? we do think
of amsfonts as a collection, and actually, cm is really a collection
and not a single family (i'd consider cmfib, cmff, cmdunh to be
different families, but implemented using cmbase, the cm character
descriptions and radically different parameters).
dummy.tfm is not a typeface -- it's only metrics (everything is zero),
a special-purpose entity whose sole purpose in existence is to enable
syntax checking by disabling all the calculations related to fonts.
since it's a .tfm file, it belongs with .tfm files. (it used to be
created from a .pl file, but that was too complicated to explain, and
it was always getting lost when people installed it, resulting in a
lot of questions, so we cobbled together a .mf file to generate it.)
it is required by ams-tex, and (i believe) by ams-latex, so it's
gotta go into the ams area. i think giving it a directory by itself
gives it too much prominence; on e-math, we don't put it into any
of the subdivisions (cyrillic, euler, etc.), but leave the .mf file
in the directory above them. inconsistent. i can discuss it here,
but don't expect any conclusive response before the end of the week.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 11:30:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 11:30:34 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503141630.AA20269@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: story.tex/io.mf
> tex/plain/misc and mf/misc?
Why not base/? They belong to the basic stuff, distributed by DEK.
Ok, base/.
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 13:36:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 14:31:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503141931.OAA05352@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <199503101732.SAA19179@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 18:32:08, Joachim Schrod wrote:
> Norm wrote:
> >
> > > [package names]
> > >
> > > babel is generic, too...
> > > amslatex is a good LaTeX package example.
> > > And `tools' if I think about it. That might make it clear that the
> > > term _package_ in this context is something different than a LaTeX2e
> > > _package_.
> >
> > What do you mean by 'tools'? I'm confused...
>
> I mean the files that are on CTAN in macros/latex/packages/tools/.
> {verbatim,array,multicol}.sty, etc.
>
> The point here is:
> -- The TDS document uses the term `package' in its usual sense: As a
> unit of distribution and maintenance.
> -- The LaTeX team in their great wisdom[*] uses the term `package'
> for macro modules. Once, I proposed the term `bundle' for a
> distribution unit in that domain.
>
> I.e., `TDS package' \ne `LaTeX2e package'.
>
> I still think, somewhere should be footnote that points out this
> distinction. I expect that LaTeX users without any knowledge of TeX's
> inner working will get confused by this mixup when they read the TDS
> document.
I guess I don't understand the LaTeX usage; can you suggest where the
footnote should go and what it should say?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 13:59:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503142000.VAA20200@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Editorial comments
To: TWG-TDS@SHSU.edu
Date: Tue, 14 Mar 1995 20:59:59 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> On 10 March 1995 at 18:32:08, Joachim Schrod wrote:
> >
> > I.e., `TDS package' \ne `LaTeX2e package'.
> >
> > I still think, somewhere should be footnote that points out this
> > distinction.
>
> I guess I don't understand the LaTeX usage; can you suggest where the
> footnote should go and what it should say?
I would add it to at the end of the first paragraph of the item
`package' (that's on page 8 in 0.66). Hmm, how about...
<footnote>
<replacable>packages</> as described in this document are
<emphasis>not</> &LaTeXe; packages, even though there exist &LaTeX;
packages of the names listed above. &LaTeX; packages are style files
that add more macro code to document classes. &TDS; packages are a
set of files that is distributed, installed, and maintained as a
unit. In the &LaTeX; universe the term <emphasis>bundle</>
is sometimes used for such units.
</footnote>
Some remarks:
-- You might want to shorten it. E.g., the last sentence can be
considered as superfluous.
-- Caveat: I used a &LaTeXe; entity above.
Cheers,
Joachim
PS: A report about a proposed minimal content for distribution of
LaTeX2e bundles is available as
ftp://ftp.th-darmstadt.de/pub/tex/latex/bundle-dist.tex.gz. The CTAN
folks have seen it before, but the rest may be interested, too.
(sebastian, I couldn't find the memo on CTAN. What happened?)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================