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