Editorial comments on draft 0.66
Norman Walsh
norm@ora.com
Tue, 14 Mar 1995 15:21:46 -0500
On 13 March 1995 at 10:35:25, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> Here are some editorial comments on draft 0.66. Most of them are
> minor corrections, etc. However, there's one new suggestion below
> that I want to put forward for general consideration:
>
> What about a top-level texmf/html directory for hypertext online
> documentation produced by utilities like texi2html or latex2html?
I'm game. Karl gave good arguments (pro and con ;-) for either a top
level directory or for putting the whole info, man, html group under
"doc".
Let's leave them in the top level for now, and see if they proliferate
further.
> (BTW, where do the .texi files go? texmf/doc or texmf/source?)
texmf/doc would be my choice.
> * global:
>
> Use \acronym instead of \textsc for TDS, also for TWG, CTAN, ...
Ok.
> Check usage of \path|...| vs. \literal{...} for reserved directories.
Ok.
> * sec. 1.2:
>
> > In this document, ``{\TeX}'' generally means ``the {\TeX} system, including
> > {\protect\MF}, \path|DVI| drivers, utilities, etc.,'' not just the {\TeX}
> ^ Maybe insert {\protect\MP} here as well?
> Not sure if we want to give it that much prominence!
> > program itself.
>
> (If you use my LaTeX 2e package for \MF and \MP, you don't need
> \protect anymore for those logos!)
It's easier for the filter to always output the protects. But I will
use your definitions ;-)
> * sec. 1.2:
>
> > \item[\command{command}]
> > Commands are typeset in italics.
> > \item[\application{application}]
> > Applications, like commands, are typeset in italics.
>
> What's exactly the difference between commands and applications?
I covered that before. I'm game for dropping one or the other if
everyone else wants to.
> > \item[\literal{literal}]
> > Literal text is typeset in typewriter type.
>
> Unfortunately, this is used quite inconsistently with \path|literal|.
Use of \path|| was an afterthought suggested by Joachim. But the
'Conventions' section actually does differentiate between \path|| for
filenames and \literal{} for literals.
> * sec. 2.1:
>
> > This feature is already supported by many implementations of
> > {\TeX} tools including, but not limited to, em{\TeX} (and its drivers),
> ^^^^^^^^
> > Public{\TeX}, \application{Web2C}, Y\&Y{\TeX}, \command{dvips(k)},
> ^^^^^^^^^^^^
> > \command{xdvi(k)}, and DECUS {\TeX} for VMS.
> ^^^^^ ^^^
> Maybe \application{em{\TeX}} and \application{PubliC~{\TeX}}?
> (I think it's two words and `PubliC' with uppercase C -> PC.)
Ok.
> Also use \acronym for DECUS and VMS here, it's already used
> for VMS elsewhere.
Ok.
> * sec. 2.3:
>
> > The root of the \textsc{TDS} should be a directory containing only
> > {\TeX}-related
> > materials. In this document, we shall designate this directory
> > \path|texmf|, but the exact name
> > of the directory is up to the installer. On PC networks, for example,
> ^^ Use \acronym{PC}?
Ok.
> > The name \path|texmf| was chosen for several reasons:
> > it reflects the fact that the directory contains files to an entire
> > {\TeX} system, (including {\protect\MF}, {\protect\BibTeX}, etc.,
> ^ Again the question whether to
> insert {\protect\MP} here?
> Perhaps not, if we keep texmf!
We're keeping texmf! ;-) But I'll stick in MP.
> > \item[\path|metapost|]
> > for \application{MetaPost} files.
> ^^^^^^^^^^^^^^^^^^^^^^ {\protect\MP}
Check
> Add the sentence: (see \xref{Section 6, {\protect\MP} Files})
Check
>
> * sec. 2.4:
>
> \item[\replaceable{program}]
> > for {\TeX} applications. It may be convenient to store
> > implementations (em{\TeX}, PC{\TeX}, etc.) as well as utilities
> ^^^^^^^^ ^^^^^^^^ \application
> > (dvips, MakeIndex, etc.) in their own directories. Implementations
> ^^^^^ ^^^^^^^^^ \application
> > can store configuration files, compiled format files, {\protect\MF}
> ^ Insert: {\TeX}
> > bases, DLLs, etc. in their own directory. Utilities can store
> ^ Insert: {\protect\MP} mems,
> > configuration files, input files, etc. in their own directory.
Check
> Maybe add the following item?
>
> ! \item[\path|html|]
> ! for hypertext documentation, produced e.g. by \application{texi2html}
> ! or \application{latex2html}.
Check.
> > \item[\path|source|]
> > for sources. For example \path|texmf/source/web2c|
> > and the \path|dtx| sources for {\LaTeX}.
>
> These are two quite different types of sources, aren't they?
> Maybe elaborate a bit that dtx files are also documentation sources?
Yes.
> * sec. 3:
>
> > The \replaceable{format} directory \path|hyphen| is reserved for
> > hyphenation patterns. Thes are used only by ini{\TeX} when a new
> ^^^^^^^^^ \application{INITEX}?
Ok.
> * sec. 3:
>
> Concerning story.tex: This is the canonical TeXbook example, but
> I doubt if it will be of any use for ``other formats compatible with
> Plain''. Maybe this (and io.mf) really belong into the doc tree?
> Or maybe in both places, so that users still can run it. (The same
> applies for the canonical LaTeX examples small2e.tex and sample2e.tex.)
They mustn't go in two places, and they need to be in the tex tree,
so we'll put them in base, I guess.
> > \item[\replaceable{package}]
> > is the name of a package.
> > \path|amstex|, \path|amslatex|, \path|babel|,
> ^^^^^^^^^^^^^
> > and \path|fancyheadings| are examples of \replaceable{packages}.
>
> Isn't that a format as it was stated before?
Oops.
> * sec. 3:
>
> > The package name \literal{base} is reserved for the base
> > distribution for each format. Files used by ini{\TeX} to construct
> ^^^^^^^^^ \application{INITEX}?
Check.
> > format files should also be stored in the \literal{base} directory.
> > For example, in the new standard {\LaTeX} distribution, the
> > \path|*.ltx| files created during the build process should be
> ^^^^^^^^^^^^ cf. \path |dtx| sources, should it be: \path|ltx| files?
Yes.
> > \item
> > The \replaceable{format} directory \path|config| is reserved for
> ^^^^^^ package!
Check.
> > \item[\path|vf|]
> > virtual font metrics
> ^^^^^^^
> Why metrics? I thought that vf files contained only typesetting
> instructions in some sort of symbolic DVI code, but they still
> used TFM files as font metrics taken from the raw fonts. (Alan?)
Yep, just a typo on my part.
> * sec. 4:
>
> > \item[\replaceable{supplier}]
> > is the name of the font supplier or \path|public|.
> > The \path|public| serves a practical
> > purpose; it designates fonts for which there are no licensing problems
> > if/when they are redistributed.
> > \path|adobe|, \path|amsfonts|,
> ^^^^^^^^^^^^^^^
> > \path|monotype|, and \path|public| are
> > examples of \replaceable{supplier}.
>
> Why `amsfonts' here? I'd say the supplier is `ams' as an organization.
Barbara made some comments in a later mail that I'm not looking at at the
moment, so maybe this has changed. But the reason I wrote it this way
is because the AMS wanted their three distributions clearly seperated,
so they got amslatex, asmtex, and amsfonts.
I'm happy with it either way. If the AMS wants to supply fonts under the
moniker "amsfonts", I'm not going to argue with them ;-)
> > \item[\replaceable{typeface}]
> > is the name of the typeface family. \path|cm|,
> > \path|latex|, \path|amsfonts|, \path|concrete|,
> ^^^^^^^^^^^^^^^
> > \path|bookman|, and \path|courier| are
> > examples of \replaceable{typeface}.
>
> There is no such typeface `amsfonts'. `ams' is a supplier for serveral
True.
> typefaces such as `euler', `symbols', `cyrillic'. BTW, what about
> typefaces consisting of a single file such as dummy.tfm? Where does
> that go? (Barbara?)
texmf/fonts/tfm/cm/misc/dummy.tfm, I think.
> > contains precisely the 75 fonts defined in \emphasis{Computers and
> ^^^^^^^^^ \doctitle?
Yeah, I was lazy.
> > Typesetting, Volumes A-E}. The \path|latex| typeface directory
> ^^^^^^^^^^^^ only Volume E is relevant for this!
Really?
> > contains only the fonts distributed by the {\AmS}.
> ^^^^^^ why the logo here?
No good reason ;-)
> > There are two reserved categories:
> > \path|help| for metainformation, such as \acronym{FAQ}'s,
> ^^^^^^^^^^^^^^^ meta-information (with a hyphen)?
Ok.
> > David Jones' macro index, etc., and \path|general| for standalone
> stand-alone (with a hyphen)? ^^^^^^^^^^
I'm less confident, but sure.
> > documents not part of any package: Michael Doob's
> > \emphasis{A Gentle Introduction to {\TeX}},
> ^^^^^^^^^ \doctitle?
> > Joachim Schrod's \emphasis{Components of {\TeX}},
> ^^^^^^^^^ \doctitle
Yeah.
> > \path|texbook.tex| and \path|mfbook.tex|, etc.
>
> What about the canonical examples: story.tex, io.mf, etc.? Do they
> go here as well, or better in the relevant format/base subdirectory?
formats/base
> Maybe texbook.tex (and story.tex) belong into texmf/doc/tex/plain/base
texbook.tex doesn't...you aren't supposed to format it!
> > Files below the \replaceable{package} level are determined by the
> > documentation author. The documentation directory may contain {\TeX}
> > sources, \path|DVI| files, text files, or whatever form
> ^ Maybe add \path|PS| files here as well?
Ok.
> > of documentation will best explain the package.
>
> * sec. 9:
>
> > texmf/fonts/martian/source/martian.mf
> > texmf/fonts/martian/source/mart10.mf
> > texmf/fonts/martian/tfm/mart10.tfm
>
> Hmmm, hasn't that been changed into:
> texmf/fonts/source/martian/martian.mf
> texmf/fonts/source/martian/mart10.mf
> texmf/fonts/tfm/martian/mart10.tfm
Yes.
> And shouldn't there be a supplier as well as a typeface name,
> so maybe it's really:
> texmf/fonts/source/public/martian/martian.mf
> texmf/fonts/source/public/martian/mart10.mf
> texmf/fonts/tfm/public/martian/mart10.tfm
Close:
texmf/fonts/source/public/*
texmf/fonts/tfm/public/*
> The figure currently misses the new directories below metafont/
> and metapost/. It also misses tex/hyphen/, tex/generic/ and
> tex/format/config. I've provided an updated version (see elsewhere).
Great.
> P.S. It seems we are nearing a final version. Perhaps we should bump
> the version number to 0.90 and set a target such as 0.99 for a public
> release. (If that fails, we could still go to version 0.999999, though!)
If we go to 0.9, we'll only discover that it takes 10 revisions to fix
the last typo.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:32:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:27:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142027.PAA06450@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: nits & notes on 0.66
References: <199503111311.OAA12079@spock.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 11 March 1995 at 14:11:28, Joachim Schrod wrote:
> The description is very good, and I would like to see it in the
> document. An appendix would be good place for it, we could then
> shorten the `Constraints' section with a pointer to that appendix.
Why move it to an appendix?
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:48:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:43:20 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142043.PAA06622@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: nits & notes on 0.66
References: <9503110052.AA04892@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 10 March 1995 at 16:52:56, Rich Morin wrote:
> 1. Section 2.2:
>
> The second paragraph is misleading and hard to read. My version
> (below) is a bit verbose, but I think it is important that the
> readers of the document have a clear and unambiguous explication:
Check.
>
> 2. Section 2.4, in and following description of bin/system:
>
> for a Sun workstation TeX system
> for a TeX system on a Sun workstation
>
> ... Or TeX administrators ...
> ... Some TeX administrators ...
>
> Although designed to be ...
> Although the TDS is designed to be ...
>
> ... Sites are
> ... Consequently, to avoid possible name collisions, sites are
Check.
> 3. Section 3:
>
> ... into a single directory (or a few directories) ...
> ... into a small number of directories ...
>
> ... example, TeXinfogoes in ...
> ... example, TeXinfo goes in ...
Check
> 4. Section 4, in and after description of supplier:
>
> ... The public serves ...
> ... The public directory serves ...
>
> ... The amsfonst
> ... The amsfonts
Check.
> It is necessary to place dpi ...
>
> Really? Examples, or are you just hand-waving here???
Originally, I thought ISO-9660 prevented files from beginning with digits.
> 5. I find it difficult to distinguish typewriter oblique from plain
> typewriter font, particularly when they are mixed together, as in
> the layout figure. Could you look into using a different font,
> or perhaps an explicit notation such as <texmf>?
Sure.
> 6. The formatting of the layout figure got trashed, somehow.
Oops.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:49:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:45:40 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142045.PAA06746@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: nits & notes on 0.66
References: <9503132026.AA26112@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 13 March 1995 at 12:26:57, Rich Morin wrote:
> I have no problem with the ISO-9660 description going into an appendix, if
I think it's fine in the text...
> I'm not sure what Joachim means by:
>
> But then we have to clarify that TDS cannot be specified with respect
> to all these restrictions. In particular, we have to emphasize even
> more that mixed case file names are *needed* by TeX.
>
> Unless I'm missing something crucial, mixed case file names are very nice
> to have, but cannot be allowed to be necessary. That is, if mixed case
> is needed to disambiguate between names, any ISO-9660 CD-ROM will fail.
I don't think it's that serious...
> The above description leads to the impression that the TDS specifies
> the use of uppercase file names. It must not, as this is unfunctional,
> and therefore unacceptable.
>
> As I would put it, the TDS must specify that names of "registered TDS
> paths" must not conflict, even when case distinctions are ignored. This
> leaves room for individual sites and unregistered packages to get into
> trouble, but that's beyond our control, in any case.
Sounds good.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:52:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:48:33 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142048.PAA06897@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments on draft 0.66
References: <199503141130.MAA19186@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 12:30:55, Joachim Schrod wrote:
> > P.S. It seems we are nearing a final version. Perhaps we should bump
> > the version number to 0.90 and set a target such as 0.99 for a public
> > release. (If that fails, we could still go to version 0.999999, though!)
>
> Please no. Use a `normal' numbering scheme. Better yet, use some
> revision management system like CVS. You'll need it if we go real
> public with this draft, when comments dripple in to arbitrary version
> you don't have available any more. (Btw, a backlog of all distributed
> versions is at my ftp site.) By using rcs.sty, one can also add
> revision numbers automatically; one might even want to typeset the
> revision log...
I'll check everything into RCS and setup some nice formatting convention
for it (probably in the footer) when we go public.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:53:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:49:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142049.PAA06927@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: initex typesetting
References: <199503141143.AA14931@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 06:43:46, K. Berry wrote:
> > > The \replaceable{format} directory \path|hyphen| is reserved for
> > > hyphenation patterns. Thes are used only by ini{\TeX} when a new
> > ^^^^^^^^^ \application{INITEX}?
>
> The canonical way to represent INITEX is by \texttt{INITEX}. See the
> TeXbook and/or tugboat.cmn.
>
> But maybe the TDS guide should be consistent with itself, and typeset
> all program names the same way (in italics).
>
> Since different program authors have different preferences (e.g., mine
> is for `Web2c' in all roman), if the tds tries to please everyone, the
> result will be inconsistent.
>
> So, I think I agree with Ulrik here about the use of \application. (I'm
> not sure I agree with `INITEX'; rather `initex'?)
Let's wait until the text is done to start picking nits this small. I'm
having a hard time keeping up as it is...
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:55:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:51:16 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142051.PAA06995@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: nits & notes on 0.66
References: <199503141148.MAA20744@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 12:48:30, Joachim Schrod wrote:
> Other OSes don't do that. The most prominent example here is Unix.
> (Are MacOS names case sensitive?)
No.
> -- I'm against a TDS that _demands_ uppercase file names for each and
> every TeX installations. If we add the ISO-9660 explanation to the
> section `Constraints' that impression may occur.
Ok, we need to make sure that doesn't happen.
> -- I'm against including the topic of registration in the TDS as it
> stands now. Except if somebody steps forward and agrees to handle
> this registration -- then I'm all in favor for it. I.e., we should
> first find the guys who do the work before we spent the time to
> specify the work.
True.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 14:57:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 15:52:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142052.PAA07078@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: Editorial comments on draft 0.66
References: <950314115542.2242a709@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 11:55:42, Philip Taylor wrote:
> [Ulrik Vieth writes:]
>
> >> 2. HTML documents are intended to be read by programs (WWW browers)
> >> and not by humans directly. The other files below texmf/doc such
> >> as preformatted .dvi or .ps files (whatever is more appropriate)
> >> can be accessed individually by invoking a viewer on the command
> >> line, whereas HTML documents rely on the links between files and
> >> cannot easily be accessed indvidually without a front-end.
>
> I cannot honestly see the distinction here; neither DVI nor PS nor
> HTML files can be meaningfully `read' without the use of a special
> viewer; what is the essential difference between an DVI viewer,
> a PostScript viewer, and an HTML `front-end'?
There really isn't a distinction; you know we put "info" and "man" at the
top because there are tools that expect them to be "easy to find". That's
not much justification, really. On the other hand, I'm not immediately
impressed with the idea of dropping them *all* into texmf/doc, so I'm
inclined to leave "html" at the top.
Does anyone think "info", "man", and "html" should all be in texmf/doc?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 15:16:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 16:12:06 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142112.QAA07446@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Re-write of MetaPost section offered
References: <9503141203.AA08433@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 13:03:47, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> \begin{filecontents}{mflogo.sty}
> \NeedsTeXFormat{LaTeX2e}[1994/06/01]
> \ProvidesPackage{mflogo}
> [1994/12/26 v1.4b LaTeX package for METAFONT and METAPOST logos]
Where's the source for logo.mf with a "P" and an "S"?
> \section{Non-font {\MF} files}
Check. But I think I'd like some of the sentences reworded to avoid
beginning with a lowercase name...
> \section{{\MP} files}
Check. And ditto.
> \setcounter{section}{9}
> \section{Summary}
>
> Here's an overview figure summarizing the \acronym{TDS} tree.
> (A longer directory listing from a real but small system should
> presumably go into the very last appendix.)
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 15:17:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 16:13:06 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142113.QAA07508@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments on draft 0.66
References: <795190164.853367.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 09:09:24, BNB@math.ams.org wrote:
> some responses to ulrik's questions ...
> Why `amsfonts' here? I'd say the supplier is `ams' as an organization.
>
> in this context, yes, it's probably better to say `ams'.
Ok.
> > \item[\replaceable{typeface}]
> > is the name of the typeface family. \path|cm|,
> > \path|latex|, \path|amsfonts|, \path|concrete|,
> ^^^^^^^^^^^^^^^
> > \path|bookman|, and \path|courier| are
> > examples of \replaceable{typeface}.
>
> There is no such typeface `amsfonts'. `ams' is a supplier for serveral
> typefaces such as `euler', `symbols', `cyrillic'. BTW, what about
> typefaces consisting of a single file such as dummy.tfm? Where does
> that go? (Barbara?)
>
> how about `name of the typeface family or collection'? we do think
> of amsfonts as a collection, and actually, cm is really a collection
> and not a single family (i'd consider cmfib, cmff, cmdunh to be
> different families, but implemented using cmbase, the cm character
> descriptions and radically different parameters).
Yes, but this was a simple typo. The directory name here should be the
face, not the collection.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Mar 1995 15:23:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Mar 1995 16:19:11 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503142119.QAA07761@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments
References: <199503142000.VAA20200@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 March 1995 at 20:59:59, Joachim Schrod wrote:
> I would add it to at the end of the first paragraph of the item
> `package' (that's on page 8 in 0.66). Hmm, how about...
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 03:32:43 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments on draft 0.66
Date: Wed, 15 Mar 1995 09:31:31 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:246630:950315093218"@cl.cam.ac.uk>
re info, man, html. i hate to be a wet blanket, but surely some
brwoser might well be able to display man pages, or info pages, at
some point? so a WWW-based documentation system might pick up all
three. in that case, preserving html at the top level
is not actually that important. i'd put them all under doc. that top
level is messy enough as it is
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 03:33:05 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Re-write of MetaPost section offered
Date: Wed, 15 Mar 1995 09:32:21 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:247360:950315093306"@cl.cam.ac.uk>
ooh, Norm, your logo.mf is not up to date! gasp! its buried on CTAN
under knuth...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 04:09:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 95 11:04:08 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503151004.AA09526@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: logo fonts
Norm wrote:
> Where's the source for logo.mf with a "P" and an "S"?
It should be located at CTAN:systems/knuth/lib/logo.mf.
You'll need Knuth's 1993 revision and you'll have to regenerate all the
PK and TFM files. There are no changes to the driver files logo<nn>.mf.
The source for logod10.mf should be CTAN:systems/knuth/local/lib/.
I think the current versions are already in Karl's lib-6.x.tar.gz
and also in the teTeX distribution.
Cheers,
Ulrik.
P.S. There's also a logosl9.mf in CTAN:systems/knuth/local/lib and
I've made up an anlogous logosl8.mf. Although the latter is not a
canonical source by Knuth, I don't think there would be any problem
about putting that into fonts/src/mflogo together with the others
as there isn't much to do wrong when simply replacing `9' by `8'.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 04:17:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 95 10:44:08 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503150944.AA09513@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: texmf/html (was: Editorial comments on draft 0.66)
Phil Taylor wrote:
> I cannot honestly see the distinction here; neither DVI nor PS nor
> HTML files can be meaningfully `read' without the use of a special
> viewer; what is the essential difference between an DVI viewer,
> a PostScript viewer, and an HTML `front-end'?
Well, perhaps I wasn't clear enough. The point I was trying to make
is that there is a fundamental difference in the way these files
are typically accessed. Whereas DVI and PS files can be accessed
indvidually by invoking a suitable viewer just like invoking an
editor or pager to list the contents of a text file, HTML files are
not usually accessed by invoking a viewer on the individual file.
One would rather start at the institute's `home page' and follow
some hyperlinks to the software documentation page, to the TeX system
documentation page, etc. to eventually arrive at a page offering
links to indvidual documents. The point is that users of the HTML
documentation wouldn't start by looking in the texmf/doc directory
manually in the first place. On the other hand, users looking into
that directory without any fancy HTML front-end wouldn't like to
find that tree filled up by literally hundreds of small HTML files.
(Norm's comp.fonts FAQ, for instance consists of 116 HTML files.)
Therefore I think that keeping HTML documents in a separate place does
make sense. However, HTML users can access all the other files in
the texmf/doc tree just as well, if there are some HTML index pages
with links to the individual documents in text, DVI or PS form and if
their HTML viewer supports invoking external viewers for these files.
I hope I was able to clarify this.
Ulrik Vieth.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 05:10:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 1995 06:10:55 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503151110.AA00762@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Editorial comments on draft 0.66
i'd put them all under doc.
I think I'm coming around to this view more strongly.
When I wrote my msg, I forgot about man.
Then there are three top-level directories that
are nothing but documentation-in-different-formats, and none of them are
universal.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 05:43:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 1995 06:38:46 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503151138.GAA22043@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/html (was: Editorial comments on draft 0.66)
References: <9503150944.AA09513@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 15 March 1995 at 10:44:08, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> Phil Taylor wrote:
>
> > I cannot honestly see the distinction here; neither DVI nor PS nor
> > HTML files can be meaningfully `read' without the use of a special
> > viewer; what is the essential difference between an DVI viewer,
> > a PostScript viewer, and an HTML `front-end'?
>
> [...]
>
> One would rather start at the institute's `home page' and follow
> some hyperlinks to the software documentation page, to the TeX system
> documentation page, etc. to eventually arrive at a page offering
> links to indvidual documents. The point is that users of the HTML
> documentation wouldn't start by looking in the texmf/doc directory
> manually in the first place. On the other hand, users looking into
> that directory without any fancy HTML front-end wouldn't like to
> find that tree filled up by literally hundreds of small HTML files.
> (Norm's comp.fonts FAQ, for instance consists of 116 HTML files.)
>
> [...]
>
> I hope I was able to clarify this.
Looking at your argument from another perspective, I think it adds weight
to my growing belief that info, html, and man all belong under doc.
1. Since the user starts at a home page, they don't care where the
docs are: nothing to be said for making them "easy" to find in the
texmf tree.
2. Servers invariably have security and only a very relaxed site is
going to let the browser wander all over the filesystem. In reality,
/texmf/doc/html will have to be lined or copied to
/usr/local/etc/htdocs, or some such.
3. Documentation is documentation, and these are all forms of documentation.
4. If we elevate html to top level status, what argument will we have
when Joe User wants dvi, ps, text, windows help, or other forms of
doc at the top level?
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, 15 Mar 1995 05:51:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 1995 11:51:34 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950315115134.2242d2a4@vms.rhbnc.ac.uk>
Subject: Re: texmf/html (was: Editorial comments on draft 0.66)
>> Well, perhaps I wasn't clear enough. The point I was trying to make
>> is that there is a fundamental difference in the way these files
>> are typically accessed. Whereas DVI and PS files can be accessed
>> indvidually by invoking a suitable viewer just like invoking an
>> editor or pager to list the contents of a text file, HTML files are
>> not usually accessed by invoking a viewer on the individual file.
>> One would rather start at the institute's `home page' and follow
>> some hyperlinks to the software documentation page, to the TeX system
>> documentation page, etc. to eventually arrive at a page offering
>> links to indvidual documents.
OK, now I understand, but I think this distinction is artificial. To give a
specific example: whilst I _could_ access the PERL documentation by starting at
Http://Vms.Rhbnc.Ac.Uk/, and working my way down, in practice I would go
straight to the primary PERL document, avoiding the network completely, and
simply launching Lynx on WWW:Perl.Html; would a TeX user, wishing to read the
local TeX documentation in HTML format, not adopt the same approach?
>> The point is that users of the HTML
>> documentation wouldn't start by looking in the texmf/doc directory
>> manually in the first place. On the other hand, users looking into
>> that directory without any fancy HTML front-end wouldn't like to
>> find that tree filled up by literally hundreds of small HTML files.
>> (Norm's comp.fonts FAQ, for instance consists of 116 HTML files.)
>> Therefore I think that keeping HTML documents in a separate place does
>> make sense. However, HTML users can access all the other files in
>> the texmf/doc tree just as well, if there are some HTML index pages
>> with links to the individual documents in text, DVI or PS form and if
>> their HTML viewer supports invoking external viewers for these files.
I don't think there's a conflict here: I wasn't proposing that all
HTMP files be simply dumped in a generic DOC directory, simply that
the root of their tree be DOC. In practice I would expect DOC to
n-furcate into DVI, MAN, HTML, ..., ..., ...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 07:00:43 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/html (was: Editorial comments on draft 0.66)
Date: Wed, 15 Mar 1995 12:55:15 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:058580:950315125535"@cl.cam.ac.uk>
Phil appears to admit that he uses Perl. hallelujah!
> Http://Vms.Rhbnc.Ac.Uk/, and working my way down, in practice I would go
> straight to the primary PERL document, avoiding the network completely, and
> simply launching Lynx on WWW:Perl.Html; would a TeX user, wishing to read the
> local TeX documentation in HTML format, not adopt the same approach?
in a word, no. thats a sophisticated appraoch. the more typical
netscape/mosaic user would have traverse the tree once, and then set
up a bookmark. maybe these poor souls under VMS with Lynx would do
what you do, but they must be regarded as unusual in web world
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 10:01:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 1995 10:57:32 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503151557.KAA27907@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Draft 0.67
Reply-To: TWG-TDS@SHSU.edu
Issued on the ides of March...
ftp://jasper.ora.com/private/twg-tds/tdsguide.*
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 12:40:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Mar 95 18:40:35 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503151840.AA03107@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Draft 0.67
Just a quick point, I think we should *not* use the logo for metapost
It may well be the case that an updated logo font is on ctan, but
The vast majority of people trying to print the dvi file will get
messages along the lines of
Character 80 not defined in font logo10
Character 83 not defined in font logo10
There is a danger that any discussion of the TDS itself will be
swamped in discussions about the merits of using a font with most of
the letters missing, and technical details of how actually to print
the document.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Mar 1995 15:10:25 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Draft 0.67
Date: Wed, 15 Mar 1995 20:44:50 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:286600:950315204506"@cl.cam.ac.uk>
well, thats easy (logo in tds) - dont put up the dvi file! put up the
source, or the PostScript, or the PDF....
david is probably right tho.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:00:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 15 Mar 1995 16:37:02 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503160037.QAA04466@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: unixtex@saul4.u.washington.edu
Subject: doc files again.
I'm reorganizing the UnixTeX tape for the rare bird who actually
gets one. I thought I had doc/ all straight but when I try to do
it there are still problems.
It is the <texmf>/doc/latex/base thing again.
According to the latest draft, the "latex" in that path is
equivalent to <category> and designates the "kind" of documentation
that is there. But I'm darned if I want to put any *.dtx
files there as duplicates of the dtx files that are in
the <texmf>/tex/latex/base branch, because those *.dtx
files actually contain the working code.
I am ready, even eager to put the sectioned PS files clsguide.001 etc, into
<texmf>/doc/latex/base, but no *dtx files. If that slightly
misleading choice is OK then I have no further problems
on that score. I might even put an explanatory note about how to run
*dtx files for documentation there, but not the files themselves.
Where should the latest version of fontnames go? <texmf>/doc/general ?
Seems like about the right place.
Also, I assume tripman goes in <texmf>/doc/general, but should
webman go there or in <texmf>/doc/tex/web ?
If I can get this clear, I can send you an actual doc tree as it
will be going out in new tapes of UnixTeX---supposing any such tapes
ever go out.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:31:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 06:09:36 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161109.AA14769@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Draft 0.67
david is probably right tho.
I agree. Let's make the document as portable as possible.
(E.g., I've also been nagging norm to make it processable with latex209)
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:31:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 06:13:27 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161113.AA14796@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/html (was: Editorial comments on draft 0.66)
Looking at your argument from another perspective, I think it adds weight
to my growing belief that info, html, and man all belong under doc.
I agree. I think there's a consensus for moving those documentation
format directories under doc/.
(I confess I haven't looked at the just-released draft yet, so I
probably shouldn't be sending this message. Sorry.)
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:38:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 95 17:36:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503161736.AA03835@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: unixtex@saul4.u.washington.edu
Subject: Re: doc files again.
Pierre:
According to the latest draft, the "latex" in that path is
equivalent to <category> and designates the "kind" of documentation
that is there. But I'm darned if I want to put any *.dtx
files there as duplicates of the dtx files that are in
the <texmf>/tex/latex/base branch, because those *.dtx
files actually contain the working code.
I thought the result of last week's discussion on this was that dtx
files were sources and so go in the source tree. There is no point in
putting dtx files under <texmf>/tex/ as they are never read by a
`production' tex setup, they are only used during installation (of
both the tex input files, and documentation)
Thus I presume that *dtx goes under source, and any dvi or ps files
that you choose to generate from them go under doc, and any sty files
generated from them go under tex.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:39:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161615.RAA17811@spice.iti.informatik.th-darmstadt.de>
Subject: 0.67
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 16 Mar 1995 17:15:00 +0100 (MEZ)
Content-Type: text
We seem to get closer...
A general comment on logos: Norm, are you willing to use a style file
that will produce logos that do not bomb in section headers and that
will adapt themselves to different sizes? (We have lots of places in
the TDS draft, where these kind of problems appear.) If yes, I'll
make one.
Now, to the draft. This time, I cite from the TeX document. (I have
no SGML setup at home, where I write this).
----------------
** 2.2 {Constraints}
{\acronym{ISO}-9669}
Isn't that ISO-9660? [two times]
\acronym{MS-DOS},
\acronym{OS/2}, Windows-NT, and MacOS filesystems are not
case-sensitive; consequently a request for \path|OT1cmr.fd| can
always be satisfied by \path|ot1cmr.fd| (or
\path|OT1CMR.FD|.
>> ^
missing parenthesis
[...]
The space overhead produced by this ``link
farm'' (at 1KB per link) may be negligible compared to the space
>> ^^^
1\,KB
required for all the files.
[...]
One use of the TDS will be the creation of mountable, generic
TeX-related distributions on CD-ROM. The only universally
acceptable file system format for CD-ROMs is ISO-9660. ISO-9660
You used entities for all this stuff elsewhere.
\item
Names and extensions may \emphasis{only} be made up of the
character set A-Z, 0-9, and the underscore. Note that any alphabetic
<literal> for these chars.
en-dash for ranges.
\item
A period is used to separate the file name from the
extension. It will always be present, even if the
name or extension is missing
(e.g., \path|FILENAME.|, \path|.EXT|).
Here the pargraph breaking went havroc. Perhaps one can discard the
last `the', then `EXT' should fit on the line.
\item
A version number, ranging from 1-32767,
en-dash for ranges.
\item
Only eight levels of directories are allowed, including
the top-level (mounted) directory. Thus, the longest
legal TDS path is:
\begin{alltt}
\replaceable{texmf}/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1\end{alltt}
No <replaceable> used for texmf/ elsewhere.
Note: Many UNIX systems (e.g., SunOS) modify the displayed
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most Unix systems
I've worked with all major Unix versions, and they do it all. (Note
also `Unix' vs. `UNIX'.)
format of ISO-9660 names, mapping alphabetic characters to
lower-case, removing extensions and trailing periods, etc.
Naturally, this does not affect the format of names on the CD-ROM.
again, you used entities elsewhere.
----------------
** 2.4 {Top Level Directories}
\item[\replaceable{program}]
for {\TeX} applications. It may be convenient to store
implementations (\application{em{\TeX}}, \application{PC{\TeX}},
etc.) as well as utilities (\command{dvips},
\command{MakeIndex}, etc.) in their own directories.
Implementations can store configuration files, compiled {\TeX}
format files, {\protect\MF} bases, {\MP} mems, \acronym{DLL}s, etc. in
>> ^^
pool files,
Please insert them here as well, I got already three questions where
to place them.
\item[\path|bin|/\replaceable{system}]
[...]
Some {\TeX} administrators may wish to put executables outside of
\path|texmf/| altogether.
Elsewhere the trailing slash is not appended to `texmf'.
----------------
** 3 Macros
\item[\replaceable{format}]
is the name of the {\TeX} format file that uses these files.
>> ^^^^
discard
It's not necessarily the file name. E.g., I wouldn't use `lplain' as a
<format> directory, but `latex209'.
It may be necessary to search other directories as well.
For example, the \path|amstex|,
\path|plain|, and \path|generic|
directories should be searched when using {\AmS}{\TeX}.
Use the AmSTeX entity.
{\TeXinfo} goes in \path|texmf/texinfo/texinfo.tex|, not
\path|texmf/texinfo/base/texinfo.tex|.
\TeXinfo must expand to `Texinfo' (lowercase `x'!).
As already noted in another mail, the tex/ level is missing two times.
----------------
** 4 Fonts
The names \path|cm|, \path|latex|, and \path|ams|
are very specifically defined. The \path|cm| typeface directory
contains precisely the 75 fonts defined in \citetitle{Computers and
Typesetting, Volumes A-E}. The \path|latex| typeface directory
contains only the fonts distributed with {\LaTeX} in the \emphasis{base}
distribution. The \path|ams| typeface directory
contains only the fonts distributed by the \acronym{AMS}.
If you don't use Ulrik's proposal of citing only Volume E here, then
use an en-dash.
And still, the AMS font stuff is in trouble.
ams/ is named two times here, first as a supplier, then as a typeface.
Either they are catalogued under public/, then they should not be
mentioned in the <supplier> item. Then the <typeface> directory should
be named amsfonts/, IMHO.
Or they get a supplier directory tree, then the notion of _one_
ams/ directory on the <typeface> level is nonsense. (It would mean:
fonts/ams/ams/*/.) If the AMS folks prefer to lump all their fonts in
one directory, we can name that amsfonts/. But it would be more in the
spirit of the TDS to name the typefaces here. I.e., I would see four
subdirectories here: cyrillic/, euler/, extracm/, and symbols/.
----------------
** 5 {Non-font METAFONT files}
\section{Non-font {\protect\MF} files}
Here is one place where the logo definition is deficient.
Most {\protect\MF} input files are fonts, however a few non-font
input files do exist (\path|null.mf|, \path|expr.mf|, and
>> ^
(\path|plain.mf|,
\path|modes.mf|, for example).
IMHO plain.mf is the most important non-font input file...
----------------
** 6 METAPOST
Knuth says he loves it.
Discard that sentence. It's irrelevant for a standard text.
\footnote{
In the past {\MP} used to be available only under
non-disclosure agreement from \acronym{AT\&T}, but it was placed in
the public domain with the beginning of this year.
>> ^^^^^^^^^
1995
`this year' gets out-of-date quite quickly... :-)
\item
\path|base| is reserved for the standard macros that come with
{\MP} as described in the documents \citetitle{A User's Manual for
MetaPost} and \citetitle{Drawing Graphs with MetaPost} by John
Hobby,\footnote{
Both documents are available as CSTR~162 and~164
from \path|ftp.netlib.att.com|. They are also included
as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
distribution.
}
Discard the footnote. Appendix C is the place for this information.
(``Don't use footnotes in your books,...'', or similar. ;-)
\item
\path|misc| is reserved for {\MP} packages consisting of only a
single file or a small number of files.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
delete
Only single-file-packages may go in misc/.
\item
\path|support| is reserved for some special files required by the
{\MP} utility programs when operating in \application{troff} mode.
These include things like a font map, a character adjustment table
>> ^
,
and a subdirectory containing low-level {\MP} programs for rendering
some special characters.
(Hah! An English comma rule I understand!)
----------------
** 8 {Documentation}
In the case of {\TeX} \replaceable{format}s, this will be the name
Elsewhere the plural-s is part of the tagged #PCDATA.
[ WE HAVEN'T CLEARLY SPECIFIED WHAT THE PACKAGE LEVEL IS YET ]
I didn't understand the current state of discussion anyhow. Have we
introduced doc/<type>/ now? In particular, for <type> \in {dvi/, ps/}
-- I have to say, I don't like that. That would be better to maintain,
but not so good for end-users. Or do we just mention man pages, info
files, and HTML documents, since they will be probably installed
elsewhere anyhow?
When the water is not so muddy any more, I'm willing to write
something up for this section.
Files below the \replaceable{package} level are determined by the
documentation author. The documentation directory may contain {\TeX}
sources, \path|DVI| files, \path|PS| files, text files, or
>> ^^^^^^^^^
PostScript
----------------
** 10 {Summary}
How about a typeset version of this table? Shall I prepare some macros
that take the input as is and format something approprieate? (And then
there are people who think SGML doesn't need DATATAG... :-)
. . . <package>/ doucmentation of packages (e.g., graphics, amslatex)
>> ^^
cu
[...]
. html/ hypertext docs (produced by e.g., texi2html or latex2html)
. info/ processed Texinfo documents
. man/ Unix-style manual pages
Moved under doc/.
. . hyphen/ hyphenation patterns
. . . <language>/ name of a language\end{alltt}\sourcefile{impissue.sgm}
Discard the last line. Each directory would just hold one or at most
two files. Just dump all these (27 freely distributable ones,
currently) in the hyphen/ directory.
----------------
** A {Implementation Issues}
Like the title says $\ldots$
But I don't understand the title... What shall appear here?
----------------
** C {Where Are All the Files?}
Rename that section to ``References to Files \& Documents''
Not only files should be referenced here, but also technical reports
mentioned, etc.
----------------
** D {About the Committee}
I saw that Vicki and Rich gave their email address. Should the other
email address be mentioned as well?
There are lots of `LaTeX' & `TeX' in this stuff that must be turned
into entities.
----------------
That's it for this time.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:41:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 95 17:40:34 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503161740.AA03840@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Draft 0.67
> I agree. Let's make the document as portable as possible.
> (E.g., I've also been nagging norm to make it processable with latex209)
I seem to remember there used to be a format of that name.....
David
PS
Before you all shout at me.. Norm told me about that `nagging' and I
sent him a preamble such that the thing runs under
latex209/article.sty or latex2e/ltxguide.cls.
Against my better judjement:-)
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:52:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161213.NAA23383@spice.iti.informatik.th-darmstadt.de>
Subject: CWEB and TDS questions (fwd)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 16 Mar 1995 13:13:43 +0100 (MEZ)
Content-Type: text
I received mail concerning TDS. Part of it I could answer immediately,
other stuff may be of general interest.
> From: "Andreas Scherer" <SCHERER@genesis.informatik.rwth-aachen.de>
> Date: 16 Mar 95 12:23:43 +0100
> Subject: CWEB and TDS questions
>
> And now to a more important issue. I've downloaded version 0.66 of the
> `TeX Directory Structure' paper in preparation of an all-new Amiga port
> of the complete Web2C 6.1 system, _without_ DVI drivers. Except for the
> `fonts' directory system, which can not be supported by the current
> versions of the Amiga DVI drivers from the PasTeX distribution, the
> major parts of my personal installation comply to the new scheme.
>
> But here are the questions I'd like to ask.
> [...]
> - There is a `config' subdirectory for certain macro packages,
> but where in the TDS should configuration files of the programs
> go? KPathSea 2.6 seems to have path configuration files (I'll stick
> to version 1.6 right now), and for the runtime memory configuration
> files in my implementation I choose a new top-level directory
> texmf/config
> Is this legitimate or should `tex.mcf' go to `texmf/tex/config'?
> `mf.mcf', `mp.mcf', and `bibtex.mcf' are similar candidates.
I've pointed out the place for config files of TeX implemenations and
utility programs. A problem seems to be his BibTeX config file. Where
do we place that? In texmf/bibtex/? texmf/bibtex/config/? texmf/bibtex/misc/?
> - Why should, according to page 8, `texinfo.tex' go to
> texmf/texinfo/texinfo.tex
> and not to
> texmf/tex/texinfo/texinfo.tex?
Typo, still in 0.67.
> - Pages 9 and 10: Why is the font `mode' below the `typeface'?
> Recursive path search would be much easier to implement and/or
> configure if the `mode', highly related to a specific output
> device and driver, would cover all possible fonts (even the
> `supplier' should move below the `mode', if you think of it).
> But here I must confess that I'm not deeply in driver programming.
> Creation of GF and PK files with MetaFont is far less crucial in
> respect to time than reading the pixel information for complex
> documents that use lots of different fonts, although I'll have
> to do some serious programming for automatic font generation.
My answer to this topic was: ``Because it's a compromise. ;-)''
But I do not want to hide this input.
> I will try to get in contact with the author of the PasTeX system, Georg
> Hessmann, but according to his recent silence, he seems to be rather busy
> with non-TeXnical stuff at the moment, so full support of TDS on the Amiga
> could well take some time.
>
> Best regards,
>
> Andreas Scherer
> Aachen University of Technology, Germany
> <scherer@genesis.informatik.rwth-aachen.de>
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:53:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 17:50:50 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950316175050.22430ae3@vms.rhbnc.ac.uk>
Subject: Re: Draft 0.67
>> I agree. Let's make the document as portable as possible.
>> (E.g., I've also been nagging norm to make it processable with latex209)
I have to say, I think this is going too far! The LaTeX team need all
the help they can get to persuade people that {LaTeX 2.09 is dead;
long live LaTeX}. We can help them in that by ensuring that the document
uses \documentclass, not \documentstyle. The TeX world is slow enough
to adopt change as it is: let's not assist it in its intertia.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:54:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161754.SAA16403@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Draft 0.67
To: TWG-TDS@SHSU.edu
Date: Thu, 16 Mar 1995 18:54:46 +0100 (MEZ)
Content-Type: text
You wrote:
>
>
> > I agree. Let's make the document as portable as possible.
> > (E.g., I've also been nagging norm to make it processable with latex209)
>
> I seem to remember there used to be a format of that name.....
Really? Wasn't it named lplain? .....
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 11:59:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 12:52:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503161752.MAA03635@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
References: <199503160037.QAA04466@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 15 March 1995 at 16:37:02, Pierre MacKay wrote:
> According to the latest draft, the "latex" in that path is
> equivalent to <category> and designates the "kind" of documentation
> that is there. But I'm darned if I want to put any *.dtx
> files there as duplicates of the dtx files that are in
> the <texmf>/tex/latex/base branch, because those *.dtx
> files actually contain the working code.
As David commented, I think we've agreed that *.dtx files go in the
source tree.
> I am ready, even eager to put the sectioned PS files clsguide.001 etc, into
> <texmf>/doc/latex/base, but no *dtx files. If that slightly
> misleading choice is OK then I have no further problems
> on that score. I might even put an explanatory note about how to run
> *dtx files for documentation there, but not the files themselves.
I think that's right.
> Where should the latest version of fontnames go? <texmf>/doc/general ?
> Seems like about the right place.
Yes, I suppose. In <texmf>/doc/general/fontnames/ and
<texmf>/doc/info/ and (potentially) <texmf>/doc/html/, I suppose.
> Also, I assume tripman goes in <texmf>/doc/general, but should
> webman go there or in <texmf>/doc/tex/web ?
Or texmf/doc/web? I dunno.
I think we have to expect a fair amount of variation in the documentation
tree. It's largely up to the TeX administrator, I think, and may reflect
"local traditions" whereas the rest of the tree has to be specified.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 12:04:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161742.SAA16630@spice.iti.informatik.th-darmstadt.de>
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Date: Thu, 16 Mar 1995 18:42:15 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> I am ready, even eager to put the sectioned PS files clsguide.001 etc, into
> <texmf>/doc/latex/base, but no *dtx files.
Exactly my understanding.
> Where should the latest version of fontnames go? <texmf>/doc/general ?
> Seems like about the right place.
>
> Also, I assume tripman goes in <texmf>/doc/general, but should
> webman go there or in <texmf>/doc/tex/web ?
Hmm, let's see: IMO webman goes in doc/web/.
But what's with cwebman? Also in doc/web/? doc/cweb/?
And then, what do I do the user manual of the LaTeX cweb style? In
doc/{c,}web/ or in doc/latex/styles/?
I would like to here opinions on the other two documents, as I've got
no idea either.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 12:12:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 13:10:44 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161810.AA00906@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
My opinion is to put all web variations into doc/web.
It's not that much, is it? Hence subdivision will just
cause needless searching?
I would put doc of subsidiary web stuff like the latex cweb
style also in web, as it's people who want to know to know
about web that will be looking there, not people who
want to know about latex.
Or leave a link/copy/whatever.
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 12:12:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 12:41:44 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503161741.MAA03429@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Draft 0.67
References: <9503161740.AA03840@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 16 March 1995 at 17:40:34, David Carlisle wrote:
> Before you all shout at me.. Norm told me about that `nagging' and I
> sent him a preamble such that the thing runs under
> latex209/article.sty or latex2e/ltxguide.cls.
And that's in use now, 'though I admit I've never tested it under
209.
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
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 12:20:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 13:15:27 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503161815.NAA04144@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: CWEB and TDS questions (fwd)
References: <199503161213.NAA23383@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 16 March 1995 at 13:13:43, Joachim Schrod wrote:
> > - There is a `config' subdirectory for certain macro packages,
> > but where in the TDS should configuration files of the programs
> > go? KPathSea 2.6 seems to have path configuration files (I'll stick
> > to version 1.6 right now), and for the runtime memory configuration
> > files in my implementation I choose a new top-level directory
> > texmf/config
> > Is this legitimate or should `tex.mcf' go to `texmf/tex/config'?
> > `mf.mcf', `mp.mcf', and `bibtex.mcf' are similar candidates.
>
> I've pointed out the place for config files of TeX implemenations and
> utility programs. A problem seems to be his BibTeX config file. Where
> do we place that? In texmf/bibtex/? texmf/bibtex/config/? texmf/bibtex/misc/?
I vote for texmf/bibtex/config. In general, if it occurs on a searchable
TeX path, putting it in a /config directory leaves a hook for some
implementations of subdirectory searching to avoid looking there for standard
input files. Just a thought.
> > - Why should, according to page 8, `texinfo.tex' go to
> > texmf/texinfo/texinfo.tex
> > and not to
> > texmf/tex/texinfo/texinfo.tex?
>
> Typo, still in 0.67.
Fixed.
> > - Pages 9 and 10: Why is the font `mode' below the `typeface'?
> > Recursive path search would be much easier to implement and/or
> > configure if the `mode', highly related to a specific output
> > device and driver, would cover all possible fonts (even the
> > `supplier' should move below the `mode', if you think of it).
> > But here I must confess that I'm not deeply in driver programming.
> > Creation of GF and PK files with MetaFont is far less crucial in
> > respect to time than reading the pixel information for complex
> > documents that use lots of different fonts, although I'll have
> > to do some serious programming for automatic font generation.
>
> My answer to this topic was: ``Because it's a compromise. ;-)''
> But I do not want to hide this input.
I see his point. But I'd like to leave fonts alone. Let's get a draft
out there and see what the implementors say.
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
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 13:23:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 95 11:22:11 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503161922.AA10587@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
The UNIX/Unix problem goes back to AT&T's decision to make the research
effort called Unix into a big commercial offering called UNIX(tm). Sigh
I don't want to argue about major/minor UNIX versions, but I can think of
several UNIX flavors that don't handle ISO-9660 names the same way Sun does:
DEC OSF/1
MachTen
A/UX
DG-UX
Irix
...
Hence my choice of "many" (which I can verify) instead of "most" (which
I cannot).
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 13:41:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 14:36:37 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503161936.OAA06401@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
References: <199503161615.RAA17811@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 16 March 1995 at 17:15:00, Joachim Schrod wrote:
> A general comment on logos: Norm, are you willing to use a style file
> that will produce logos that do not bomb in section headers and that
> will adapt themselves to different sizes? (We have lots of places in
> the TDS draft, where these kind of problems appear.) If yes, I'll
> make one.
Yes! The crud I've got now is from an attempt I made to do that.
Actually, I got it to work too, once, but I haven't time to figure it
out again now.
> {\acronym{ISO}-9669}
>
> Isn't that ISO-9660? [two times]
Yeah.
> \acronym{MS-DOS},
> \acronym{OS/2}, Windows-NT, and MacOS filesystems are not
> case-sensitive; consequently a request for \path|OT1cmr.fd| can
> always be satisfied by \path|ot1cmr.fd| (or
> \path|OT1CMR.FD|.
> >> ^
> missing parenthesis
Check
> [...]
>
> The space overhead produced by this ``link
> farm'' (at 1KB per link) may be negligible compared to the space
> >> ^^^
> 1\,KB
> required for all the files.
Picky, picky, picky ;-)
> [...]
>
> One use of the TDS will be the creation of mountable, generic
> TeX-related distributions on CD-ROM. The only universally
> acceptable file system format for CD-ROMs is ISO-9660. ISO-9660
>
> You used entities for all this stuff elsewhere.
Thanks.
> \item
> Names and extensions may \emphasis{only} be made up of the
> character set A-Z, 0-9, and the underscore. Note that any alphabetic
>
> <literal> for these chars.
> en-dash for ranges.
Ok.
> \item
> A period is used to separate the file name from the
> extension. It will always be present, even if the
> name or extension is missing
> (e.g., \path|FILENAME.|, \path|.EXT|).
>
> Here the pargraph breaking went havroc. Perhaps one can discard the
> last `the', then `EXT' should fit on the line.
I took a stab at it.
> \item
> A version number, ranging from 1-32767,
>
> en-dash for ranges.
check.
> \item
> Only eight levels of directories are allowed, including
> the top-level (mounted) directory. Thus, the longest
> legal TDS path is:
> \begin{alltt}
> \replaceable{texmf}/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1\end{alltt}
>
> No <replaceable> used for texmf/ elsewhere.
Ok.
> Note: Many UNIX systems (e.g., SunOS) modify the displayed
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Most Unix systems
>
> I've worked with all major Unix versions, and they do it all. (Note
> also `Unix' vs. `UNIX'.)
Check.
> format of ISO-9660 names, mapping alphabetic characters to
> lower-case, removing extensions and trailing periods, etc.
> Naturally, this does not affect the format of names on the CD-ROM.
>
> again, you used entities elsewhere.
Check.
> ----------------
>
> ** 2.4 {Top Level Directories}
>
> \item[\replaceable{program}]
> for {\TeX} applications. It may be convenient to store
> implementations (\application{em{\TeX}}, \application{PC{\TeX}},
> etc.) as well as utilities (\command{dvips},
> \command{MakeIndex}, etc.) in their own directories.
> Implementations can store configuration files, compiled {\TeX}
> format files, {\protect\MF} bases, {\MP} mems, \acronym{DLL}s, etc. in
> >> ^^
> pool files,
> Please insert them here as well, I got already three questions where
> to place them.
Ok.
> \item[\path|bin|/\replaceable{system}]
> [...]
> Some {\TeX} administrators may wish to put executables outside of
> \path|texmf/| altogether.
>
> Elsewhere the trailing slash is not appended to `texmf'.
Check.
> ----------------
>
> ** 3 Macros
>
> \item[\replaceable{format}]
> is the name of the {\TeX} format file that uses these files.
> >> ^^^^
> discard
Check.
> Use the AmSTeX entity.
Check
> {\TeXinfo} goes in \path|texmf/texinfo/texinfo.tex|, not
> \path|texmf/texinfo/base/texinfo.tex|.
>
> \TeXinfo must expand to `Texinfo' (lowercase `x'!).
> As already noted in another mail, the tex/ level is missing two times.
Check.
> ** 4 Fonts
>
> The names \path|cm|, \path|latex|, and \path|ams|
> are very specifically defined. The \path|cm| typeface directory
> contains precisely the 75 fonts defined in \citetitle{Computers and
> Typesetting, Volumes A-E}. The \path|latex| typeface directory
> contains only the fonts distributed with {\LaTeX} in the \emphasis{base}
> distribution. The \path|ams| typeface directory
> contains only the fonts distributed by the \acronym{AMS}.
>
> If you don't use Ulrik's proposal of citing only Volume E here, then
> use an en-dash.
I forget who originally suggested A-E. Which should it be?
> And still, the AMS font stuff is in trouble.
> ams/ is named two times here, first as a supplier, then as a typeface.
> Either they are catalogued under public/, then they should not be
> mentioned in the <supplier> item. Then the <typeface> directory should
> be named amsfonts/, IMHO.
> Or they get a supplier directory tree, then the notion of _one_
> ams/ directory on the <typeface> level is nonsense. (It would mean:
> fonts/ams/ams/*/.) If the AMS folks prefer to lump all their fonts in
> one directory, we can name that amsfonts/. But it would be more in the
> spirit of the TDS to name the typefaces here. I.e., I would see four
> subdirectories here: cyrillic/, euler/, extracm/, and symbols/.
Yes. Actually, I think I've got that paragraph about the names "cm",
"latex", and "ams" in the wrong place. We agreed that those were *supplier*
names, right?
We can't have "ams" under public since it's got to have "cyrillic", "euler",
etc. as typeface names. Technically, I suppose that "cm" and "latex"
are typeface names, but I don't think it's wrong to call them "suppliers".
Some of you will disagree.
> ----------------
>
> ** 5 {Non-font METAFONT files}
>
> \section{Non-font {\protect\MF} files}
>
> Here is one place where the logo definition is deficient.
Yes.
> Most {\protect\MF} input files are fonts, however a few non-font
> input files do exist (\path|null.mf|, \path|expr.mf|, and
> >> ^
> (\path|plain.mf|,
> \path|modes.mf|, for example).
>
> IMHO plain.mf is the most important non-font input file...
Ok.
> ----------------
>
> ** 6 METAPOST
>
> Knuth says he loves it.
>
> Discard that sentence. It's irrelevant for a standard text.
Check.
> \footnote{
> In the past {\MP} used to be available only under
> non-disclosure agreement from \acronym{AT\&T}, but it was placed in
> the public domain with the beginning of this year.
> >> ^^^^^^^^^
> 1995
>
> `this year' gets out-of-date quite quickly... :-)
Check.
>
> \item
> \path|base| is reserved for the standard macros that come with
> {\MP} as described in the documents \citetitle{A User's Manual for
> MetaPost} and \citetitle{Drawing Graphs with MetaPost} by John
> Hobby,\footnote{
> Both documents are available as CSTR~162 and~164
> from \path|ftp.netlib.att.com|. They are also included
> as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
> distribution.
>
> }
>
> Discard the footnote. Appendix C is the place for this information.
> (``Don't use footnotes in your books,...'', or similar. ;-)
Check.
> \item
> \path|misc| is reserved for {\MP} packages consisting of only a
> single file or a small number of files.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> delete
>
> Only single-file-packages may go in misc/.
Check.
> \item
> \path|support| is reserved for some special files required by the
> {\MP} utility programs when operating in \application{troff} mode.
> These include things like a font map, a character adjustment table
> >> ^
> ,
> and a subdirectory containing low-level {\MP} programs for rendering
> some special characters.
>
> (Hah! An English comma rule I understand!)
But in this case...no, I'm just kidding, Joachim.
> ----------------
>
> ** 8 {Documentation}
>
> In the case of {\TeX} \replaceable{format}s, this will be the name
>
> Elsewhere the plural-s is part of the tagged #PCDATA.
Ok.
> Files below the \replaceable{package} level are determined by the
> documentation author. The documentation directory may contain {\TeX}
> sources, \path|DVI| files, \path|PS| files, text files, or
> >> ^^^^^^^^^
> PostScript
Yeah.
> ----------------
>
> ** 10 {Summary}
>
> How about a typeset version of this table? Shall I prepare some macros
> that take the input as is and format something approprieate? (And then
> there are people who think SGML doesn't need DATATAG... :-)
I'm willing to mangle the input if you'll provide the macros for the
output ;-)
>
> . . . <package>/ doucmentation of packages (e.g., graphics, amslatex)
> >> ^^
> cu
Check.
>
> [...]
>
> . html/ hypertext docs (produced by e.g., texi2html or latex2html)
> . info/ processed Texinfo documents
> . man/ Unix-style manual pages
>
> Moved under doc/.
Check.
>
> . . hyphen/ hyphenation patterns
> . . . <language>/ name of a language\end{alltt}\sourcefile{impissue.sgm}
>
> Discard the last line. Each directory would just hold one or at most
> two files. Just dump all these (27 freely distributable ones,
> currently) in the hyphen/ directory.
Ok.
> ----------------
>
> ** A {Implementation Issues}
>
> Like the title says $\ldots$
>
> But I don't understand the title... What shall appear here?
Rich had some thoughts...
> ----------------
>
> ** C {Where Are All the Files?}
>
> Rename that section to ``References to Files \& Documents''
>
> Not only files should be referenced here, but also technical reports
> mentioned, etc.
Ok.
> ----------------
>
> ** D {About the Committee}
>
> I saw that Vicki and Rich gave their email address. Should the other
> email address be mentioned as well?
Yes, lets.
> There are lots of `LaTeX' & `TeX' in this stuff that must be turned
> into entities.
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 14:26:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 95 18:32:31 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503161832.AA03894@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: CWEB and TDS questions (fwd)
> I see his point. But I'd like to leave fonts alone. Let's get a draft
> out there and see what the implementors say.
I must say when we had our previous round of `discussions' over
fonts/type I had assumed that in the case of pk fonts all the three
directory levels denoting the `type' of the file would stick together,
viz: pk/mode/dpi It had somehow escaped my attention how things
finally ended up. However I don't want top start that discussion
again, so lets get the draft finished with no major changes to the
tree structure now...
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 14:53:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503162052.VAA16397@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.67
To: TWG-TDS@SHSU.edu
Date: Thu, 16 Mar 1995 21:52:49 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> The UNIX/Unix problem goes back to AT&T's decision to make the research
> effort called Unix into a big commercial offering called UNIX(tm). Sigh
:-) That's why I prefer to use UNIX if I mean the AT&T (or USL)
product, or if it's part of another name like `UNIX Review'; but use
Unix when I mean the class of operating systems that is roughly
described by 1170. Actually, in the TDS context I would even argue
that we could talk about POSIX.[12]-like systems.
> I don't want to argue about major/minor UNIX versions, but I can think of
> several UNIX flavors that don't handle ISO-9660 names the same way Sun does:
>
> DEC OSF/1
> MachTen
> A/UX
> DG-UX
> Irix
> ...
I stand corrected. From these systems I have only used OSF/1 and
Irix, and didn't use CD-ROMs there. `Many' is therefore the better
attribute for the paragraph of name mapping by Unices.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 15:22:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 16:17:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503162117.QAA08790@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.68
Reply-To: TWG-TDS@SHSU.edu
At ftp://jasper.ora.com/private/twg-tds/tdsguide.*
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 15:30:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 1995 12:32:34 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503161732.AA00717@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: doc files again.
I am ready, even eager to put the sectioned PS files clsguide.001 etc, into
<texmf>/doc/latex/base, but no *dtx files. If that slightly
misleading choice is OK then I have no further problems
on that score. I might even put an explanatory note about how to run
*dtx files for documentation there, but not the files themselves.
Seems good to me. I agree about no .dtx files (i.e., those those in the
source tree), and I think we reached consensus on that.
Where should the latest version of fontnames go? <texmf>/doc/general ?
Sounds good.
Also, I assume tripman goes in <texmf>/doc/general, but should
If you really think anyone wants to read it besides those doing the
compilations. That's why I leave it in a subdirectory in the web2c
distribution. (Personally, I think it's a lot of fun to read, but I
suspect few users would agree.)
webman go there or in <texmf>/doc/tex/web ?
doc/web, I'd think? Why under tex?
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 17:30:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 16 Mar 1995 12:41:11 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Message-ID: <795375671.963195.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i have enormous sympathy with pierre's position regarding
<texmf>/doc/latex/base -- i'm fighting that same battle here
regarding ams-latex (which doesn't have a separate doc area,
driving me out of my poor, feeble mind),
i believe the latex group's position is that nothing should go
into "their" base area unless it comes directly from the group.
and i agree that the dtx files really are closer to sources
than to documentation, if a choice has to be made.
pierre -- i believe your suggestion for an explanatory note
about how to run dtx files is excellent. if you could not only
write one, but get it accepted as "theirs" by the latex group,
that would be an enormous step forward.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Mar 1995 22:54:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Mar 95 10:42:15 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503160942.AA10201@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Notes on draft 0.67
* sec. 2.2:
That CD-ROM standard: Is that ISO-9669 or ISO-9660. It's used incosistenly
and presumably only one of these numbers is correct.
> ... consequently a request for \path|OT1cmr.fd| can
> always be satisfied by \path|ot1cmr.fd| (or \path|OT1CMR.FD|.
Insert a closing parenthesis here!
> One use of the TDS will be the creation of mountable, generic
> TeX-related distributions on CD-ROM. The only universally
^^^
Use the {\TeX} logo!
> A period is used to separate the file name from the
> extension. It will always be present, even if the
> name or extension is missing
> (e.g., \path|FILENAME.|, \path|.EXT|).
I think \path|.EXT| shouldn't be broken across lines!
* sec. 2.3:
> The name \path|texmf| was chosen for several reasons:
> it reflects the fact that the directory contains files to an entire
> {\TeX} system, (including {\protect\MF}, {\MP} {\protect\BibTeX}, etc.,
^
Insert a comma here!
> The \path|texmf| root is not intended to be placed under an
> implementation-dependent directory. For example, \path|emtex/texmf|
> is wrong.
Question: Does that mean that \path|/usr/local/tex/texmf| is also wrong?
* sec. 2.4:
> Implementations can store configuration files, compiled {\TeX}
> format files, {\protect\MF} bases, {\MP} mems, \acronym{DLL}s, etc. in
^
> their own directory. Utilities can store configuration files,
> input files, etc. in their own directory.
^
Use a control space: \ after `etc.' in the middle of a sentence!
* sec. 3:
> The \replaceable{format} directory \path|hyphen| is reserved for
> hyphenation patterns. Thes are used only by {\iniTeX} when a new
^^^^ These
> format file is being built.
^^^^^^ maybe use \path|.fmt| here?
> The \path|plain| directory is intended for files which are
> useful with the Plain {\TeX} format and others compatible with Plain:
> \path|fontchart.tex|, \path|testfont.tex|,
> \path|story.tex|, \path|manmac.tex|,
> \path|webmac.tex|, etc., as well as \path|plain.tex| itself.
I still think it should be mentioned that story.tex is an example file.
What about rewording the sentence as follows?
! ... as well as \path|plain.tex| itself and the canonical example
! \path|story.tex| from \citetitle{The {\TeX}book}.
> The package name \path|base| is reserved for the base
^^^^^^^ \replaceable{package}
> distribution for each format. Files used by {\iniTeX} to construct
> format files should also be stored in the \path|base| directory.
What about this (for consistency with the MF and MP sections)?
! Files used by {\iniTeX} when dumping \path|.fmt| files ...
> Two \replaceable{package} names are reserved:
Move the preceeding paragraph (speaking about \path|base|) below
this line, make that another \item, and change `Two' to `Three'.
> \item
> The package name \path|misc| is reserved for packages that
^^^^^^^ \replaceable{package}
> consist of a single file.
* sec. 4.1:
> For PostScript fonts rendered as bitmaps with the \command{ps2pk}
^^^^^^^^^^ {\PS}
> program, the mode \path|ps2pk| should be used.
> \command{gsftopk} is handled analogously.
* sec. 5:
> \item
> \path|modes| is reserved for files containing {\protect\MF} mode
> descriptions for output devices, such as the quasi-canonical
> \path|modes.mf| and any local mode definition files that might
> be included by {\iniMF} when dumping \path|.base|
> files containing preloaded macro definitions.
I think this idea has been rejected by the majority, so this paragraph
can vanish. However, it should be mentioned that modes.mf should go
into \path|misc|.
* sec. 6:
After re-reading the draft as a whole, I think my write-up of the
MetaPost section doesn't fit very well with the tone of the rest of
the document. In particular, the first paragraph (adapted from the
introduction of the MetaPost manual) sounds too much like advertising.
Therefore I think the first two paragraphs of this section should be
shortened and combined to mention only the most important facts:
- MetaPost is a METAFONT-like system with PS output
- it is mainly intended for drawing figures for inclusion into TeX
documents with dvips
(That's what it is and why it belongs in the TDS hierarchy.)
- it has facilities for integrating typeset text by invoking TeX
or troff and some utilties in a sub-process
(That's the reason why we need the metapost/support directory.)
- it used to be restricted in the past, and therefore it isn't
widely available yet, but that might change in the future
(That's why readers of the draft might not be familiar with MP.)
- it is approved by Knuth who uses it himself and says he loves it
(That's actuallly irrelevant, but it might be nice to mention.)
> Both documents are available as CSTR~162 and~164
> from \path|ftp.netlib.att.com|. They are also included
> as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
^^^^^^^^^^ Sorry, make that: |mpgraph.ps|
> distribution.
(And better put this stuff in an appendix or the bibliography.)
* sec. 8:
> In the case of {\TeX} \replaceable{format}s, this will be the name
> of the format: \path|latex|, \path|plain|, \path|amstex|, etc.
> Directories for each \replaceable{format} should contain directories
> for each package, in a tree paralleling the \path|tex| tree.
> Packages that consist of only a single file, or a small number of
> independent files, may be installed in the \path|misc|
> package directory.
Why is it \replaceable{format} but not \replaceable{package} here?
Is it really appropriate to use \replaceable here at all?
* sec. 10:
The formatting of the figure got mixed up again. You have to remove
to spaces after the replaceable items to compensate for the newly
introduced angle brackets.
Also move the top-level html/, info/, and man/ below the doc/ hierarchy
and remove metafont/modes.
So much for this time.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 05:20:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 06:16:07 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171116.GAA22442@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: vieth@xerxes.thphy.uni-duesseldorf.de
Subject: Re: Notes on draft 0.67
References: <9503160942.AA10201@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 16 March 1995 at 10:42:15, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
Ulrik, are you not on the TWG-TDS mailing list? I asked for a review
of members and your address isn't there...
> * sec. 2.2:
>
> That CD-ROM standard: Is that ISO-9669 or ISO-9660. It's used incosistenly
> and presumably only one of these numbers is correct.
Yeah, I made an SGML entity for it and munged the replacement text.
It's ISO-9660 and it's fixed now.
> > ... consequently a request for \path|OT1cmr.fd| can
> > always be satisfied by \path|ot1cmr.fd| (or \path|OT1CMR.FD|.
>
> Insert a closing parenthesis here!
Check.
> > One use of the TDS will be the creation of mountable, generic
> > TeX-related distributions on CD-ROM. The only universally
> ^^^
> Use the {\TeX} logo!
Oops.
> > A period is used to separate the file name from the
> > extension. It will always be present, even if the
> > name or extension is missing
> > (e.g., \path|FILENAME.|, \path|.EXT|).
>
> I think \path|.EXT| shouldn't be broken across lines!
I think I fixed that ... I reworded the sentence, but I haven't
checked the line break.
> * sec. 2.3:
>
> > The name \path|texmf| was chosen for several reasons:
> > it reflects the fact that the directory contains files to an entire
> > {\TeX} system, (including {\protect\MF}, {\MP} {\protect\BibTeX}, etc.,
> ^
> Insert a comma here!
Check.
> > The \path|texmf| root is not intended to be placed under an
> > implementation-dependent directory. For example, \path|emtex/texmf|
> > is wrong.
>
> Question: Does that mean that \path|/usr/local/tex/texmf| is also wrong?
Yes.
[I'll make the rest of the corrections later today....]
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:11:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:11:57 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171511.AA28588@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Notes on draft 0.67
Therefore I think the first two paragraphs of this section should be
shortened and combined to mention only the most important facts:
- MetaPost is a METAFONT-like system with PS output
[etc.]
I think those paragraphs should simply be removed from the standard.
Or else put in a subsection or an appendix saying ``background info on
metapost, since it's not as well-known as the others''.
But that info really seems to belong in a different file (that the tds
would give a pointer to). Separation of concerns and all that.
- it is approved by Knuth who uses it himself and says he loves it
(That's actuallly irrelevant, but it might be nice to mention.)
I'm as much of a Knuth groupie as anyone else (if not more so :-), but I
still don't think that sentence should be in the tds document.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:12:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:13:00 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171513.AA28594@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
i have enormous sympathy with pierre's position regarding
<texmf>/doc/latex/base -- i'm fighting that same battle here
regarding ams-latex (which doesn't have a separate doc area,
driving me out of my poor, feeble mind),
i believe the latex group's position is that nothing should go
into "their" base area unless it comes directly from the group.
But ``their'' base area is texmf/tex/latex/base, not
texmf/doc/latex/base, right? Do they lay claims to the doc directory as well?
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:18:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:19:25 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171519.AA28616@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
> the top-level (mounted) directory. Thus, the longest
> legal TDS path is:
> \begin{alltt}
> \replaceable{texmf}/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1\end{alltt}
1) Please use `valid', not `legal'. Let's keep legal meaning human laws.
2) The statement isn't true. .../LL2/... is a one-character longer path.
Perhaps ``deepest'' would be true.
3) I don't see that this little example helps anything; it's just
restating what ``eight levels'' means. Perhaps just toss it? Or alter
it so that it shows the actual texmf tree and how close we are to the
limit?
I prefer removing it.
> If you don't use Ulrik's proposal of citing only Volume E here, then
> use an en-dash.
I forget who originally suggested A-E. Which should it be?
It's volume E that defines the CM fonts. Use that.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:20:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:21:28 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171521.AA28620@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
Yes. Actually, I think I've got that paragraph about the names "cm",
"latex", and "ams" in the wrong place. We agreed that those were *supplier*
names, right?
cm and latex are typeface names. Supplier is public. The things under
them are the standard 75 and the base latex fonts.
ams is a supplier name. The things under it are all and only the amsfonts.
Typefaces are cyrillic, euler, extracm, and symbols.
I'm pretty sure we've reached consensus on this.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:25:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:26:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171526.AA28636@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: CWEB and TDS questions (fwd)
> > Is this legitimate or should `tex.mcf' go to `texmf/tex/config'?
> > `mf.mcf', `mp.mcf', and `bibtex.mcf' are similar candidates.
>
> I've pointed out the place for config files of TeX implemenations and
> utility programs. A problem seems to be his BibTeX config file. Where
> do we place that? In texmf/bibtex/? texmf/bibtex/config/? texmf/bibtex/misc/?
I vote for texmf/bibtex/config. In general, if it occurs on a searchable
I'm not sure I agree. Presumably these config files are
amiga-implementation-specific. Therefore I think they should in
texmf/amiga -- with the other implementation-dependent files like
.fmt's.
Kpathsea's texmf.cnf goes in texmf/web2c, right? And these seem analogous.
Whether you have a bunch of config files or one seems like an
implementation decision.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:38:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 95 15:37:52 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503171537.AA07770@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
> But ``their'' base area is texmf/tex/latex/base, not
> texmf/doc/latex/base, right? Do they lay claims to the doc directory
> as well?
Depends what you mean. I think it would be useful to separate out
`official' documentation from contributed help files. If the system
does not match the former then there is a bug (in the system or the
documentation). However it would seem perfectly reasonable to put in
the base documentation area anything that is just re-structuring of
the documentation coming with the system, for instance the one-page PS
files that Pierre mentioned should clearly go in doc/latex/base.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:40:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:36:29 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171536.KAA27903@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
References: <199503171521.AA28620@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 17 March 1995 at 10:21:28, K. Berry wrote:
> Yes. Actually, I think I've got that paragraph about the names "cm",
> "latex", and "ams" in the wrong place. We agreed that those were *supplier*
> names, right?
>
> cm and latex are typeface names. Supplier is public. The things under
> them are the standard 75 and the base latex fonts.
>
> ams is a supplier name. The things under it are all and only the amsfonts.
> Typefaces are cyrillic, euler, extracm, and symbols.
>
> I'm pretty sure we've reached consensus on this.
Right! I had a case of tunnel vision. Ignore my screwup in 0.68, too.
I'll fix it...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:44:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:40:47 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171540.KAA27961@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
References: <199503171519.AA28616@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 17 March 1995 at 10:19:25, K. Berry wrote:
> > the top-level (mounted) directory. Thus, the longest
> > legal TDS path is:
> > \begin{alltt}
> > \replaceable{texmf}/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1\end{alltt}
>
> 1) Please use `valid', not `legal'. Let's keep legal meaning human laws.
Check.
> 2) The statement isn't true. .../LL2/... is a one-character longer path.
> Perhaps ``deepest'' would be true.
Check.
> 3) I don't see that this little example helps anything; it's just
> restating what ``eight levels'' means. Perhaps just toss it? Or alter
> it so that it shows the actual texmf tree and how close we are to the
> limit?
I'll try it that way..
> I prefer removing it.
But I have no objection to this either, anyone else have an opinion?
> > If you don't use Ulrik's proposal of citing only Volume E here, then
> > use an en-dash.
>
> I forget who originally suggested A-E. Which should it be?
>
> It's volume E that defines the CM fonts. Use that.
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:51:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:46:43 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171546.KAA28065@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
References: <199503171519.AA28616@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 17 March 1995 at 10:19:25, K. Berry wrote:
> 3) I don't see that this little example helps anything; it's just
> restating what ``eight levels'' means. Perhaps just toss it? Or alter
> it so that it shows the actual texmf tree and how close we are to the
> limit?
>
> I prefer removing it.
Well, I went in to replace that path with
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
because I thought that banged against the limit and discovered that
the (1) it doesn't and (2) I wouldn't have known that from the textual
description.
Eight levels, to me, would have meant:
texmf/L2/L3/L4/L5/L6/L7/files
So either the text has to be fixed, the example has to stay, or everyone
has to say "You're thick, norm, no one else will make that mistake."
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:52:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:47:27 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171547.KAA28072@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: CWEB and TDS questions (fwd)
References: <199503171526.AA28636@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 17 March 1995 at 10:26:31, K. Berry wrote:
>
> I vote for texmf/bibtex/config. In general, if it occurs on a searchable
>
> I'm not sure I agree. Presumably these config files are
> amiga-implementation-specific. Therefore I think they should in
> texmf/amiga -- with the other implementation-dependent files like
> .fmt's.
>
> Kpathsea's texmf.cnf goes in texmf/web2c, right? And these seem analogous.
> Whether you have a bunch of config files or one seems like an
> implementation decision.
I think Karl's right. Tunnel vision again, on my part.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:52:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171547.QAA18428@spice.iti.informatik.th-darmstadt.de>
Subject: Re: CWEB and TDS questions (fwd)
To: TWG-TDS@SHSU.edu
Date: Fri, 17 Mar 1995 16:47:23 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> > > Is this legitimate or should `tex.mcf' go to `texmf/tex/config'?
> > > `mf.mcf', `mp.mcf', and `bibtex.mcf' are similar candidates.
> >
> > I've pointed out the place for config files of TeX implemenations and
> > utility programs. A problem seems to be his BibTeX config file. Where
> > do we place that? In texmf/bibtex/? texmf/bibtex/config/? texmf/bibtex/misc/?
>
> I vote for texmf/bibtex/config. In general, if it occurs on a searchable
>
> I'm not sure I agree. Presumably these config files are
> amiga-implementation-specific. Therefore I think they should in
> texmf/amiga -- with the other implementation-dependent files like
> .fmt's.
Very good point. So we can let texmf/bibtex/ as it is now.
I'll forward it to Andreas.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 09:54:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 10:50:06 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503171550.KAA28120@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Notes on draft 0.67
References: <199503171511.AA28588@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 17 March 1995 at 10:11:57, K. Berry wrote:
> Therefore I think the first two paragraphs of this section should be
> shortened and combined to mention only the most important facts:
>
> - MetaPost is a METAFONT-like system with PS output
> [etc.]
>
> I think those paragraphs should simply be removed from the standard.
>
> Or else put in a subsection or an appendix saying ``background info on
> metapost, since it's not as well-known as the others''.
>
> But that info really seems to belong in a different file (that the tds
> would give a pointer to). Separation of concerns and all that.
>
> - it is approved by Knuth who uses it himself and says he loves it
> (That's actuallly irrelevant, but it might be nice to mention.)
>
> I'm as much of a Knuth groupie as anyone else (if not more so :-), but I
> still don't think that sentence should be in the tds document.
Right. I incorporated those sections from Ulrik without so much as a
passing glance; I'll see about rewording them to fit into the tds guide
a little better.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 10:00:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 11:00:39 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171600.AA10460@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.67
I don't get it.
Put in the texmf/fonts/pk/.../cmr10.pk example, and say this
is seven levels. It is, right?
My objection is more to the L2/L3/etc. stuff than to the idea
of showing the directory levels in an example.
I'm about to send more comments, so don't release .69 in
the next hour, ok? :-)
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 10:21:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 17 Mar 1995 11:21:24 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Message-ID: <795457284.440934.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
me, earlier:
i believe the latex group's position is that nothing should go
into "their" base area unless it comes directly from the group.
karl:
But ``their'' base area is texmf/tex/latex/base, not
texmf/doc/latex/base, right? Do they lay claims to the doc directory as
well?
good point. i don't know. is there someone here who can enlighten us?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 10:30:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 95 16:29:15 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503171629.AA07814@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
> good point. i don't know. is there someone here who can enlighten
> us?
I sent some random thoughts on this a moment ago, but I dont see that
this is a LaTeX issue particularly.
Where should local or contributed documentation for eplain or amstex
go?? I would have thought it made sense to put it in a directory
that made its contributed status clear, but is this being to
`possesive' of the `base' directories??
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 10:30:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171630.RAA19565@spice.iti.informatik.th-darmstadt.de>
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Date: Fri, 17 Mar 1995 17:30:50 +0100 (MEZ)
Content-Type: text
barbara wrote:
>
> me, earlier:
> i believe the latex group's position is that nothing should go
> into "their" base area unless it comes directly from the group.
>
> karl:
> But ``their'' base area is texmf/tex/latex/base, not
> texmf/doc/latex/base, right? Do they lay claims to the doc directory as
> well?
>
> good point. i don't know. is there someone here who can enlighten us?
I think this was written before David send his mail. But I would like
to take this opportunity for a remark:
If somebody is writing up how one gets documentation out of DTX files,
he or she should mention the possibility to get only the user
documentation part by adding \OnlyDescription to the driver part. It
should further be mentioned that one does not have to change the DTX
files for that, this can go in ltxdoc.cfg.
At least my users are more interested in the user manual than the
implementation description. I think there are many more with the same
approach...
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 11:00:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 17 Mar 1995 09:00:59 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171700.JAA19545@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
If somebody is writing up how one gets documentation out of DTX files,
he or she should mention the possibility to get only the user
documentation part by adding \OnlyDescription to the driver part. It
should further be mentioned that one does not have to change the DTX
files for that, this can go in ltxdoc.cfg.
That is exactly the idea. The more it is possible to treat distributed
packages as read-only resources, the better off both distributors
and users are.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 11:19:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 17 Mar 1995 12:19:03 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Message-ID: <795460743.345934.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
david:
... I dont see that
this is a LaTeX issue particularly.
Where should local or contributed documentation for eplain or amstex
go?? I would have thought it made sense to put it in a directory
that made its contributed status clear, but is this being to
`possesive' of the `base' directories??
i think the point about the contributed status is the key.
regarding ams(la)tex, if a file appears in a core ams(la)tex
directory i believe a user would most likely expect that it came
from ams. we agree to support what we distribute, and haven't
got the resources to answer questions about what came from
somewhere else. we know that a lot of users don't bother to
read the documentation before asking for help, so let's try
to make it easy for them to figure out where *not* to ask.
i don't think "possessive" has quite the right flavor. how about
"enlightened self interest"?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 11:31:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 12:31:39 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171731.AA11037@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Separating documentation written by the maintainers from
a locally-written good can only be a guide thing.
Presumably local documentation goes in a local tree.
If there's a lot of it.
If there's not (like if it's one file describing
the setup), I don't see that it much matters.
We seem to all agree that the base/ directory
should contain only the distributed documentation,
but that it can be in whatever formats the distributor/
installer/whoever wants -- postscript, dvi, source, whatever.
yes?
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 11:32:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 12:31:49 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171731.AA11045@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 68 comments
\tableofcontents
The `9 Summary' line of the contents still comes out on page 2.
How can this be the default formatting?
particular, the TWG believes it is usable under Unix, \acronym{MS-DOS},
We haven't defined `TWG' yet. I propose changing this sentence above:
The primary purpose of this document is to describe a standard
to this:
The TUG Working Group on Directory Structure (TWG) was formed to
describe ...
local system uses the {\TeX} Directory Structure recommended here.
Propose another paragraph:
This version is a draft. Email comments to twg-tds@shsu.edu.
[Do we need to allow snail mail comments?]
components (as in \path|texmf/fonts/|$\ldots$). This is the
The linebreak after texmf/ here looks confusing to me. Maybe reword as
... components; for example, ...?
Applications, like commands, are typeset in italics.
You don't have the `like foo' in any of the others. Suggest dropping it.
typefaces a site may wish to install. Listing that many directories
would lead to paths many thousands of characters long, overflowing the
available space on some systems.
Insert `Aside from anything else,' before `Listing' (and lowercase the
L/l :-).
directories to search at runtime (in the
\systemitem{ENVIRONVAR}{TEXINPUTS} environment variable or a
Change `the' to `a' before TEXINPUTS here.
it would possibly even require recompiling software, an intolerable burden.
would possibly even => could
installer and user) for all paths, though the \acronym{TDS} requires
subdirectory searching only for {\TeX} input files and fonts.
No longer true. Suggest deleting everything after `all paths'.
files or environment variables
Missing period.
is imperative to a well organized \acronym{TDS}, for the reasons stated above.
Hyphenate well-organized.
and the performance of this system is thus independent of the number
the performance of this system => performance
Having accepted that subdirectory searching was necessary, the \acronym{TWG}
... accepted the necessity for subdirectory searching
filenames. In the {\acronym{ISO}-9660} format, mixed case names are not allowed.
Hyphenate mixed-case. Globally. (I.e., do a global replace, this occurs
in more than one place.)
\acronym{OS/2}, Windows-NT, and MacOS filesystems are not
Is `MacOS' a common term? I don't know, I'm not a Mac person, I'm just asking.
Maybe just `Macintosh'?
\path|OT1CMR.FD|). Unix platforms, which do have case
sensitive filesystems, can use links to overcome any restrictions that
Hyphenate case-sensitive.
TeX-related distributions on \acronym{CD-ROM}. The only universally
\TeX...
File and directory names may not exceed eight characters.
We use filename in other places to mean the entire name, including the
directory and extension. So I suggest saying `names, not including any
directory or extension part,'. And/or `The base part of file and ...'.
File names may have extensions of up to three characters.
Let's keep `filename'(s) as one word. Globally.
If a file has no name, it \emphasis{must} have an extension.
The idea of a file without a name doesn't make sense to me.
Suggest `A filename must have a base part, an extension, or both.'
\literal{0}--\literal{9}, and the underscore. Note that any
Delete `the' before `underscore.
alphabetic characters must be in upper-case.
Let's not hyphenate uppercase. Globally. Ditto lowercase.
Many Unix systems modify the displayed
format of {\acronym{ISO}-9660} names,
Suggest: Many Unix systems display a modified format of ISO...
Naturally, this does not affect the format of names on the CD-ROM.
add `itself' after `CD-ROM', I think.
{\TeX} system, (including {\protect\MF}, {\MP} {\protect\BibTeX}, etc., and not just {\TeX}
Missing comma after MP.
Wasn't METAPOST typeset as {\logo META}{\tt post} for a while?
Maybe that would be more portable for our purposes.
for the input files used by {\TeX} (see \xref{Section 3, {Macros}}).
for the (non-font) input files used by {\protect\MF} (see \xref{Section 5, {Non-font {\protect\MF} Inputs}}).
for the font-related files (see \xref{Section 4, {Fonts}}).
Delete `the' after `for' in these items. (It's inconsistently present in
this list.)
for \emphasis{user} documentation (see \xref{Section 8, {Documentation}}).
I find the \emphasis confusing here. What other kind of documentation
have we been talking about?
for {\TeX} applications. It may be convenient to store
applications. (In fact, the tex, metafont, metapost, and bibtex
directories above may be seen as examples of this.)
The name ``spsun413'' is one possible {\acronym{ISO}-9660} compliant abbreviation
Except it's not uppercase. Ugh.
for ``sparc-sunos4.1.3''.
Should have a - before the 4.
Also, both the `spsun413' and `sparc...' should probably be in
typewriter, not quoted roman.
\path|texmf/source/web2c|) and {\LaTeX} \path|dtx| sources.
... sources (\path|texmf/source/latex|).
administrator to mount a single ``{\TeX} server'' (even in a
construct a single \TeX server in a ...
path, it is still possible to use them as macro packages under
possible => straightforward
[it would be *possible* the other way, too.]
Two \replaceable{format} names are reserved:
`The following' instead of `Two', I think. (In one place you had the
number wrong -- we'll get to that -- and I don't see that saying the
number of items in the list adds anything.)
\begin{itemize}
I find the spacing between items in all the bulleted lists too large.
hyphenation patterns. Thes are used only by {\iniTeX} when a new
Delete `new'.
reserved for input files that are useful across a wide range of
formats. Generally, this means any format that uses the category
... formats (including at least \TeX and \LaTeX). Generally, ...
and \path|fancyheadings| are examples of \replaceable{packages}.
1) fancyheadings can't be an example of a directory name. It's too long.
2) \replaceable{package}s, I think.
The package name \path|base| is reserved for the base
This should be the first item in the list, not a separate paragraph before.
packages of the names listed above. {\LaTeX} packages are style files
packages with the names ...
set of files that is distributed, installed, and maintained as a
Delete `that is'.
Two \replaceable{package} names are reserved:
Again, suggest `The following'.
file and has no auxilliary packages, that file can simply be placed
auxiliary
\path|texmf/fonts/|\replaceable{type}/\replaceable{supplier}/\replaceable{typeface}/\replaceable{files}
Are we doomed to have slashes in random fonts forever? Some of these are
in cmtt, others in cmsltt.
Type 1 fonts in \path|PFA| or \path|PFB| format
Somehow I want to say `either PFA or PFB or both' here, just to
be absolutely clear that we know we are breaking our own ``rule''.
Perhaps we should explain why, too, out of the old mail.
(Sorry, I'm in proofreading mode right now, don't want to look it up :-)
purpose; it designates fonts for which there are no licensing problems
I think : instead of ;.
\path|adobe|,
\path|monotype|, \path|ams|, \path|cm|, and
\path|latex| are
examples of \replaceable{supplier}.
This sentence should be the second sentence in this item, not the
last. And `The public directory...' sentence should probably start a new
paragraph.
are very specifically defined. The \path|cm| typeface directory
specifically defined. => precisely defined, as follows.
[or make the following three sentences a three-item list, or three
clauses after a colon, etc.]
for {\TeX} fonts}: CTAN:\path|info/fontname|.
The : after fonts} should be `in', I think. And \replaceable{CTAN}?
Hey, maybe \path|\replaceable{CTAN}/info/fontname| would avoid people
thinking that CTAN is just a hostname?
$\ldots$\path|/pk/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
May as well say texmf/fonts/pk instead of .../pk?
disadvantages. The most vexing is the fact that it creates dozens of
Delete `the fact'.
do exist that need to have a place in the \acronym{TDS} as well.
Delete `as well'
{\MP} is a picture-drawing language developed by John Hobby that is
...
\command{dvips}.
We've already talked about this a little. I think all of this (including
the footnotes) should be somewhere else, preferably in another document
that we point to.
Also, `via \command{dvips}' seems to unnecessarily discriminate among
dvi-to-postscript drivers.
overhead for searching this directory unnecessarily seems negligible
Delete unnecessarily.
invoking {\TeX} in a sub-process for typesetting labels.
Unhyphenate subprocess.
{\MP} can
also process {\protect\MF} input files and searches the {\protect\MF} input paths
as well when invoked on a {\protect\MF} file such as \path|logo10.mf|.
I don't see that this is relevant to the TDS. If anything, it belongs in
this hypothetical other document/section.
understand. In order to reduce the confusion, the \acronym{TDS}
specifies a directory
specifies directories
Most packages come with some form of documentation. In order to make
Delete `In order'.
keep the documentation together and (2) make it easy for users to
It's never easy for users to do anything. Suggest `straightforward'.
identifies the ``kind'' of documentation that resides
Suggest ``kind'' => general topic
(we're not talking about file formats only)
There are five reserved categories:
Five seems definitely too high to count :-).
[ WE HAVEN'T CLEARLY SPECIFIED WHAT THE PACKAGE LEVEL IS YET ]
Files below the \replaceable{package} level are determined by the
documentation author. The documentation directory may contain {\TeX}
sources, \path|DVI| files, {\PS} files, text files, or
whatever form of documentation will best explain the package.
I suggest simply dropping the package level in the schematic. We already
explained the package case in the `In the case of TeX formats' paragraph
above. So I suggest dropping the first sentence here, and saying `The
documentation directories ...' instead of `directory'.
[wow, a rainstorm just hit; wonder how long I'll have power.]
Something like the following:
Here is a skeleton of the directory structure described in this document.
<texmf>/ top-level directory for \acronym{TDS} tree
I hate to say it, but I think all the comments should be in roman, not
typewriter.
. bin/*/ binaries, by system type
Please append `(optionally)' or some such.
. . . <package>/ documentation of packages (e.g., graphics, amslatex)
Indentation of the comment (documenation...) is wrong here (and in many
other places.)
. . . . . <mode>/ type of output device (type pk and gf only)
. . . . . . <dpi>/ font resolution (type pk and gf only)
I find the double usage of `type' confusing. Suggest `for pk...' instead
of `type pk...'.
. . html/ hypertext docs (produced by e.g., texi2html or latex2html)
Comma before e.g.
. . info/ processed Texinfo documents
Append `(produced by, e.g., makeinfo)'.
. metafont/ METAFONT (non-font) input files
. metapost/ METAPOST input and support files
Please, not all capitals.
. <program>/ TeX applications, by name (e.g., makeindex)
I think `dvips' is worth adding after makeindex. And it should be
makeindx, anyway.
Like the title says $\ldots$
I'm not sure we have anything to say here. What did you have in mind?
[ SOMEONE HELP ME HERE, PLEASE, I'M NO GOOD AT WRITING THIS OVERVIEW STUFF ]
Well, what's there seems ok. I agree this section needs work.
I'm burned out for today on the TDS, but maybe over the weekend.
This appendix is for pointers to files we mention in this draft.
Not just files, but other documents. I wonder if it should be a bibliography.
By the way, I hope this document itself will be producible in Texinfo
and HTML formats, so that hypertext links can be made right, etc.
Sebastian suggests: it may be sensible to note that this group only existed by
email, just in case people think we have been meeting in person at
vast cost.
I agree. How about this:
The TWG had no formal meetings (many but not all members attended TUG
'94). All discussions were held by email. (Archived on shsu.edu:twg-tds.)
Berry, Karl (\literal{kb@cs.umb.edu}). Denies all affiliations ;-) [ yes, this has to come
out before the draft goes public ]
You can say `Maintainer of Web2c, Eplain, modes.mf, et al.'.
Geez, people are never happy ... the TUG office didn't like my
photograph, either :-).
Joachim Schrod (\literal{schrod@iti.informatik.th-darmstadt.de}). Scientific Assistant, Computer Science Department,
You mean Schrod, Joachim. Though I think it would be a cute informal
touch to put first-name-first, and sort on first name for a change. It
doesn't make any real difference.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:00:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171755.SAA24006@spice.iti.informatik.th-darmstadt.de>
Subject: Re: doc files again.
To: TWG-TDS@SHSU.edu
Date: Fri, 17 Mar 1995 18:55:53 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> We seem to all agree that the base/ directory
> should contain only the distributed documentation,
I'm not sure if I agree. That depends, what did you want to say? :-)
Is a DVI file that contains only the user manual part of a style file
(let's say makeindx.dtx) a ``distributed documentation''? I ask
because it's not so in a literal sense, it's only part of the
documentation that's in makeindx.dtx.
If you think so, then I agree with you.
Btw, how about making the doc/ section more hand-waving? Asking the
principal authors of a system to give guidance here? I.e., the AMS
folks should structure doc/ams{,tex,latex}/ as they want; the LaTeX
folks have a say for doc/latex/, etc.
To be honest, I think our decision around doc/ is irrelevant. It's
not backed up by any experience with real-life installations. (Well,
except a few hundred users at my site, but most of them know TeX
already and won't look too often at the documentation area). I think
a doc/ structure has to be tested and revised after we got more
experience. The real life situation for anything that's on the HCI
level, I'm afraid. :(
Joachim
PS: David, Alan. How about asking Rosemary Bailey? You know, she's
really good in finding basic flaws in documentation delivery.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:22:06 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 17 Mar 1995 10:22:17 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171822.KAA26519@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Separating documentation written by the maintainers from
a locally-written good can only be a guide thing.
Good, because when, for example, I put the clsguide.00n files
in a doc/latex/base directory, I also have to put in a README
saying what they are, and it might as well include some terse
instructions on how to roll your own. The README, however is
not part of the LaTeX distribution
Presumably local documentation goes in a local tree.
If there's a lot of it.
If there's not (like if it's one file describing
the setup), I don't see that it much matters.
Not clear what is meant here. Description of the "setup" procedure
would either be in the source tree or in doc/plain/package.
And this reminds me once again of the problem of ambiguity, whic
may not matter, so long as it is faced up to.
In doc/plain/<whatever> "plain" seems to mean "ordinary ascii"
which is to say, readable without any preprocessing.
In doc/latex/<whatever> "latex" appears to mean "this is about latex"
sometimes, and "this has to be run through latex" at others.
Maybe it doesn't matter, but I still do not feel that it is clear.
We seem to all agree that the base/ directory
should contain only the distributed documentation,
but that it can be in whatever formats the distributor/
installer/whoever wants -- postscript, dvi, source, whatever.
yes?
No problem so far, preprocessed documentation from clsguide, fntguide,
etc is all that is intended in doc/latex/base
But now a real world, non-martian problem.
I have written to Klaus Lagally asking him to let me try
a rearrangement of arabtex into a TDS tree. How does that tree look?
The documentation is written in LaTeX. Arabtex is an addon package,
it is not an independent format. What to do?
in doc/latex/base
"latex" means "this is about LaTeX, but does not
require processing through LaTeX"
In doc/latex/arabtex/<whatever> (following the "martian" example)
"latex" means "this is *NOT* about
LaTeX, it is about arabtex, but it has to be processed through LaTeX
before you can read it."
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:28:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 18:29:01 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950317182901.22438ece@vms.rhbnc.ac.uk>
Subject: RE: 68 comments
>> The TUG Working Group on Directory Structure (TWG) was formed to
>> describe ...
According to my notes on other TWGs, the `T' of TWG is not `TUG'
but `Technical'; thus (IMHO) the `TWG-TDS' is in full ``The TUG
Technical Working Group (on a) TeX Directory Structure''.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:32:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 13:32:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171832.AA29209@ra.cs.umb.edu>
To: schrod@iti.informatik.th-darmstadt.de
CC: twg-tds@shsu.edu
Subject: Re: doc files again.
Is a DVI file that contains only the user manual part of a style file
(let's say makeindx.dtx) a ``distributed documentation''? I ask
because it's not so in a literal sense, it's only part of the
documentation that's in makeindx.dtx.
If you think so, then I agree with you.
Yes, that's I meant. I should have said ``distributed or derived from
distributed''.
Btw, how about making the doc/ section more hand-waving? Asking the
I agree. In the comments I just sent, I suggest something a little way
along those lines.
I.e., the AMS
folks should structure doc/ams{,tex,latex}/ as they want; the LaTeX
folks have a say for doc/latex/, etc.
Right.
To be honest, I think our decision around doc/ is irrelevant. It's
Right.
PS: David, Alan. How about asking Rosemary Bailey? You know, she's
really good in finding basic flaws in documentation delivery.
Who is Rosemary Bailey? Does she want to read unixtex.ftp and
{kpathsea/dvipsk/xdvik/dviljk}/INSTALL :-) ?
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:34:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 13:34:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171834.AA29233@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
In doc/latex/arabtex/<whatever> (following the "martian" example)
"latex" means "this is *NOT* about
LaTeX, it is about arabtex, but it has to be processed through LaTeX
before you can read it."
I say this.
The format the documentation is in is irrelevant.
(Except for the machine-readable .info/.html/.[123456789l]!)
Whether the documentation is written in Texinfo or LaTeX or Martian TeX,
it still describes arabtex, and thus should go in an arabtex directory.
>From the point of view of the users, they don't care what the author
wrote the documentation in. They just want to read it, whatever format
it's in.
Make sense?
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:37:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 95 18:37:38 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503171837.AA07967@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
In doc/plain/<whatever> "plain" seems to mean "ordinary ascii"
which is to say, readable without any preprocessing.
In doc/latex/<whatever> "latex" appears to mean "this is about latex"
sometimes, and "this has to be run through latex" at others.
I thought that in both cases it meant `about' as in `about plain TeX'
and `about latex'
in doc/latex/base
"latex" means "this is about LaTeX, but does not
require processing through LaTeX"
fine
In doc/latex/arabtex/<whatever> (following the "martian" example)
"latex" means "this is *NOT* about
LaTeX, it is about arabtex, but it has to be processed through LaTeX
before you can read it."
Does arabtex count as a format in TDS-speak? If so it would presumably
be doc/arabtex/
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 12:48:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171848.TAA14593@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 68 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 17 Mar 1995 19:48:25 +0100 (MEZ)
Content-Type: text
[It's too late to count if it's really 68. :-) Before I'm leaving for
the weekend, just one comment.]
Karl wrote:
>
> and \path|fancyheadings| are examples of \replaceable{packages}.
>
> 2) \replaceable{package}s, I think.
If that is changed, there are more genetiv-s in the document. I would
stay with the current version.
> Here is a skeleton of the directory structure described in this document.
>
> <texmf>/ top-level directory for \acronym{TDS} tree
>
> I hate to say it, but I think all the comments should be in roman, not
> typewriter.
Since there were some comments on this topic; a FYI: I just send
macros to Norm that take the skeleton as it is and make a typeset
table of it. I've volunteered to write logos macros, too.
So that's the one comment... Hmm? Where is my calculator? Let's
see... 1 + 1 is ... 1. Hmm, ... 3?
Cheers -- 'nough for today. :)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Mar 1995 13:01:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 14:02:13 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503171902.AA29430@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: doc files again.
In doc/plain/<whatever> "plain" seems to mean "ordinary ascii"
which is to say, readable without any preprocessing.
In doc/latex/<whatever> "latex" appears to mean "this is about latex"
sometimes, and "this has to be run through latex" at others.
I thought that in both cases it meant `about' as in `about plain TeX'
and `about latex'
That's what I thought, too.
In doc/latex/arabtex/<whatever> (following the "martian" example)
"latex" means "this is *NOT* about
LaTeX, it is about arabtex, but it has to be processed through LaTeX
before you can read it."
Does arabtex count as a format in TDS-speak? If so it would presumably
be doc/arabtex/
Pierre said it was an add-on latex package, not a format.
MHO: If it's texmf/tex/latex/arabtex, the documentation goes in
texmf/doc/latex/arabtex.
If it's texmf/tex/arabtex, the doc goes in texmf/doc/arabtex.
Put another way, the only things in ``doc'' that aren't topics are
info, html, and man.
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Mar 1995 03:32:04 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 1995 14:02:13 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: Re: doc files again.
In doc/plain/<whatever> "plain" seems to mean "ordinary ascii"
which is to say, readable without any preprocessing.
In doc/latex/<whatever> "latex" appears to mean "this is about latex"
sometimes, and "this has to be run through latex" at others.
I thought that in both cases it meant `about' as in `about plain TeX'
and `about latex'
That's what I thought, too.
In doc/latex/arabtex/<whatever> (following the "martian" example)
"latex" means "this is *NOT* about
LaTeX, it is about arabtex, but it has to be processed through LaTeX
before you can read it."
Does arabtex count as a format in TDS-speak? If so it would presumably
be doc/arabtex/
Pierre said it was an add-on latex package, not a format.
MHO: If it's texmf/tex/latex/arabtex, the documentation goes in
texmf/doc/latex/arabtex.
If it's texmf/tex/arabtex, the doc goes in texmf/doc/arabtex.
Put another way, the only things in ``doc'' that aren't topics are
info, html, and man.
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Mar 1995 04:53:14 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Mar 95 19:38:37 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: nits¬es on 0.68
1. Section 1.1
... and in-use, ...
... and in use, ...
2. I think you need to decide whether to use typewriter oblique
or angle brackets to indicate replaceable text, and document
accordingly. At present, the figure uses brackets, but the
note in Section 1.2 doesn't explain this usage. My opinion
is still that typewriter oblique is too hard to tell from non-
oblique, and that some other differentiation should be made.
3. Section 2.2
The last sentence in the second paragraph is unwieldy. How about:
... environments and that filenames ... case, are ...
... environments. Filenames ... case are ...
And, at the top of the following paragraph:
... script files, however, ...
... script files. Fortunately, ...
KB is unclear about why the example:
texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
is needed. I like Norm's response, and assure him that this
point is one of the most frequently confused parts of the
ISO-9660 specification. So, I suggest using Norm's example
AND my example, with the addition of a bit of annotation, as:
=============================================================
Only eight levels of directories are allowed, including the top-
level (mounted) directory. Thus, the deepest valid TDS path is:
texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
1 2 3 4 5 6 7 8
Here is a typical TDS-oriented example, using only seven levels:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
=============================================================
4. The last sentence in the footnote on page 8 should read:
TDS packages are sets of files that are ... as units.
5. Section 4.1, paragraphs two and three
To construct clean sentences, common practice is not to use
this sort of construction! How about:
Fonts with different device types (modes) are generally
segregated into separate directories.
Two naming strategies are commonly used to identify
the resolution of bitmap font files. ...
6. paragraph four:
Since the ...
Because the ...
use the latter scheme ...
use the latter (directory-based) scheme ...
7. Section 4.1.1
The first sentence in the last paragraph goes on far too long.
(California law doesn't allow three-trailer semi's, Norm! :-)
I'm not sure how to chop it up, but how about:
information: if ...
information. If ...
... from (or that is, in fact) the ...
... from the ...
8. Section 8
option was placing them ...
option was to place them ...
texmf/doc/category/package/...
^^^^
I would stay in typewriter font for the "/..." above.
9. Section 10
I'm not real excited about indenting the descriptive info.
If you're going to indent, use two spaces per level, to
match the left side of the figure.
I also think that someone is going example-happy, and that it
makes the descriptive info busy and hard to read. Trim the
"e.g."s back to one (or at most, two) names.
Appendix A
There is no concensus on how TDS implementation should be achieved,
or even on what the key problems are. Further, I don't want to delay
the TDS an iota by trying to achieve concensus at this point. So,
here's some hand-waving which most of us *may* be able to accept. I'm
sorry it's a bit verbose; suggestions are requested.
========================================================================
A Implementation Issues
We believe that the TDS has the potential to bring a great deal of order
to the current anarchic state of many TeX installations.
In addition, by providing a common frame of reference,
it will ease the burden of documenting administrative tasks.
Finally, it is a necessary part of any reasonable system
of true ``drop-in'' distribution packages for TeX.
Adoption of TDS will not be immediate or universal, however.
Most TeX administrators will not be inclined to make the switch until:
* clear and demonstrable benefits can be shown for the TDS
* TDS-compliant versions of all key programs are available
in ported, well-tested forms
* A "settling" period has taken place, to flush out problems
Consequently, most of the first trials of the TDS
will be made by members of the TDS committee
and/or developers of TeX-related software.
Indeed, some of this has taken place during the course of our deliberations.
These trials may result in minor modifications to the TDS specification.
They will certainly result in the production
of a substantial number of TDS-compliant packages.
Once installable forms of key TDS-compliant packages are ready,
some adventurous TeX administrators will set up TDS-compliant trees,
possibly in parallel to existing production directories.
This ``Beta Testing'' will flush out problems that were not obvious
in the confined settings of the developers' sites.
In particular, it should help to flush out OS and package dependencies,
package interdependencies, and other esoteric details
that were not considered by the committee.
Finally, after most of the dust has settled,
conservative TeX administrators will begin to adopt the TDS.
Eventually, most TeX sites will have adopted the new structure,
and most common packages will be readily available in TDS-compliant form.
Expediting the Process
We believe that the process described above will occur fairly quickly.
The TDS committee spans a wide range of interests in the TeX community.
Consequently, we believe that most of the key issues involved
in defining a workable TDS definition have been covered, often in detail.
Further, a number of TeX developers have been consulted
about implementation issues, and have been trying out suggested TDS formats.
Thus, we don't expect any big surprises as implementation gets under way.
Finally, there are several (current or prospective) publishers
of TeX-based CD-ROMs.
These publishers are highly motivated to work out details
of TDS implementation, and their products will provide inexpensive
and convenient ways for experimentally-minded TeX administrators
to try out the TDS.
Efforts are under way to set up a "TDS Registry" that will coordinate the
assignment of TDS-compliant directory names and provide a definitive
database of TDS-compliant software distributions. Interested parties
should peruse CTAN:??? or send email to tdsr@cfcl.com.
============================================================================
Miscellany:
KB> Is `MacOS' a common term? I don't know, I'm not a Mac person, I'm
KB> just asking. Maybe just `Macintosh'?
MacOS has been a de facto name for the "Macintosh OS" for some time now.
Apple has recently trademarked it. We should NOT use just "Macintosh",
as that refers to the hardware, not the OS.
KB> We use filename in other places to mean the entire name, including the
KB> directory and extension. So I suggest saying `names, not including any
KB> directory or extension part,'. And/or `The base part of file and ...'.
I can't visualize what the result of all KB's edits would be (and I'll let
Norm hack up the text), but I think KB's on the right track. I wrestled
with the problem a bit, and I'd be happy to see the language clarified.
I *would* suggest the UNIX usage "basename", rather than "base part".
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Mar 1995 13:50:58 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68
To: TWG-TDS@SHSU.edu
Date: Sat, 18 Mar 1995 13:44:28 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> KB is unclear about why the example:
>
> texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
>
> is needed. I like Norm's response, and assure him that this
> point is one of the most frequently confused parts of the
> ISO-9660 specification. So, I suggest using Norm's example
> AND my example, with the addition of a bit of annotation, as:
Nice stuff, put it in.
> I'm not real excited about indenting the descriptive info.
No indentation in the typeset version.
> Appendix A
>
> There is no concensus on how TDS implementation should be achieved,
> or even on what the key problems are.
I didn't even understand what was meant with `implementation' in that
context. But now I see what you're meaning. It's a well-written
section, I don't think it's too verbose. The only problem, I see
currently, is the last paragraph
> Efforts are under way to set up a "TDS Registry" that will coordinate the
> assignment of TDS-compliant directory names and provide a definitive
> database of TDS-compliant software distributions. Interested parties
> should peruse CTAN:??? or send email to tdsr@cfcl.com.
Speaking as a macro developer -- if somebody tells me what a
``TDS-compliant software distribution'' is, I might consider
registration for some packages... :-)
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 Sat, 18 Mar 1995 19:19:45 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 18 Mar 95 10:12:48 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68
JS> Speaking as a macro developer -- if somebody tells me what a
JS> ``TDS-compliant software distribution'' is, I might consider
JS> registration for some packages... :-)
I think one of the problems with freeware archiving in general,
and the current CTAN collection in particular, is that there is
far too little documentation, let alone active cooperation, by
the submittors. As a result, for instance, there is no standard
"announcement" file for packages, containing information on each
package's purpose, origin, status, etc.
At the same time, I think the TDS will be far more useful if the
"TDS Name Space" is regulated, at least for distributed packages.
I propose that a registration process be created that would allow
a package to "own" some number of locations in the TDS name space.
These will generally be directories, but may, for small packages,
simply be files.
By preventing conflicts in the name space, the TDS Registry can
perform a function analogous to that performed currently for top-
level DNS and IP addresses. For example, the "Martian 1.0" package
might lay claim to the following directories:
texmf/doc/latex/martian/
texmf/doc/plain/martian/
texmf/fonts/source/public/martian/
texmf/fonts/tfm/public/martian/
texmf/tex/hyphen/martian/
texmf/tex/latex/martian/
texmf/tex/plain/martian/
It is clear to me that there may be occasional reasons to allow one
registered package to conflict with another, such as letting the 1.1
version of Martian use the same name space as the 1.0 version. I'm
not really clear on this part, however, so feedback is requested.
Here is my rough cut on implementation. "We", below, basically means
an "expanded subset" of the TDS committee. That is, a small group of
folks who are willing to take on some fairly minor volunteer duties.
1. We define an electronic "registration form" that has defined
places for a number of pieces of useful information:
Package Name, Description
Version Number, Date
Author Name, Contact Info
Maintainer Name, Contact Info
Support Contact Info
Operating System Dependencies (e.g, MS-DOS)
TeX-related Pre-requisites (e.g., LateX2e)
TDS Name Space Usage
Redistribution Status (e.g., PD, GPL, Proprietary, ???)
Distribution Format (e.g., sparse Info-Zipped tree)
2. Anyone who has created a TDS-compliant distribution is invited
to fill in and submit a registration form, probably to a known
email address. This address would feed a daemon, which would:
* do an automated analysis of the received form, looking
for missing information, syntax errors, TDS name space
conflicts, and so forth.
* send a response such as "Thank you for your form. Our
preliminary analysis indicates that ...".
* place the analyzed form into a location in the CTAN.
This location would be publicly accessible but not
heavily advertised. (A developer might wish to look
here for a conflicting form that is "in process".)
* forward the analyzed form to a smail mailing list
3. At any given time (I'm thinking about something like two-week
tours of duty), one or more members of the mailing list would be
"on call" to handle incoming forms. S/he would shepherd the form
past any discussions in the group. Forms should normally get in
and out of the process within a week. The other members of the
list would be responsible for looking the incoming forms over for
possible problems, then making suitable comments to the list.
Note: the registration process is basically a clerical function.
The only reasons for rejecting a form would be errors, omissions,
incomprehensible descriptions, unreasonable demands for TDS name
space, or some very peculiar happenstance.
4. Accepted forms would be placed into a public location in the CTAN,
and perhaps built into some sort of HTML document.
5. I can think of some follow-on activities involving testing of the
packages, handling of user comments, etc., but these are not
within the scope of this discussion.
Feedback is earnestly requested is requested on this entire scheme. By
the way, Vicki & I can handle the details of the daemon implementation
and serve as volunteers, at least initially.
Yours, Rich
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Mar 1995 22:51:40 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 18 Mar 1995 10:41:38 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: nits¬es on 0.68
2. I think you need to decide whether to use typewriter oblique
or angle brackets to indicate replaceable text, and document
accordingly. At present, the figure uses brackets, but the
note in Section 1.2 doesn't explain this usage. My opinion
is still that typewriter oblique is too hard to tell from non-
oblique, and that some other differentiation should be made.
I was the one who suggested typewriter oblique.
I don't find it hard to differentiate, but of course everyone reads
differently ...
Before, sometimes italic typewriter was used, which is certainly easy to
distinguish, but looks absolutely awful. I found it far more
distracting/harder to read than cmsltt.
I suspect using \langle and \rangle will look strange, because the angle
brackets will be so light compared to the characters.
Using typewriter < and > seems clunky. That's what you do in
ASCII when you can't do any fancy typography.
Maybe regular or bold italics or slanted would be worth trying.
Rich, do you have anything in mind?
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Mar 1995 22:59:09 MET
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 18 Mar 1995 13:46:41 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Cc: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
To be honest, I think our decision around doc/ is irrelevant. It's
not backed up by any experience with real-life installations. (Well,
except a few hundred users at my site, but most of them know TeX
already and won't look too often at the documentation area). I think
a doc/ structure has to be tested and revised after we got more
experience. The real life situation for anything that's on the HCI
level, I'm afraid. :(
In one obvious case, the correct installation of a dvips interpreter
largely depends on understanding how config.ps should be edited and it
helps to know several other things too. These happen to be stated
most clearly in dvips.texi, but if you have to install first, before
you can print out dvips.texi, the installation is likely to be
unsatisfactory and have to be done all over again. I can understand
your despair of making the large majority of users ever read
documentation, but if they are going to do so at all, it helps to make
it easy for them. Anyone who gets dvips presumably has a PostScript
printer, and though I admit that there will probably be many
installers who will go ahead and install with a totally bogus
config.ps no matter how much help they are offered, I keep hoping that
some will take the opportunity to read a nicely formatted manual
first.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Sun, 19 Mar 1995 00:42:08 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 18 Mar 95 13:45:27 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68
I don't have any wonderful suggestions to make regarding the replaceable
text. I assume that you TeXnocrats know much more than I do about the
kinds of fonts that might be available. My typical approach is to use
typewriter < and >. I agree that it's clunky-looking, but it sure is
hard to miss!
-r
================================================================================
From owner-twg-tds@shsu.edu Sun, 19 Mar 1995 01:47:55 MET
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 18 Mar 1995 16:37:22 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Here is a first try. I have not tried to get the long names out.
In the case of gzipped files, what does one do?
Each of the *.001 ... sections, by the way is a ten-page section,
which is, I hope, small enough to get through even very underpowered
PostScript printers.
doc/
dvips/
dvips.001 dvips.002 dvips.003 dvips.004 dvips.005 dvips.006 dvips.007
dvips.008 dvips.009 dvips.010 dvips.011 dvips.012 dvips.dvi
general/
NOTE errata.eight.gz errata.five.gz errata.four.gz errata.one.gz
errata.seven.gz errata.six.gz errata.tex.gz errata.three.gz
errata.two.gz errorlog.tex.gz fontname-1.6.tar.gz gentle.tex.gz
history.txt.gz logmac.tex.gz tex82.bug.gz texbook.tex.gz
tripman.tex.gz
help/
CyrilEncFAQ.gz NOTE README.WRITE-W README.vf SlowStart.FAQ TeX-FAQ.gz
TeX-FAQ.sup.tar.gz TeX-index.gz cyrillic.help mf-begin.tex.gz
mf-fontlist.gz patgen2.tut.gz
kpathsea/
kpathsea.001 kpathsea.002 kpathsea.003 kpathsea.004 kpathsea.005
kpathsea.006 kpathsea.007 kpathsea.008 kpathsea.dvi
latex/
arabtex/
NOTE arabdoc.ps arabtex.doc arabtex.faq guha.ps omar.ps
base/
clsguide.001 clsguide.002 clsguide.003 clsguide.004 clsguide.005
clsguide.006 fntguide.001 fntguide.002 fntguide.003 fntguide.004
fntguide.005 fntguide.006 fntguide.007 usrguide.001 usrguide.002
usrguide.003 usrguide.004 usrguide.005 usrguide.006 usrguide.007
metafont/
PXLformat.gz cm85.bug.gz mf84.bug.gz mfbook.tex.gz
plain/
arabtex/
SEElatex
base/
glue.web
web/
webman.tex.gz
================================================================================
From owner-twg-tds@shsu.edu Sun, 19 Mar 1995 11:41:47 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 19 Mar 1995 11:39:32 -0500
From: "K. Berry" <kb@cs.umb.edu>
Subject: Re: nits¬es on 0.68
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
1. We define an electronic "registration form" that has defined
places for a number of pieces of useful information:
I like this idea. A lot (or maybe all) of it could be pulled
automatically out of the header comments in a source file, for people
who just write a foohack.sty and want to submit it, for example.
far too little documentation, let alone active cooperation, by
the submittors.
True. And even when there is documentation, it's usually hard to find --
or at least not found by the people who most need it. After several
years of maintaining various TeX things, I've come to the conclusions
that there's no solution for this. It's just the way computers are.
That's not to say TeX packages couldn't be documented a lot better than
they are. But in the end, what we're talking about is coordinating the
efforts of ten zillion different people into a cohesive whole. It's not
going to happen. A real TeX distribution, like Pierre's, takes a lot of
work to maintain, and always will.
Enough blather.
It is clear to me that there may be occasional reasons to allow one
registered package to conflict with another, such as letting the 1.1
version of Martian use the same name space as the 1.0 version. I'm
not really clear on this part, however, so feedback is requested.
We haven't addressed handling different versions at all. We've just made
it possible for texadmins to do so within the TDS framework. Certainly
the TDS names can't include version numbers, for the usual stupid
lowest-common-denominator portability reasons. So yes, different
versions have to use the same name.
================================================================================
From owner-twg-tds@shsu.edu Sun, 19 Mar 1995 20:19:21 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 19 Mar 95 11:08:16 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68
KB> I like this idea. A lot (or maybe all) of it could be pulled
KB> automatically out of the header comments in a source file, for people
KB> who just write a foohack.sty and want to submit it, for example.
I have no problem with folks including a registration form as part of the
header comments in a single file. In fact, I think this is a good way to
keep the information from being lost. Some identifying syntax can be set
up to allow the form to be included as a comment and still be recognizable
by a script.
However...
As someone who makes his living pulling information out of header comments,
I want to assert that:
a Pulling information from randomly formatted header comments is
NOT a job for a script. Even humans have to work hard at it!
b. Forms are best prepared by someone who knows about the package.
This could be the original author or a follow-on repackager, but
a bit of knowledge is really useful!
c. I'm not volunteering the Registry committee to do the work of
comment extraction and form writing. If an individual Registry
member *also* wishes to get into that business, I have no complaint.
The basis of my idea, however, is to separate the functions of
registration form creation and acceptance. This distributes the
work, keeping us from falling into a morass of support issues.
KB> That's not to say TeX packages couldn't be documented a lot better than
KB> they are. But in the end, what we're talking about is coordinating the
KB> efforts of ten zillion different people into a cohesive whole. It's not
KB> going to happen. A real TeX distribution, like Pierre's, takes a lot of
KB> work to maintain, and always will.
The registration system will not automatically generate "drop-in" packages,
debugged packages, or complete distributions. It can, however, move us all
in the right direction. Further, the TeX community is in an unusually good
position to try something like this:
a. The presence of the CTAN and organized snapshots like TeXcetera
defines a single, important "channel" for distribution of TeX-
related freeware. This means that developers pay attention to
the CTAN. Some actively work with it!
b. The adoption of the TDS by major TeX-related freeware developers,
and the formalization of a TDS Registry, will give TDS some real
status as the "right" way to do things. A TDS Registry can take
advantage of this by giving special status to registered packages.
c. Over time, as the details of "drop-in" TDS-compliant packages are
worked out, standards can be made available to developers and re-
packagers. We don't have to enforce compliance; the presence of
appropriate "drop-in" flags in the form will lend cachet, and
users will benefit from knowing whether an *attempt* has been
made to achieve compliance. We will also have someone (the author
or supporter listed in the form) to harass if the designation is,
shall we say, overly optimistic.
d. To the extent that drop-in packages become available, the task of
creating arbitrary TeX-related distributions *will* become easier.
This won't happen overnight, but it gives us a clear goal and a
strong incentive!
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 10:32:54 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 10:18:56 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
> Here is a first try. I have not tried to get the long names out.
> general/
> NOTE errata.eight.gz errata.five.gz errata.four.gz errata.one.gz
> errata.seven.gz errata.six.gz errata.tex.gz errata.three.gz
> errata.two.gz errorlog.tex.gz
I think these errata.{one,...,eight} should be renamed to errata[1-8].tex.
Apart from the long names the problem is that all of these files would
proudce an errata.dvi with the same name when TeXed.
> fontname-1.6.tar.gz gentle.tex.gz
> history.txt.gz logmac.tex.gz tex82.bug.gz texbook.tex.gz
> tripman.tex.gz
I think logmac.tex belongs into texmf/tex/plain/base. It's a macro file
needed to run errorlog.tex through TeX, but you'll also need manmac.tex,
which presumably already resides in texmf/tex/plain/base. (BTW, you'll
also need some non-standard fonts (cmsltt9.mf) form Knuth's local files
(CTAN:systems/knuth/local/{cm,lib}) to run errorlog.tex through TeX.
One shouldn't forget about that when including errolog.tex!
> metafont/
> PXLformat.gz cm85.bug.gz mf84.bug.gz mfbook.tex.gz
I don't quite understand why you decided to put tex82.bug into general/,
but mf84.bug into metafont/. I'd prefer one of these two possibilities:
Either you put all of them in the same directory (general/ or some
subdirectory below general/) or make another subdirectory tex/ for
tex82.bug, texbook.tex, tripman.tex. And don't forget trapman.tex
if you already include tripman.tex.
> plain/
> base/
> glue.web
I'm not sure where this belongs and if this should be considered as
documentation. What about putting glue.web into web/ as well?
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:15:58 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 10:23:23 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: logos and such
Some comments on the definitions of logos and such in tdsguide.sty:
1. The definition of \acronym
\acronym{...} is currently defined as \textsc{...}. I wonder if
this really does what's intended, as using \textsc won't make much
of a difference when used with uppercase letters. If the intention
was to produce medium caps smaller than the usual uppercase letters,
it would be better to use \smsize or a variant thereof instead:
\def\acronym#1{{\protect\smsize #1}}
(And please don't try to circumvert this with \textsc and lowercase
letters, as that causes funny replacements in boldface headings.)
2. The BibTeX logo bombing out...
I think you'll either have to protect \BibTeX throughout or protect
the \smsize macro within the definition of \BibTeX:
\def\BibTeX{B{\protect\smsize IB}\TeX}
3. The AmS-TeX and AmS-LaTeX logos
All the recent versions of tdsguide.dvi show the wrong font for the
AMS logos. I wonder why you don't get any error messagess when TeXing
the document, as \fontfamily{amslogofam} won't be defined in standard
LaTeX2e. Adapted from the AmS-LaTeX documentation I'd suggest to put
the following definition into tdsguide.sty:
\def\AmSfont{\protect\usefont{OMS}{cmsy}{m}{n}}}
4. The MetaPost and METAFONT logos
A while back I asked John Hobby why he didn't use the logo font in
the distributed version of the MetaPost manuals. His answer was that
he personally preferred the spelling `MetaPost' in mixed-case roman
and he would continue to do so, but using the logo font (as Knuth
did) would be acceptable as well. Therefore, I'd suggest using the
replacement definition
\def\MP{\application{MetaPost}}
if the logo font is considered too much of a portability problem.
This replacement definition could be put at the end of tdsguide.sty
so that it can be commented out when preparing the final version
for reproduction in TUGboat, etc. For the METAFONT logo, however,
I'd suggest to continue using the logo font in any case.
Concerning the deficiencies of the logos in headlines and such,
just use the 2e package and font definition I provided and put
\usepackage{mflogo} before \usepackage{tdsguide}. For the 2.09
compatibility you could still leave the deficient definitions
in tdsguide.sty as they are already surrounded by \ifx\undefined.
It might be a good idea to use {\protect\MF} and {\protect\MP}
then in order to avoid possible problems with these definitions.
Cheers,
Ulrik.
P.S. I doubt if the current version of tdsguide.sty would run
with LaTeX 2.09 anyway, when making use of things like \f@size,
\fontsize, \fontfamily, \selectfont, etc. in the defintion of
\smsize or the \AmS logo. Well, maybe it would be better just
to throw out the 2.09 support completely.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:29:14 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 10:22:50 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: Re: 68 comments
Karl Berry wrote:
> Wasn't METAPOST typeset as {\logo META}{\tt post} for a while?
> Maybe that would be more portable for our purposes.
I don't know, but John Hobby says he personally prefers `MetaPost'
in mixed-case roman anyway, and that's the way he wrote it before
Knuth adapted the logo font. So if not using the logo font here,
I'd suggest to define \MP as \application{MetaPost} instead.
(More on logos in a separate message.)
> I find the spacing between items in all the bulleted lists too large.
I think this is due to the fact that the list environment parameters
in ltxguide.cls haven't been tuned for non-zero \parskip. Sorry
to say so, but the LaTeX list environment is really a mess with
respect to that. The NTG document classes (type 3) try to correct
all this for non-zero \parskip, but that's still rather messy.
However, I realize that it's really difficult to do better and
still keep compatibility. But I hope that's sheduled for LaTeX3.
> Also, `via \command{dvips}' seems to unnecessarily discriminate among
> dvi-to-postscript drivers.
Sorry to contradict, but there is a good reason why I put that in.
When using MF fonts for the labels included in MetaPost pictures,
MetaPost produces PS files with unresolved font references. It uses
cmr10 as if it were a built-in font and produces some header line
starting with `%*' that lists the required fonts and magnifications.
When including such MetaPost figures into a TeX document, dvips
positively knows how to handle these font requests and downloads
the required PK fonts. However I can't tell if other drivers can
do this. Therefore, I'd suggest leaving it in or maybe adding
something like `via \command{dvips} and possibly others...'.
Besides, there is an internal parameter in MetaPost that determines
whether to produce conforming PS files with structured comments
like `%% DocumentFonts'. This is used by default in troff mode,
and it might be possible in TeX mode as well, but not by default.
To get proof sheets of MetaPost figures containing TeX labels,
you normally have to call: 'tex mproof.tex figure.1 figure.2 ...'
folowed by 'dvips mproof' to get the font requests resolved.
> {\MP} can
> also process {\protect\MF} input files and searches the {\protect\MF}
> input paths
> as well when invoked on a {\protect\MF} file such as \path|logo10.mf|.
> I don't see that this is relevant to the TDS. If anything, it belongs in
> this hypothetical other document/section.
Agreed. I just put that in because I thought it might be interesting
to know which program has to look into which input paths for a given
file type. Maybe it would be useful to collect this sort of information
into another appendix or a separate document? (MetaPost is really
a complicated beast in this respect.)
> . metafont/ METAFONT (non-font) input files
> . metapost/ METAPOST input and support files
> Please, not all capitals.
Well, I thought that using all capitals was the standard repalcement
for the logo font. For `METAPOST' you could use `MetaPost', but
for `METAFONT' I don't know. Should it be `Metafont' or `MetaFont'?
(However, we needn't care about this anymore, if the explanations
could be set in roman and the proper logos could be used then.)
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 05:41:19 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 10:36:57 +0000 (GMT)
From: David Carlisle <carlisle@cs.man.ac.uk>
Subject: Re: 68 comments (MP)
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
> ....
> Besides, there is an internal parameter in MetaPost that determines
> ...
I think there is a danger of all this MP stuff getting out of hand and
distorting the TDS document. It is not supposed to be an introduction
to metapost. I would rather that as far as this document is concerned,
MetaPost was treated in the way we treat bibtex. Namely just
mentioning in a couple of lines where it fits in the tree.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 12:19:03 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 10:53:59 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68 (registration)
I fear that the registration issue is going to be a non-starter.
In terms of ctan submission, there is a simple mechanism for
preventing name clashes of directories, as the stuff is installed on
the same disk so the ctan maintainers notice if a directory of that
name is already there.
I would be very surprised if they would have the time to do more than
this (ie check that packages conformed to some minimal standard).
Sebastian?
There is already a proposal for such a minimal standard in the
latex/contrib/supported area of ctan (Joachim's work) but I think it
mainly foundered because of the effort required to enforce this (and
possibly also to agree on the minimal standard).
However not all packages are distributed from ctan. I just do not
believe that even a large minority of these distributions will fill
out TDS registration forms.
So what does the installer do, refuse to install any unregistered
packages on his local TDS tree? This seems very unlikely, so in short
time, the local TDS tree is populated with a mixed bag of registered
and unregistered packages, and then it is not clear what purpose the
registration has.
On the other hand, it would be good to have a `registration scheme', so
if someone wants to try, good luck! However I think that too strongly
tying in the TDS idea to a `registration' idea would be a bad thing,
as the former has a good chance of succeeding in practice, but
the latter is probably unfortunately doomed to failure.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 12:33:56 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68 (registration)
Date: Mon, 20 Mar 1995 11:16:38 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
i am all in favour of registration; but (speaking for George
Greenwade, Robin Fairbairns and Rainer Schoepf, i think), the current
CATN maintainers have no time to do the work. But we'd be very happy
to work with any Registry Committee or whatever.
maybe Joachim would like to comment, since he it is who drew up the
(unimplemented so far) rules for latex2e/contrib/supported
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 14:02:30 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 07:44:18 -0500
From: norm@ora.com (Norman Walsh)
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
References: <795375671.963195.BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
On 16 March 1995 at 12:41:11, BNB@math.ams.org wrote:
> i have enormous sympathy with pierre's position regarding
> <texmf>/doc/latex/base -- i'm fighting that same battle here
> regarding ams-latex (which doesn't have a separate doc area,
> driving me out of my poor, feeble mind),
Do you mean a separate doc area in the TDS? You're welcome to
texmf/doc/amslatex ;-)
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 08:04:47 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 07:54:04 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: Notes on draft 0.67
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503160942.AA10201@thphy.uni-duesseldorf.de>
On 16 March 1995 at 10:42:15, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> > The \path|plain| directory is intended for files which are
> > useful with the Plain {\TeX} format and others compatible with Plain:
> > \path|fontchart.tex|, \path|testfont.tex|,
> > \path|story.tex|, \path|manmac.tex|,
> > \path|webmac.tex|, etc., as well as \path|plain.tex| itself.
>
> I still think it should be mentioned that story.tex is an example file.
> What about rewording the sentence as follows?
>
> ! ... as well as \path|plain.tex| itself and the canonical example
> ! \path|story.tex| from \citetitle{The {\TeX}book}.
Ok.
> > The package name \path|base| is reserved for the base
> ^^^^^^^ \replaceable{package}
Ok.
> What about this (for consistency with the MF and MP sections)?
>
> ! Files used by {\iniTeX} when dumping \path|.fmt| files ...
Actually, I'm more inclined to reword the MF and MP sections...
> > Two \replaceable{package} names are reserved:
>
> Move the preceeding paragraph (speaking about \path|base|) below
> this line, make that another \item, and change `Two' to `Three'.
Check.
> > \item
> > The package name \path|misc| is reserved for packages that
> ^^^^^^^ \replaceable{package}
Check.
>
> > For PostScript fonts rendered as bitmaps with the \command{ps2pk}
> ^^^^^^^^^^ {\PS}
Check.
> * sec. 5:
>
> > \item
> > \path|modes| is reserved for files containing {\protect\MF} mode
> > descriptions for output devices, such as the quasi-canonical
> > \path|modes.mf| and any local mode definition files that might
> > be included by {\iniMF} when dumping \path|.base|
> > files containing preloaded macro definitions.
>
> I think this idea has been rejected by the majority, so this paragraph
> can vanish. However, it should be mentioned that modes.mf should go
> into \path|misc|.
Check.
> * sec. 6:
>
> After re-reading the draft as a whole, I think my write-up of the
> MetaPost section doesn't fit very well with the tone of the rest of
> the document. In particular, the first paragraph (adapted from the
> introduction of the MetaPost manual) sounds too much like advertising.
> Therefore I think the first two paragraphs of this section should be
> shortened and combined to mention only the most important facts:
Check.
> > Both documents are available as CSTR~162 and~164
> > from \path|ftp.netlib.att.com|. They are also included
> > as \path|mpman.ps| and \path|mpgraph.mp| in the {\MP}
> ^^^^^^^^^^ Sorry, make that: |mpgraph.ps|
Check.
> * sec. 8:
>
> > In the case of {\TeX} \replaceable{format}s, this will be the name
> > of the format: \path|latex|, \path|plain|, \path|amstex|, etc.
> > Directories for each \replaceable{format} should contain directories
> > for each package, in a tree paralleling the \path|tex| tree.
> > Packages that consist of only a single file, or a small number of
> > independent files, may be installed in the \path|misc|
> > package directory.
>
> Why is it \replaceable{format} but not \replaceable{package} here?
> Is it really appropriate to use \replaceable here at all?
Probably not.
> * sec. 10:
>
> The formatting of the figure got mixed up again. You have to remove
> to spaces after the replaceable items to compensate for the newly
> introduced angle brackets.
Yes, I'm not spending a lot of time on the figure until I think it's
finished.
> Also move the top-level html/, info/, and man/ below the doc/ hierarchy
> and remove metafont/modes.
Check.
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 08:12:39 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 08:01:35 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: doc files again.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <795460743.345934.BNB@MATH.AMS.ORG>
On 17 March 1995 at 12:19:03, BNB@math.ams.org wrote:
> david:
> ... I dont see that
> this is a LaTeX issue particularly.
> Where should local or contributed documentation for eplain or amstex
> go?? I would have thought it made sense to put it in a directory
> that made its contributed status clear, but is this being to
> `possesive' of the `base' directories??
>
> i think the point about the contributed status is the key.
>
> regarding ams(la)tex, if a file appears in a core ams(la)tex
> directory i believe a user would most likely expect that it came
> from ams. we agree to support what we distribute, and haven't
> got the resources to answer questions about what came from
> somewhere else. we know that a lot of users don't bother to
> read the documentation before asking for help, so let's try
> to make it easy for them to figure out where *not* to ask.
>
> i don't think "possessive" has quite the right flavor. how about
> "enlightened self interest"?
In the next draft, I've identified "<format>/base" as being intended for
the format's authors. This ought to satisfy everyone.
As I think I mentioned earlier, I'm beginning to despair of imposing
order on the doc tree to a very deep level. It's for humans, they'll
sort it out... :-(
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:16:13 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 08:56:57 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: 68 comments
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <199503171731.AA11045@terminus.cs.umb.edu>
On 17 March 1995 at 12:31:49, K. Berry wrote:
> \tableofcontents
>
> The `9 Summary' line of the contents still comes out on page 2.
> How can this be the default formatting?
Huh? On my copy, "10 Summary" comes out on page 1, but there's still a
bunch of stuff on page 2. So much stuff that it'll never be fixable.
Does it matter where the break occurs?
> particular, the TWG believes it is usable under Unix, \acronym{MS-DOS},
>
> We haven't defined `TWG' yet. I propose changing this sentence above:
>
> The primary purpose of this document is to describe a standard
>
> to this:
>
> The TUG Working Group on Directory Structure (TWG) was formed to
> describe ...
Ok.
> local system uses the {\TeX} Directory Structure recommended here.
>
> Propose another paragraph:
>
> This version is a draft. Email comments to twg-tds@shsu.edu.
Check.
> components (as in \path|texmf/fonts/|$\ldots$). This is the
>
> The linebreak after texmf/ here looks confusing to me. Maybe reword as
> ... components; for example, ...?
Check.
> Applications, like commands, are typeset in italics.
>
> You don't have the `like foo' in any of the others. Suggest dropping it.
Check. Actually, I dropped the whole thing. Ulrik has already pointed out
the remarkably tiny, and useless, distinction I'm making here...
> typefaces a site may wish to install. Listing that many directories
> would lead to paths many thousands of characters long, overflowing the
> available space on some systems.
>
> Insert `Aside from anything else,' before `Listing' (and lowercase the
> L/l :-).
Ok.
> directories to search at runtime (in the
> \systemitem{ENVIRONVAR}{TEXINPUTS} environment variable or a
>
> Change `the' to `a' before TEXINPUTS here.
Check.
> it would possibly even require recompiling software, an intolerable burden.
>
> would possibly even => could
Check.
> installer and user) for all paths, though the \acronym{TDS} requires
> subdirectory searching only for {\TeX} input files and fonts.
>
> No longer true. Suggest deleting everything after `all paths'.
Ok.
> files or environment variables
>
> Missing period.
Check.
> is imperative to a well organized \acronym{TDS}, for the reasons stated above.
>
> Hyphenate well-organized.
Ok.
> and the performance of this system is thus independent of the number
>
> the performance of this system => performance
Check.
> Having accepted that subdirectory searching was necessary, the \acronym{TWG}
>
> ... accepted the necessity for subdirectory searching
>
> filenames. In the {\acronym{ISO}-9660} format, mixed case names are not allowed.
>
> Hyphenate mixed-case. Globally. (I.e., do a global replace, this occurs
> in more than one place.)
Check.
> \acronym{OS/2}, Windows-NT, and MacOS filesystems are not
>
> Is `MacOS' a common term? I don't know, I'm not a Mac person, I'm just asking.
> Maybe just `Macintosh'?
It was Rich's suggestion to change it to MacOS. The other things listed
are OS's, so I tend to agree. Mac folks ought to know and non-mac folks
ought to be able to figure it out ;-)
> \path|OT1CMR.FD|). Unix platforms, which do have case
> sensitive filesystems, can use links to overcome any restrictions that
>
> Hyphenate case-sensitive.
Check.
> TeX-related distributions on \acronym{CD-ROM}. The only universally
>
> \TeX...
Check.
> File and directory names may not exceed eight characters.
>
> We use filename in other places to mean the entire name, including the
> directory and extension. So I suggest saying `names, not including any
> directory or extension part,'. And/or `The base part of file and ...'.
Check.
> File names may have extensions of up to three characters.
>
> Let's keep `filename'(s) as one word. Globally.
Ok.
> If a file has no name, it \emphasis{must} have an extension.
>
> The idea of a file without a name doesn't make sense to me.
> Suggest `A filename must have a base part, an extension, or both.'
I just took the sentence out. It was confusing both ways and not really
relevant to the TDS anyway.
> \literal{0}--\literal{9}, and the underscore. Note that any
>
> Delete `the' before `underscore.
Ok.
> alphabetic characters must be in upper-case.
>
> Let's not hyphenate uppercase. Globally. Ditto lowercase.
Ok.
> Many Unix systems modify the displayed
> format of {\acronym{ISO}-9660} names,
>
> Suggest: Many Unix systems display a modified format of ISO...
Check.
> Naturally, this does not affect the format of names on the CD-ROM.
>
> add `itself' after `CD-ROM', I think.
Check.
> {\TeX} system, (including {\protect\MF}, {\MP} {\protect\BibTeX}, etc., and not just {\TeX}
>
> Missing comma after MP.
Check.
> Wasn't METAPOST typeset as {\logo META}{\tt post} for a while?
> Maybe that would be more portable for our purposes.
I'm just going to drop the logofont all together and go with METAFONT
and METAPOST in small caps.
> for the input files used by {\TeX} (see \xref{Section 3, {Macros}}).
> for the (non-font) input files used by {\protect\MF} (see \xref{Section 5, {Non-font {\protect\MF} Inputs}}).
> for the font-related files (see \xref{Section 4, {Fonts}}).
>
> Delete `the' after `for' in these items. (It's inconsistently present in
> this list.)
Ok.
> for \emphasis{user} documentation (see \xref{Section 8, {Documentation}}).
>
> I find the \emphasis confusing here. What other kind of documentation
> have we been talking about?
I took out the emphasis, because it's unnecessary. However, there are other
sorts of documentation that we could be talking about (implementor, installer,
maintainer, etc.)
> for {\TeX} applications. It may be convenient to store
>
> applications. (In fact, the tex, metafont, metapost, and bibtex
> directories above may be seen as examples of this.)
Ok.
> The name ``spsun413'' is one possible {\acronym{ISO}-9660} compliant abbreviation
>
> Except it's not uppercase. Ugh.
We don't use UC anywhere else, even when we mean directories that might
go on a CD-ROM. I don't think that's a problem. I reworded the sentence a
little bit so that it doesn't sound like we mean explicitly "lowercase-s,
lowercase-p, etc." is ISO-9660 compliant, though.
> for ``sparc-sunos4.1.3''.
>
> Should have a - before the 4.
Check.
> Also, both the `spsun413' and `sparc...' should probably be in
> typewriter, not quoted roman.
Yep.
> \path|texmf/source/web2c|) and {\LaTeX} \path|dtx| sources.
>
> ... sources (\path|texmf/source/latex|).
Check.
> administrator to mount a single ``{\TeX} server'' (even in a
>
> construct a single \TeX server in a ...
Check.
> path, it is still possible to use them as macro packages under
>
> possible => straightforward
> [it would be *possible* the other way, too.]
Check.
> Two \replaceable{format} names are reserved:
>
> `The following' instead of `Two', I think. (In one place you had the
> number wrong -- we'll get to that -- and I don't see that saying the
> number of items in the list adds anything.)
Check.
> \begin{itemize}
>
> I find the spacing between items in all the bulleted lists too large.
Std LaTeX, what can I say ...
> hyphenation patterns. Thes are used only by {\iniTeX} when a new
>
> Delete `new'.
Check.
> reserved for input files that are useful across a wide range of
> formats. Generally, this means any format that uses the category
>
> ... formats (including at least \TeX and \LaTeX). Generally, ...
>
> and \path|fancyheadings| are examples of \replaceable{packages}.
>
> 1) fancyheadings can't be an example of a directory name. It's too long.
Sigh.
> 2) \replaceable{package}s, I think.
That looks ugly. I don't think it's confusing this way...
> The package name \path|base| is reserved for the base
>
> This should be the first item in the list, not a separate paragraph before.
Check.
> packages of the names listed above. {\LaTeX} packages are style files
>
> packages with the names ...
Check.
> set of files that is distributed, installed, and maintained as a
>
> Delete `that is'.
Check.
> Two \replaceable{package} names are reserved:
>
> Again, suggest `The following'.
Check.
> file and has no auxilliary packages, that file can simply be placed
>
> auxiliary
Check.
> \path|texmf/fonts/|\replaceable{type}/\replaceable{supplier}/\replaceable{typeface}/\replaceable{files}
>
> Are we doomed to have slashes in random fonts forever? Some of these are
> in cmtt, others in cmsltt.
No, not forever, just for a long time ;-)
> Type 1 fonts in \path|PFA| or \path|PFB| format
>
> Somehow I want to say `either PFA or PFB or both' here, just to
> be absolutely clear that we know we are breaking our own ``rule''.
> Perhaps we should explain why, too, out of the old mail.
> (Sorry, I'm in proofreading mode right now, don't want to look it up :-)
I put in 'or both'. I didn't try to dig up the old mail, though... :-(
> purpose; it designates fonts for which there are no licensing problems
>
> I think : instead of ;.
Ok.
> \path|adobe|,
> \path|monotype|, \path|ams|, \path|cm|, and
> \path|latex| are
> examples of \replaceable{supplier}.
>
> This sentence should be the second sentence in this item, not the
> last. And `The public directory...' sentence should probably start a new
> paragraph.
Ok.
> are very specifically defined. The \path|cm| typeface directory
>
> specifically defined. => precisely defined, as follows.
> [or make the following three sentences a three-item list, or three
> clauses after a colon, etc.]
Ok.
> for {\TeX} fonts}: CTAN:\path|info/fontname|.
>
> The : after fonts} should be `in', I think. And \replaceable{CTAN}?
> Hey, maybe \path|\replaceable{CTAN}/info/fontname| would avoid people
> thinking that CTAN is just a hostname?
I just moved it to the "References" appendix.
> $\ldots$\path|/pk/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
>
> May as well say texmf/fonts/pk instead of .../pk?
Ok.
> disadvantages. The most vexing is the fact that it creates dozens of
>
> Delete `the fact'.
Ok.
> do exist that need to have a place in the \acronym{TDS} as well.
>
> Delete `as well'
Ok.
> {\MP} is a picture-drawing language developed by John Hobby that is
> ...
> \command{dvips}.
>
> We've already talked about this a little. I think all of this (including
> the footnotes) should be somewhere else, preferably in another document
> that we point to.
Yes.
> overhead for searching this directory unnecessarily seems negligible
>
> Delete unnecessarily.
Check.
> invoking {\TeX} in a sub-process for typesetting labels.
>
> Unhyphenate subprocess.
Check.
> understand. In order to reduce the confusion, the \acronym{TDS}
> specifies a directory
>
> specifies directories
Check.
> Most packages come with some form of documentation. In order to make
>
> Delete `In order'.
Check.
> keep the documentation together and (2) make it easy for users to
>
> It's never easy for users to do anything. Suggest `straightforward'.
Ok.
> identifies the ``kind'' of documentation that resides
>
> Suggest ``kind'' => general topic
> (we're not talking about file formats only)
Ok.
> There are five reserved categories:
>
> Five seems definitely too high to count :-).
Huh?
> [ WE HAVEN'T CLEARLY SPECIFIED WHAT THE PACKAGE LEVEL IS YET ]
> Files below the \replaceable{package} level are determined by the
> documentation author. The documentation directory may contain {\TeX}
> sources, \path|DVI| files, {\PS} files, text files, or
> whatever form of documentation will best explain the package.
>
> I suggest simply dropping the package level in the schematic. We already
> explained the package case in the `In the case of TeX formats' paragraph
> above. So I suggest dropping the first sentence here, and saying `The
> documentation directories ...' instead of `directory'.
Check.
> Something like the following:
>
> Here is a skeleton of the directory structure described in this document.
>
> <texmf>/ top-level directory for \acronym{TDS} tree
>
> I hate to say it, but I think all the comments should be in roman, not
> typewriter.
This is all going to be fixed by Joachim ;-)
> . bin/*/ binaries, by system type
>
> Please append `(optionally)' or some such.
Check.
> . . . <package>/ documentation of packages (e.g., graphics, amslatex)
>
> Indentation of the comment (documenation...) is wrong here (and in many
> other places.)
Yeah.
> . . . . . <mode>/ type of output device (type pk and gf only)
> . . . . . . <dpi>/ font resolution (type pk and gf only)
>
> I find the double usage of `type' confusing. Suggest `for pk...' instead
> of `type pk...'.
Check.
> . . html/ hypertext docs (produced by e.g., texi2html or latex2html)
>
> Comma before e.g.
Ok.
> . . info/ processed Texinfo documents
>
> Append `(produced by, e.g., makeinfo)'.
Ok.
> . metafont/ METAFONT (non-font) input files
> . metapost/ METAPOST input and support files
>
> Please, not all capitals.
Check.
> . <program>/ TeX applications, by name (e.g., makeindex)
>
> I think `dvips' is worth adding after makeindex. And it should be
> makeindx, anyway.
Check.
> Like the title says $\ldots$
>
> I'm not sure we have anything to say here. What did you have in mind?
I ripped it out, for now.
Ok.
> This appendix is for pointers to files we mention in this draft.
>
> Not just files, but other documents. I wonder if it should be a bibliography.
I think that's been fixed. It probably should be a bibliography...
> By the way, I hope this document itself will be producible in Texinfo
> and HTML formats, so that hypertext links can be made right, etc.
Yeah, I've got an HTML filter now and a Texinfo filter is high on my list.
> Sebastian suggests: it may be sensible to note that this group only existed by
> email, just in case people think we have been meeting in person at
> vast cost.
>
> I agree. How about this:
>
> The TWG had no formal meetings (many but not all members attended TUG
> '94). All discussions were held by email. (Archived on shsu.edu:twg-tds.)
>
> Berry, Karl (\literal{kb@cs.umb.edu}). Denies all affiliations ;-) [ yes, this has to come
> out before the draft goes public ]
>
> You can say `Maintainer of Web2c, Eplain, modes.mf, et al.'.
Check.
> Joachim Schrod (\literal{schrod@iti.informatik.th-darmstadt.de}). Scientific Assistant, Computer Science Department,
>
> You mean Schrod, Joachim. Though I think it would be a cute informal
> touch to put first-name-first, and sort on first name for a change. It
> doesn't make any real difference.
For a list this short, it'd be ok. But it's very counter-intuitive.
Our internal company phone directory is sorted that way and I invariably
spend 15 seconds figuring out why I can't find the person I'm looking for.
I should just stick with the online system, I guess ;-)
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:21:03 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 08:59:11 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: doc files again.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <199503171834.AA29233@ra.cs.umb.edu>
On 17 March 1995 at 13:34:31, K. Berry wrote:
> In doc/latex/arabtex/<whatever> (following the "martian" example)
> "latex" means "this is *NOT* about
> LaTeX, it is about arabtex, but it has to be processed through LaTeX
> before you can read it."
>
> I say this.
>
> The format the documentation is in is irrelevant.
> (Except for the machine-readable .info/.html/.[123456789l]!)
>
> Whether the documentation is written in Texinfo or LaTeX or Martian TeX,
> it still describes arabtex, and thus should go in an arabtex directory.
I concur.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:17:22 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 08:59:57 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: doc files again.
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503171837.AA07967@r8d.cs.man.ac.uk>
On 17 March 1995 at 18:37:38, David Carlisle wrote:
>
>
> In doc/plain/<whatever> "plain" seems to mean "ordinary ascii"
> which is to say, readable without any preprocessing.
> In doc/latex/<whatever> "latex" appears to mean "this is about latex"
> sometimes, and "this has to be run through latex" at others.
>
> I thought that in both cases it meant `about' as in `about plain TeX'
> and `about latex'
Yes.
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 10:00:11 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 09:18:00 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: nits¬es on 0.68
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503180338.AA16671@cfcl.com>
On 17 March 1995 at 19:38:37, Rich Morin wrote:
> 1. Section 1.1
>
> ... and in-use, ...
> ... and in use, ...
Check.
> 2. I think you need to decide whether to use typewriter oblique
> or angle brackets to indicate replaceable text, and document
> accordingly. At present, the figure uses brackets, but the
> note in Section 1.2 doesn't explain this usage. My opinion
> is still that typewriter oblique is too hard to tell from non-
> oblique, and that some other differentiation should be made.
I'm pushing some things, like subtle typography differences, off into the
future. I *know* they are important, but I want to be *finished* writing
this document as soon as possible.
> 3. Section 2.2
>
> The last sentence in the second paragraph is unwieldy. How about:
>
> ... environments and that filenames ... case, are ...
> ... environments. Filenames ... case are ...
Ok.
> And, at the top of the following paragraph:
>
> ... script files, however, ...
> ... script files. Fortunately, ...
Check.
> KB is unclear about why the example:
>
> texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
>
> is needed. I like Norm's response, and assure him that this
> point is one of the most frequently confused parts of the
> ISO-9660 specification. So, I suggest using Norm's example
> AND my example, with the addition of a bit of annotation, as:
>
> =============================================================
> Only eight levels of directories are allowed, including the top-
> level (mounted) directory. Thus, the deepest valid TDS path is:
>
> texmf/L2/L3/L4/L5/L6/L7/L8/FOO.BAR;1
> 1 2 3 4 5 6 7 8
>
> Here is a typical TDS-oriented example, using only seven levels:
>
> texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
> 1 2 3 4 5 6 7
I'll try taht.
> 4. The last sentence in the footnote on page 8 should read:
>
> TDS packages are sets of files that are ... as units.
Check.
> 5. Section 4.1, paragraphs two and three
>
> To construct clean sentences, common practice is not to use
> this sort of construction! How about:
>
> Fonts with different device types (modes) are generally
> segregated into separate directories.
>
> Two naming strategies are commonly used to identify
> the resolution of bitmap font files. ...
Check.
> 6. paragraph four:
>
> Since the ...
> Because the ...
Ah, yes, *that* distinction. You don't know how many times my editor
changed "since" to "because" in _Making TeX Work_. You really don't.
> use the latter scheme ...
> use the latter (directory-based) scheme ...
Ok.
> 7. Section 4.1.1
>
> The first sentence in the last paragraph goes on far too long.
> (California law doesn't allow three-trailer semi's, Norm! :-)
> I'm not sure how to chop it up, but how about:
>
> information: if ...
> information. If ...
Ok.
> ... from (or that is, in fact) the ...
> ... from the ...
Karl wanted the parenthetical. Derived from doesn't generally conote
"the same as", so I think it better stay.
> 8. Section 8
>
> option was placing them ...
> option was to place them ...
Check.
> texmf/doc/category/package/...
> ^^^^
> I would stay in typewriter font for the "/..." above.
Ok.
> 9. Section 10
>
> I'm not real excited about indenting the descriptive info.
> If you're going to indent, use two spaces per level, to
> match the left side of the figure.
>
> I also think that someone is going example-happy, and that it
> makes the descriptive info busy and hard to read. Trim the
> "e.g."s back to one (or at most, two) names.
We'll see how it looks formatted by Joachim's macros...
> Appendix A
>
> There is no concensus on how TDS implementation should be achieved,
> or even on what the key problems are. Further, I don't want to delay
> the TDS an iota by trying to achieve concensus at this point. So,
> here's some hand-waving which most of us *may* be able to accept. I'm
> sorry it's a bit verbose; suggestions are requested.
>
> ========================================================================
>
> A Implementation Issues
For the moment, I've inserted Rich's suggestions wholesale. I may or may
not edit them before posting 0.69.
> KB> We use filename in other places to mean the entire name, including the
> KB> directory and extension. So I suggest saying `names, not including any
> KB> directory or extension part,'. And/or `The base part of file and ...'.
>
> I can't visualize what the result of all KB's edits would be (and I'll let
> Norm hack up the text), but I think KB's on the right track. I wrestled
> with the problem a bit, and I'd be happy to see the language clarified.
>
> I *would* suggest the UNIX usage "basename", rather than "base part".
'cept I threw the sentence out ;-)
--norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:33:25 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 09:19:01 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: nits¬es on 0.68
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <199503181244.NAA20066@spock.iti.informatik.th-darmstadt.de>
On 18 March 1995 at 13:44:28, Joachim Schrod wrote:
> I didn't even understand what was meant with `implementation' in that
> context. But now I see what you're meaning. It's a well-written
> section, I don't think it's too verbose. The only problem, I see
> currently, is the last paragraph
>
> > Efforts are under way to set up a "TDS Registry" that will coordinate the
> > assignment of TDS-compliant directory names and provide a definitive
> > database of TDS-compliant software distributions. Interested parties
> > should peruse CTAN:??? or send email to tdsr@cfcl.com.
>
> Speaking as a macro developer -- if somebody tells me what a
> ``TDS-compliant software distribution'' is, I might consider
> registration for some packages... :-)
I've left it alone for the moment, there's more mail about this later
in my queue, and I may edit it out before I'm done.
--nomr
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 15:50:56 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 09:24:10 -0500
From: norm@ora.com (Norman Walsh)
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
References: <199503190037.QAA22006@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 18 March 1995 at 16:37:22, Pierre MacKay wrote:
>
> Here is a first try. I have not tried to get the long names out.
> In the case of gzipped files, what does one do?
I don't think you have to get the long names out. The CD-ROM restrictions
are important for selecting names mentioned in the TDS spec, and it's a good
idea to point them out to folks, but for distribution of Unix TeX, I don't
think you should worry about it. Unless you're going to start distributing
it on CD-ROM, of course ;-)
> doc/
> dvips/
> general/
> help/
> kpathsea/
> latex/
> arabtex/
> base/
> metafont/
> plain/
> arabtex/
> SEElatex
> base/
> web/
I like it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:45:21 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 09:27:59 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: TDS with PasTeX on Amiga
Sender: owner-twg-tds@SHSU.edu
To: twg-tds@shsu.edu
Cc: scherer@genesis.informatik.rwth-aachen.de
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <12FA54E6A72@genesis.informatik.rwth-aachen.de>
On 20 March 1995 at 09:18:34, Andreas Scherer wrote:
> After another round of playing with PasTeX this weekend, I have to admit
> that my statements in the previous mail were not correct, due to a typical
> case of `RTFM'.
>
> Even with the current configuration setup there is in fact a way for
> ShowDVI and DVIprint to conveniently support the TDS ideas.
Great.
> It is at this point that I would like to repeat my suggestion that the name
> of the <driver>, here `amiga', should move further up in the directory
> structure, e.g.,
Yeah, I can see how
texmf/fonts/pk/<mode>/<dpi>/supplier/typeface
is easier to work with than
texmf/fonts/pk/supplier/typeface/<mode>/<dpi>
for this kind of thing.
I'm resistant to changing it before a public release of the draft, but
I'm not resistant in general.
Perhaps it's best not to wait, what do you all say?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:52:36 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 09:31:55 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: logos and such
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503200923.AA12653@thphy.uni-duesseldorf.de>
On 20 March 1995 at 10:23:23, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> 1. The definition of \acronym
>
> \acronym{...} is currently defined as \textsc{...}. I wonder if
> this really does what's intended, as using \textsc won't make much
> of a difference when used with uppercase letters. If the intention
> was to produce medium caps smaller than the usual uppercase letters,
> it would be better to use \smsize or a variant thereof instead:
>
> \def\acronym#1{{\protect\smsize #1}}
>
> (And please don't try to circumvert this with \textsc and lowercase
> letters, as that causes funny replacements in boldface headings.)
Um, ok. I'll look into it.
> 2. The BibTeX logo bombing out...
>
> I think you'll either have to protect \BibTeX throughout or protect
> the \smsize macro within the definition of \BibTeX:
>
> \def\BibTeX{B{\protect\smsize IB}\TeX}
I *swear* I tried this and it didn't help, but I'll try again.
> 3. The AmS-TeX and AmS-LaTeX logos
>
> All the recent versions of tdsguide.dvi show the wrong font for the
> AMS logos. I wonder why you don't get any error messagess when TeXing
> the document, as \fontfamily{amslogofam} won't be defined in standard
> LaTeX2e. Adapted from the AmS-LaTeX documentation I'd suggest to put
> the following definition into tdsguide.sty:
>
> \def\AmSfont{\protect\usefont{OMS}{cmsy}{m}{n}}}
I'll try that. Actually, I do get errors, but I've been ignoring them ;-)
> 4. The MetaPost and METAFONT logos
>
> A while back I asked John Hobby why he didn't use the logo font in
> the distributed version of the MetaPost manuals. His answer was that
> he personally preferred the spelling `MetaPost' in mixed-case roman
> and he would continue to do so, but using the logo font (as Knuth
> did) would be acceptable as well. Therefore, I'd suggest using the
> replacement definition
>
> \def\MP{\application{MetaPost}}
All righty then.
> Concerning the deficiencies of the logos in headlines and such,
> just use the 2e package and font definition I provided and put
> \usepackage{mflogo} before \usepackage{tdsguide}. For the 2.09
> compatibility you could still leave the deficient definitions
> in tdsguide.sty as they are already surrounded by \ifx\undefined.
> It might be a good idea to use {\protect\MF} and {\protect\MP}
> then in order to avoid possible problems with these definitions.
>
> P.S. I doubt if the current version of tdsguide.sty would run
> with LaTeX 2.09 anyway, when making use of things like \f@size,
> \fontsize, \fontfamily, \selectfont, etc. in the defintion of
> \smsize or the \AmS logo. Well, maybe it would be better just
> to throw out the 2.09 support completely.
Maybe. Phil already suggested it, and I'm sure the LaTeX folks
would have no objection ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 09:44:37 EST
Return-path: <owner-twg-tds@SHSU.edu>
Date: 20 Mar 1995 09:33:48 -0500
From: norm@ora.com (Norman Walsh)
Subject: Re: 68 comments (MP)
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Errors-to: owner-twg-tds@SHSU.edu
Warnings-to: <>
Reply-to: TWG-TDS@SHSU.edu
Content-transfer-encoding: 7BIT
X-ListName: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
References: <9503201036.AA09462@r8d.cs.man.ac.uk>
On 20 March 1995 at 10:36:57, David Carlisle wrote:
>
> > ....
> > Besides, there is an internal parameter in MetaPost that determines
> > ...
>
> I think there is a danger of all this MP stuff getting out of hand and
> distorting the TDS document. It is not supposed to be an introduction
> to metapost. I would rather that as far as this document is concerned,
> MetaPost was treated in the way we treat bibtex. Namely just
> mentioning in a couple of lines where it fits in the tree.
I think David's right. I'll work on rewording it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 16:16:04 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 14:44:38 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Cc: scherer@genesis.informatik.rwth-aachen.de
Subject: Re: TDS with PasTeX on Amiga
> I'm resistant to changing it before a public release of the draft, but
> I'm not resistant in general.
I think that echoes the comment I made, but if we all end up saying,
we should change it, but not now, then.....
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 16:58:31 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 14:52:20 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: logos and such
> > P.S. I doubt if the current version of tdsguide.sty would run
> > with LaTeX 2.09 anyway, when making use of things like \f@size,
> > \fontsize, \fontfamily, \selectfont, etc. in the defintion of
> > \smsize or the \AmS logo. Well, maybe it would be better just
> > to throw out the 2.09 support completely.
> Maybe. Phil already suggested it, and I'm sure the LaTeX folks
> would have no objection ;-)
Although I don't really mind if it runs with 2.09 either:-)
If we are planning to distribute this as dvi/ps/html/pdf?/sgml??/...
then 2.09 sites should not be too seriously disadvantaged if they can
not latex the tex source, so if it ends up that you have to put \if...
all over the place to support 2.09, it is probably best just to remove
the support.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 17:00:52 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS with PasTeX on Amiga
Date: Mon, 20 Mar 1995 15:39:39 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
since norm asks, the fonts tree is already so fragmented, why not move
mode up and supplier down? since we have to have a script to populate
this, i'm easy
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 17:14:46 MET
Return-Path: <owner-twg-tds@SHSU.edu>
Errors-To: owner-twg-tds@SHSU.edu
X-Listname: TUG Technical Working Group -- Directory Structures (WG-94-07)
<TWG-TDS@SHSU.edu>
Warnings-To: <>
Errors-To: owner-twg-tds@SHSU.edu
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: Guidelines for LaTeX bundles [was: Re: nits¬es on 0.68
(registration)]
To: TWG-TDS@SHSU.edu
Date: Mon, 20 Mar 1995 16:43:25 +0100 (MEZ)
Content-Type: text
Rich:
> I think one of the problems with freeware archiving in general,
> and the current CTAN collection in particular, is that there is
> far too little documentation, let alone active cooperation, by
> the submittors. As a result, for instance, there is no standard
> "announcement" file for packages, containing information on each
> package's purpose, origin, status, etc.
>
> [longer list of actions deleted]
There is another issues involved, besides the ones you listed:
Registered packages must be supported and the supporter must
acknowledge that periodically. Otherwise an other developer cannot
take over the work of somebody.
On the particular issue of LaTeX distribution packages (aka bundles):
David:
> There is already a proposal for such a minimal standard in the
> latex/contrib/supported area of ctan (Joachim's work) but I think it
> mainly foundered because of the effort required to enforce this (and
> possibly also to agree on the minimal standard).
sebastian:
> maybe Joachim would like to comment, since he it is who drew up the
> (unimplemented so far) rules for latex2e/contrib/supported
Well, very similar to, but not _exactly_ my view of this affair... ;-)
First, for those who don't know it: The proposal describes the
guidelines for the minimal structure of the distribution of a
supported LaTeX 2e bundles. (Bad English, I know.) It's available as
ftp://ftp.th-darmstadt.de/pub/tex/latex/bundle-dist.tex.gz ; it is a
gzipped LaTeX2e document.
It's unimplemented in the sense that this rules are not in effect.
It's ``implemented'' in so far as I have written Perl scripts that
check bundles if they conform to the guidelines.
The effect foundered because we were not successful in setting up a
procedure to maintain the supported area. The problem involves myself
(I didn't push the CTAN team enough) and the CTAN team (they didn't
respond to queries of mine, respectively to problems reports). It's
important for me to point out that I don't blame them; I simply think
it isn't too high on the priority list, running CTAN itself is
already more than enough work.
The effort to check for conformance is not very high, it can be (and
is partly) automated. Perl is a very effective tool in that problem
domain. ;-)
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, 20 Mar 1995 10:54:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 11:55:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201655.AA21369@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 68 comments
I'm just going to drop the logofont all together and go with METAFONT
and METAPOST in small caps.
How about `Metafont' and `MetaPost', in roman?
We're spending way too much time on this :-).
>> There are five reserved categories:
> Five seems definitely too high to count :-).
Huh?
I.e., say `The following categories are reserved'.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:04:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 12:03:37 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201703.AA21449@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: logos and such
then 2.09 sites should not be too seriously disadvantaged if they can
I was the one who suggested 2.09 be supported.
I withdraw my suggestion.
As David says, the existence of .dvi/.ps/.whatever versions ought to
satisfy everyone.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:07:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 12:02:41 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503201702.MAA15073@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 68 comments
References: <199503201655.AA21369@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 20 March 1995 at 11:55:14, K. Berry wrote:
> I'm just going to drop the logofont all together and go with METAFONT
> and METAPOST in small caps.
>
> How about `Metafont' and `MetaPost', in roman?
> We're spending way too much time on this :-).
Indeed. Fine.
> >> There are five reserved categories:
> > Five seems definitely too high to count :-).
Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:17:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 12:14:59 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201714.AA21500@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS with PasTeX on Amiga
texmf/fonts/pk/<mode>/<dpi>/supplier/typeface
I don't think I have any objection to changing to this.
Or should it be pk/<dpi>/<mode>? I don't know.
Pierre, do you see any issue with this? As long as supplier/typeface
loses, it may as well lose totally, right?
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:20:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 12:17:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201717.AA21509@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 68 comments
do this. Therefore, I'd suggest leaving it in or maybe adding
something like `via \command{dvips} and possibly others...'.
Fine.
file type. Maybe it would be useful to collect this sort of information
into another appendix or a separate document? (MetaPost is really
I think another file (metapost-intro or some such) is the right place to
explain all the ins and outs of MetaPost. I can include it in the next
web2c distribution.
The TDS, as David suggested, should just say where the files go. IMHO.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:23:27 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Guidelines for LaTeX bundles [was: Re: nits¬es on 0.68 (registration)]
Date: Mon, 20 Mar 1995 16:54:27 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:020470:950320165450"@cl.cam.ac.uk>
re the "supported bundle" thing, I think it is well worth while
resurrecting it, if Joachim can retrieve the outstanding problems.
maybe Rich can grab it and comment, and it might be a sensible way forward
to get this working as a test of a larger system.
i notethat i at least have been conforming to it, as i interpret it
:-}
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:23:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 12:22:41 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201722.AA21571@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nits¬es on 0.68
a Pulling information from randomly formatted header comments is
NOT a job for a script. Even humans have to work hard at it!
It's not random, it's header = "value".
The point is just to adapt existing headers for some of the info you
need, and promulgate standard names for the others.
Anyway, I think we all agree a registry is a good idea in general.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:32:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 17:31:07 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950320173107.224330bb@vms.rhbnc.ac.uk>
Subject: Re: TDS with PasTeX on Amiga
>> Subject: Re: TDS with PasTeX on Amiga
But assuming we're talking about other systems, as well as PasTeX on an Amigas:
>> texmf/fonts/pk/<mode>/<dpi>/supplier/typeface
>> I don't think I have any objection to changing to this.
>> Or should it be pk/<dpi>/<mode>? I don't know.
>> Pierre, do you see any issue with this? As long as supplier/typeface
>> loses, it may as well lose totally, right?
Is it not the case that <dpi> must be the terminal node, at least if
existing drivers are to be capable of working with a TDS structure?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 11:32:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 95 09:29:31 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503201729.AA26248@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: TDS Registry
I have looked over Joachim's guidelines. I think they look very useful,
if a bit rough in spots. (No rougher than some of the TDS drafts! :-)
I think, in fact, that the guidelines should receive some editorial help
and attention, and that they might well become a *very* useful guide.
Anyway, attached below is the portion that seems most relevant to the
TDS Registry, edited into an approximate ASCII rendition. Please note
that I am not discounting the value of the other files Joachim requests.
I just don't think we can ask the Registry to handle the task of dealing
with them, and I'm also afraid the extra burden might keep some authors
from attempting registration. So, regretfully, we punt (for now)...
I have no problem with the chosen format. It looks machine-readable
*and* easy for humans to edit and read. Nor do I have any quibble with
Joachim's defined fields. I would, however, add a few, such as:
Get-From: (how and where can I get the latest version?)
TR-Date: YYYYMMDD.HHMM (GMT reg. date; added by TDS Registry)
TR-Usage: whitespace separated path names (M)
=========================================================================
Format of the Catalogue File
The catalogue file (mandatory:catalogue from above) is the only file
in your distribution where we demand a fixed name *and* a fixed format
for the contents. This file is the token we keep for your bundle; we
must be able to extract information from it automatically.
The format of the file is similar to the header of a mail file (see RFC
822). This also corresponds to the entry format of David Jones' "Styles
Catalog" (aka TeX Macro Index). The file consists of fields: each field
starts with a name in column 1; continuation lines start with white space.
The field name is terminated by a colon, and is case-insensitive (Upper-
and lowercase letters are not distinguished). Fields with the following
names must be supplied by you:
Name:
The name of your bundle. Please use only letters and digits in this
name; this will be the name of the directory where your bundle is
placed. You might want to take care of users with crippled systems
and restrict the length of this name to 8 or 14 characters.
Problems-To:
The email address an author shall use if a problem report must be
sent. If you don't have an email address, you *must* add an "Address"
field with your postal address (see below).
The email address must be in Internet/ARPA style, as specified by
RFC 822, <name@domain>.
Author:
Your full name. You might want to add an email address, if the
problem report address is not the same as yours, or if you name
multiple authors here. It's recommended to put the email address
in angles: <name@domain>.
Version:
Version number and release date of this bundle's revision.
But, since you're creating this file anyhow, how about adding the rest
of the fields as well? It's not mandatory, but it makes you look good...
Description:
Up to ten lines that describe your bundle. Some kind of mini-abstract,
an executive summary, if one dare say.
Keywords:
Some keywords you think would characterize the facilities provided
by your bundle.
See-Also:
A list of other bundles that provide similar features and might be
of interest for an author.
Note:
Any additional information which seems pertinent.
Address:
Your postal address. (You might want to omit a private phone number,
it's reported that people got phoned in the middle of the night.)
If you supply these fields, an update for David Jones' TeX macro index
will be created automatically; you don't have to burden yourself with it.
Name: bundle name (M)
Problems-To: email address (M)
Author: free text (M)
Version: free text (version and date) (M)
Description: free text
Keywords: free text
See-Also: list of bundle or module names
Note: free text
Address: free text
Confirmation of Support
>From our viewpoint, the main problem is not to add a bundle to the
"supported area", but the decision when we have to remove it from
there. We need your cooperation to handle that.
First, if you decide at some point in the future that you won't
actively support this bundle any more---send us some mail. We will
*not* throw your software away; it will just be moved to a different
area, and will still be accessible like it was before. Thank you in
advance.
Nevertheless, we might need a bit more cooperation. If you don't
send us an update for your bundle for a year, we'll send you email
asking for a confirmation that you still support it actively. If we
don't receive a confirmation within two months, we will send another
email message. Then we wait for one month; if you haven't answered
by then, we will assume that your bundle as not supported any more.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 13:03:01 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 20 Mar 1995 11:03:36 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201903.LAA11145@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
> general/
> NOTE errata.eight.gz errata.five.gz errata.four.gz errata.one.gz
> errata.seven.gz errata.six.gz errata.tex.gz errata.three.gz
> errata.two.gz errorlog.tex.gz
I think these errata.{one,...,eight} should be renamed to errata[1-8].tex.
Apart from the long names the problem is that all of these files would
proudce an errata.dvi with the same name when TeXed.
I simply retained DEKs names for all these. Since they appear to
represent superseded versions of the errata file, perhaps they should
go into a separate directory, and only errata.tex.gz be left in the
basic directory. I guess there is no problem with changing to
errata1.tex.gz etc.
> fontname-1.6.tar.gz gentle.tex.gz
> history.txt.gz logmac.tex.gz tex82.bug.gz texbook.tex.gz
> tripman.tex.gz
I think logmac.tex belongs into texmf/tex/plain/base.
Of course. It will be moved.
(BTW, you'll
also need some non-standard fonts (cmsltt9.mf) form Knuth's local files
(CTAN:systems/knuth/local/{cm,lib}) to run errorlog.tex through TeX.
Any harm in putting such font sources in texmf/fonts/public/extracm ?
> metafont/
> PXLformat.gz cm85.bug.gz mf84.bug.gz mfbook.tex.gz
People should regard metafont as an equal part of the package, but
they don't. I thought about this for some time, and decided
that it would make the metafont stuff more recognizable to those
who really have an interest if it is under doc/metafont/
I am not firmly committed to this. What do others think.
And don't forget trapman.tex
if you already include tripman.tex.
Thanks for the reminder
> plain/
> base/
> glue.web
I guess it's a matter of whether it is more about glue or more about
web, but I suspect you are right.
Anyway, many thanks for your immediate response. There is nothing
like a concrete example to get these things decided intelligently.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 13:14:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 20 Mar 1995 11:14:34 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201914.LAA12516@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
I am not in any position to complicate my life with attempting
to distribute on CD-ROM, and anyway others are doing it quite
satisfactorily. But it seems to me that as long as
it is possible to keep to a set of names and conventions
that can be used outside Unix, it is a good idea to do so.
Otherwise, if the Unix approach is to go off on its own entirely---a
somewhat tempting possibility---the whole mess of dpinnn/<font>.pk
files is unnecessary, not to mention the <format>/<source> ordering
to which we have been dragged kicking and screaming.
Recent guidance is very helpful, but I would say that if I could so
misunderstand the language about doc/<format> it is possible
that others might too.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 13:35:37 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 20 Mar 1995 11:34:29 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503201934.LAA14202@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TDS with PasTeX on Amiga
texmf/fonts/pk/<mode>/<dpi>/supplier/typeface
I don't think I have any objection to changing to this.
Or should it be pk/<dpi>/<mode>? I don't know.
Pierre, do you see any issue with this? As long as supplier/typeface
loses, it may as well lose totally, right?
As someone (David?) just said, if we don't do it now, then when?
It strikes me as a scheme that would drive anyone who wants access to
more than half a dozen faces right up the wall. I think I will have to
develop a script to reverse this fragmentation for Unix sites.
But as Karl says, once we have lost on supplier/typeface, the rest
doesn't really matter all that much.
But isn't it going to do strange things to path searching when <font>.pk
is not directly resident in dpinnn/ ? And what about the often
expressed desire to have MakeTeXPK put fonts right into their
assigned directories? (I am still not sure that that should be done
in any case. Surely a crontab script, or its equivalent, is a better
notion.)
Path searching just gets better and better, and it is eventually going
to be seen as a necessity. While compromises can be and have been made
no path organization that genuinely sets it back should be adopted
for an ephemeral advantage.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Mar 1995 13:48:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 20 Mar 1995 14:42:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503201942.OAA18543@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS with PasTeX on Amiga
References: <199503201934.LAA14202@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 20 March 1995 at 11:34:29, Pierre MacKay wrote:
>
> But isn't it going to do strange things to path searching when <font>.pk
> is not directly resident in dpinnn/ ? And what about the often
> expressed desire to have MakeTeXPK put fonts right into their
> assigned directories? (I am still not sure that that should be done
> in any case. Surely a crontab script, or its equivalent, is a better
> notion.)
Phil pointed this out, and it basically shoots down the suggestion.
The dpinnn directory has to be at the bottom. And mode might as well
be down there to.
Cheers,
norm
P.S. I suppose one could argue that it doesn't have to be at the bottom,
but part of the reason for the compromise was to make adapting the TDS
easy for developers...
---
Norman Walsh <norm@ora.com> | Television: A medium. So called because it is
Production Tools Specialist | neither rare nor well done. -- Ernie Kovacs
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 04:05:46 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS Registry
Date: Tue, 21 Mar 1995 10:04:26 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:129720:950321100433"@cl.cam.ac.uk>
maybe i havent read messages craefully enough, but what does field
TR-Usage do?
i am also bothered by Get-From; if this is on CTAN, we dont wantt o
give any impression that we dont have the latest; if we know of a
later version, we'll get it. if we dont, we wont update that field
properly anyway. the history of archives and ftp sites is littered
with non-existent or wrong ftp URLs...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 05:28:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Mar 1995 11:29:08 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950321112908.2244244f@vms.rhbnc.ac.uk>
Subject: Re: TDS Registry
>> i am also bothered by Get-From; if this is on CTAN, we dont wantt o
>> give any impression that we dont have the latest; if we know of a
>> later version, we'll get it. if we dont, we wont update that field
>> properly anyway. the history of archives and ftp sites is littered
>> with non-existent or wrong ftp URLs...
I'm not sure I agree with SPQR here: if a file has an associated `Get-From: '
field, doesn't that make the automation of CTAN much simpler? CTAN sites
already mirror each other: does it not make sense for mirroring also to be
carried out at the package level, so that any developer changes are
automatically mirrored on CTAN at the earliest available opportunity?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 06:00:47 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS Registry
Date: Tue, 21 Mar 1995 11:59:45 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:185410:950321115954"@cl.cam.ac.uk>
> I'm not sure I agree with SPQR here: if a file has an associated `Get-From: '
gasp
> field, doesn't that make the automation of CTAN much simpler? CTAN sites
> already mirror each other: does it not make sense for mirroring also to be
> carried out at the package level, so that any developer changes are
> automatically mirrored on CTAN at the earliest available opportunity?
>
you misunderstand CTAN. we dont mirror each other, as a whole. we
mirror individual packages, and maintain a database of them with their
authoritative hosts. one could argue that the catalog file should be
the master repository of this information, indeed. but my concern is
that we dont *encourage* people to go looking for it on the original
sites, because thats inefficient.
i dont feel that strongly, i admit
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 06:11:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Mar 1995 12:11:36 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950321121136.2244910a@vms.rhbnc.ac.uk>
Subject: Re: TDS Registry
>> you misunderstand CTAN. we dont mirror each other, as a whole. we
>> mirror individual packages, and maintain a database of them with their
>> authoritative hosts. one could argue that the catalog file should be
>> the master repository of this information, indeed. but my concern is
>> that we dont *encourage* people to go looking for it on the original
>> sites, because thats inefficient.
OK, understood: but just because a package (yes, I admit it, I hate the
word `bundle') writer provides `Get-from: ' data doesn't mean that it
can't be filtered out before making the package available on CTAN,
does it? Then the `Get-from: ' info can be retained for CTAN use but
not otherwise disseminated...
** Phil.
>> i dont feel that strongly, i admit
Perhaps you need more iron in your diet:-)
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 11:00:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Mar 95 09:01:17 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503211701.AA01123@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS Registry
SR> maybe i havent read messages craefully enough, but what does field
SR> TR-Usage do?
You haven't (:-). It contains names of directories (or in the case of
some small packages, files) that this package has *reserved* in the TDS
Registry name space, as:
texmf/doc/latex/martian/
texmf/doc/plain/martian/
texmf/fonts/source/public/martian/
texmf/fonts/tfm/public/martian/
texmf/tex/hyphen/martian/
texmf/tex/latex/martian/
texmf/tex/plain/martian/
SR> i am also bothered by Get-From; if this is on CTAN, we dont wantt o
SR> give any impression that we dont have the latest; if we know of a
SR> later version, we'll get it. if we dont, we wont update that field
SR> properly anyway. the history of archives and ftp sites is littered
SR> with non-existent or wrong ftp URLs...
If the CTAN is willing to stand as a definitive archive site for a given
package, I have no problem with listing some form of CTAN-based location.
I'm also quite happy to let the CTAN folks deal with the details of this.
Some packages may not be appropriate for the CTAN, however. Proprietary
packages, in particular, will not generally be on the CTAN. By listing
the information on how to get them, they can take part in the Registry
without having to submit freely redistributable code.
-r
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 14:20:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Mar 1995 15:15:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503212015.PAA20538@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Announce: 0.69
Reply-To: TWG-TDS@SHSU.edu
0.69 is now available from
ftp://jasper.ora.com/private/twg-tds/tdsguide.*
You will find LaTeX (.tex), texinfo (.texi), info (.info), HTML (.htm),
DVI (.dvi) and PostScript versions (.ps) there. Plus all the source
SGML files.
Happy now? ;-)
P.S. To format it yourself, you'll need the new style files "tdstable.sty".
----------------------------------------------------------------------
Joachim,
Thanks for the macros to typeset the table. They look great. Just
one problem:
\end{tdsSummary} complains ... "perhaps a missing \item?"
I haven't tried to figure out what's wrong ...
----------------------------------------------------------------------
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Mar 1995 19:01:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Mar 95 17:02:04 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503220102.AA02851@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: 0.69 notes
1. page 5
... not including any directory or extension part,
... not including any directory path or extension,
2. page 6
... only sevel levels.
... only seven levels.
3. pages 14-15
The descriptive text for the figure is extending well past the
margin. Part of this is due to the four-character indentation;
much of the reaminder is due to multiple example names.
I also think the vertical lines of dots assist the reader in
tracking levels, particularly when shallow (e.g. two character)
levels are used.
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 04:31:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 11:20:05 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221020.AA15440@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: doc files again.
Pierre MacKay wrote:
[Re: errata files]
> I simply retained DEKs names for all these. Since they appear to
> represent superseded versions of the errata file, perhaps they should
> go into a separate directory, and only errata.tex.gz be left in the
> basic directory. I guess there is no problem with changing to
> errata1.tex.gz etc.
No, I don't think they represent superseded versions. errata.tex
holds the latest changes after the ``final'' revision of the books.
errata.one to errata.eight contain earlier changes that should be
already included in the latest revisions. Whether you'll need them
or not depends on which printing of the TeXbook/MFbook you have.
And even if you have a recent printing you can't be sure of
surprises. (But you may be rewarded $2.56 if you find something!)
[Re: Knuth's local/cm]
> Any harm in putting such font sources in texmf/fonts/public/extracm ?
Personally, I'd prefer ..fonts/public/cmlocal or some such because
`extracm' might be associated with ..fonts/ams/extracm.
And I really would like to see them included by default, so that one
could write packages based on the assumption that they are present at
a well-equipped site. (Some of them can be quite useful as they fill
some holes of unavailable font shape combinations, e.g. cmssbxo10.)
Incidently, most of them come from the font specimens in Volume E,
but as they are not described in that volume, they aren't considered
standard somehow. :-(
[Re: doc/metafont]
> People should regard metafont as an equal part of the package, but
> they don't. I thought about this for some time, and decided
> that it would make the metafont stuff more recognizable to those
> who really have an interest if it is under doc/metafont/
That's fine, but I'd prefer doc/tex for the corresponding files,
leaving only those in doc/general which are neither tex nor mf,
but relevant to both. (see below)
[Re: glue.web]
> I guess it's a matter of whether it is more about glue or more about
> web, but I suspect you are right.
I can't really tell as haven't actually read it. But doc/plain/base
is certainly not the right place, doc/tex or doc/web would be better.
I'd also suggest including Knuth's ``Literate Programming'' paper
in doc/web.
> Anyway, many thanks for your immediate response. There is nothing
> like a concrete example to get these things decided intelligently.
Acutually, after you've posted your ideas I've been thinking of having
a try at reorganizing the stuff from Knuth's latest tex95.tar.gz into
the TDS tree (while preserving the original file dates!), but I haven't
found time to do so, yet. The difficult question is what to include
and what to leave out from his local directories.
Anyway, here's my (theoretical) approach for the doc tree:
doc/
help/
CTAN/ info about CTAN sites, catalog, macro index
FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
info/
components/ ...
lkurz/ ...
lshort/ ...
misc/ gentle.{tex,dvi}, ...
...
general/
errata/ errata.{tex,dvi}, errata[1-8].tex
errorlog/ errorlog.{tex,dvi},
tex82.bug, mf84.bug, cm85.bug,
manuals/ texbook.tex, story.tex,
mfbook.tex, mfman.nf, io.mf,
(links to ../../tex or ../../metafont)
triptrap/ tripman.{tex,dvi}, trip.tex,
trapman.{tex,dvi}, trap.mf,
(DVI files truncated after Appendix B!)
web/ webman.{tex,dvi}, cwebman.{tex,dvi},
web.{tex,dvi}, primes.web, glue.web (?),
tex/ texbook.tex, story.tex, letter.tex (?)
metafont/ mfbook.tex, mfman.mf, io.mf
metapost/ mpman.{dvi,ps}, manfig.mp,
mpgraph.{dvi,ps}, mpgraph.mp,
dvips/ separate directorys for each of them (?)
kpathsea/ .
fontname/ .
eplain/ .
ams/
amsfonts/ amsfonts.faq, amfndoc.{tex,dvi},
amstex/ amsguide.{tex,dvi}, joyerr.tex,
amslatex/ amslatex.faq, amsldoc.{tex,dvi},
diff12.{tex,dvi}, technote.{tex,dvi},
testmath.tex (?)
latex/
amslatex -> ../ams/amslatex
base/ ltnews*.{tex,dvi}, *guide.{tex,dvi},
manual.err, compan.err,
small2e.tex, sample2e.tex,
graphics/ grfguide.{tex,ps}
german/ -> ../generic/german
styles/ ...
fonts/
fontname -> ../fontname
amsfonts -> ../ams/amsfonts
oldgerm/ corkpapr.{tex,dvi}
...
generic/
german/ germdoc.{tex,dvi}
babel/ ...
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 09:36:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 15:36:35 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221536.AA11679@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69
> \section{\BibTeX}
> [ NORM: THE {\protect\BibTeX} LOGO IS BOMBING TEX IN A SECTION TITLE! ]
It wouldn't if you defined \smsize like this:
\def\smsize{%
\ifdim\f@size pt=24.88pt\fontsize{17.28}{20pt}\selectfont\else%
\ifdim\f@size\p@=17.28pt\fontsize{14.4}{16pt}\selectfont\else%
\ifdim\f@size\p@=14.4pt\fontsize{10.95}{12pt}\selectfont\else%
\ifdim\f@size\p@=10.95pt\fontsize{9}{10pt}\selectfont\else%
\ifdim\f@size\p@=10pt\fontsize{8}{9pt}\selectfont\else%
\ifdim\f@size\p@=9pt\fontsize{7}{8pt}\selectfont\else%
\ifdim\f@size\p@=8pt\fontsize{6}{7pt}\selectfont\else%
\typeout{smsize macro undefined for size \f@size!}\undefined%
\fi%
\fi%
\fi%
\fi%
\fi%
\fi%
\fi
}
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 10:02:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 16:02:57 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221602.AA11689@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (LaTeX 2.09)
The preamble that I sent Norm, as it appears at the top of
0.69 did actually run with LaTeX2.09 on the version of the document I
tested (0.66 or 0.68, I cant remember) However the new version, 0.69,
has lots more LaTex2e code in it, and it seems pointless trying to
keep it running under 2.09.
Actually I think we should do as suggested in tdstable.sty and wrap up
all the required TeX hackery (sorry I meant to say, implementation of
the specified typographic design:-) into a single tdsguide.cls class
file.
Actually when I first pulled over my the files, my eyes deceived me
and I read that as tds stable. Yipee I thought: it's all done! No more
changes...
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 10:09:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 1995 11:05:04 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503221605.LAA09212@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (LaTeX 2.09)
References: <9503221602.AA11689@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 16:02:57, David Carlisle wrote:
> The preamble that I sent Norm, as it appears at the top of
> 0.69 did actually run with LaTeX2.09 on the version of the document I
> tested (0.66 or 0.68, I cant remember) However the new version, 0.69,
> has lots more LaTex2e code in it, and it seems pointless trying to
> keep it running under 2.09.
I think we all agree on that point, I'll take out that goop at the
top of the file before the next revision.
> Actually I think we should do as suggested in tdstable.sty and wrap up
> all the required TeX hackery (sorry I meant to say, implementation of
> the specified typographic design:-) into a single tdsguide.cls class
> file.
Yes. Joachim has offered to clean up the macros and I suspect he'll
do something like that ;-)
> Actually when I first pulled over my the files, my eyes deceived me
> and I read that as tds stable. Yipee I thought: it's all done! No more
> changes...
You mean it's that easy!? It'll say "tds stable" next time fer sure then!
--norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 10:16:20 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503221615.RAA22279@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Announce: 0.69 (LaTeX 2.09)
To: TWG-TDS@SHSU.edu
Date: Wed, 22 Mar 1995 17:15:26 +0100 (MEZ)
Content-Type: text
David wrote:
>
> Actually I think we should do as suggested in tdstable.sty and wrap up
> all the required TeX hackery (sorry I meant to say, implementation of
> the specified typographic design:-) into a single tdsguide.cls class
> file.
I have already started to work on that. It will be LaTeX2e specific,
though.
Since I'm at it, Rich wrote in his comments on 0.69:
> The descriptive text for the figure is extending well past the
> margin. Part of this is due to the four-character indentation;
> much of the reaminder is due to multiple example names.
>
> I also think the vertical lines of dots assist the reader in
> tracking levels, particularly when shallow (e.g. two character)
> levels are used.
That's three different points:
-- Is the indentation too large (2 quad currently)?
-- Do others also like dots for alignment.
Both is easy to change, it's one macro. What do the others think, what
do you want?
The third point
-- the descriptive text extends in the margin
is more difficult. That this text is not broken, was an intentional
decision; I thought that two-liners there would destroy the figure. I
would like to hear more opinions on that: Shall I change the macros or
shall Norm rewrite the explanations?
Joachim
PS: I look in the error message `missing \item' later this evening.
The environment starts with `\trivlist \item\relax', I wonder where
the \everypar binding gets discarded.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 11:24:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 16:39:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221639.AA11728@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (LaTeX 2.09)
-- Is the indentation too large (2 quad currently)?
It looks about right to me, although could experiment with reducing it
a bit to help with the overflow into the margin.
-- Do others also like dots for alignment.
Not very much, certainly not for all the lines, could perhaps put in
leaders just for the top level entries
bibtex, bin doc etc,
that would visually split the table up into the main branches of the
tree. (I havent tried it though, may just look a mess)
-- the descriptive text extends in the margin
The whole tree is indented, even `texmf' is not flush left.
I think that could be fixed. If space were really tight you could move
it all slightly to the left, into the left margin?
PS: I look in the error message `missing \item' later this evening.
The environment starts with `\trivlist \item\relax', I wonder where
the \everypar binding gets discarded.
Strange it runs without error here.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 13:13:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 19:12:06 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221912.AA11868@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Is my understanding of the `8 levels' restriction corect that the
> Here is a typical \acronym{TDS} example, using only sevel levels:
^
^
n
example, is in fact the *maximum* that could be allowed in the TDS
tree, if the CDROM is to have a top level directory that looks like
install
installation scripts
info
Useful info about the nice people who published the CD
texmf
the tds tree, pushed down a level ??
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 13:34:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 11:33:40 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221933.AA06129@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Well, I can't speak for anyone else, but I don't think PTF would want
to remove a level from the TDS, just for administrative reasons. PTF
currently stashes all of its administrivia into a directory called
"a2z". This isn't too meaningful, however, and we probably can decide
on a better name for definition in the TDS. Here are some options:
admin files related to the administration of
this TDS tree
or
cdrom files related to this CD-ROM
or
cd_admin administrivia for this CD-ROM
cd_info information about this CD-ROM
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 13:52:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 1995 14:48:49 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503221948.OAA13420@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
References: <9503221933.AA06129@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 11:33:40, Rich Morin wrote:
> Well, I can't speak for anyone else, but I don't think PTF would want
> to remove a level from the TDS, just for administrative reasons. PTF
> currently stashes all of its administrivia into a directory called
> "a2z". This isn't too meaningful, however, and we probably can decide
> on a better name for definition in the TDS. Here are some options:
>
> admin files related to the administration of
> this TDS tree
> or
> cdrom files related to this CD-ROM
> or
> cd_admin administrivia for this CD-ROM
> cd_info information about this CD-ROM
>
Whoa, whoa, whoa! Back the directory truck up! (That's a Tim Allenism,
so those of you outside the USA may not find that very humerous. Heck,
maybe those of you inside the USA won't even find it funny.)
I don't want to put any cdrom info inside the TDS, it doesn't belong
there. Maybe I'm confused. From this example:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
I would have thought that I could have a CD-ROM like this:
/READ.ME;1
/TEXMF
/CDROM
.
.
.
and that I could "mount -t iso9660 -r /dev/scd0 /cdrom" and get:
/cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
Rich, is it the case that "texmf" in the first diagram is the *mount*
point?
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, 22 Mar 1995 15:03:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 13:03:47 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503222103.AA06437@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
NW sez (adapted slightly):
I don't want to put any cdrom info inside the TDS, it doesn't belong
there. Maybe I'm confused. From this example:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
I would have thought that I could have a CD-ROM like this:
/READ.ME;1
/TEXMF
/CD_ADMIN
...
and that I could "mount -t iso9660 -r /dev/scd0 /cdrom" and get:
/cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
You could, but it would be WRONG (:-).
Looking at the TDS drafts, I have been getting quite a different
understanding than you have. So, let's go back to basics...
On UNIX systems, the "name" of the top-level directory of a mountable
file system is always "/". This name gets overridden in the mounting
process. Similarly, in MS-DOS, the top-level directory gets the name
"<DEVICE>:". My reading of the TDS always led me to believe that the
<texmf> name was simply a placeholder, and that mounting the tree on
a UNIX or MS-DOS machine would yield something like:
/<mount point>/fonts/pk/public/cm/cx/dpi300/cmr10.pk
or
<mount point>:\FONTS\PK\PUBLIC\CM\CX\DPI300\CMR10.PK
Thus, I *have* been thinking of <texmf> as the mount point for a CD-ROM.
You have apparently been thinking of it as a subsidiary directory. If
we choose my interpretation, we end up with some clutter in the <texmf>
directory, such as a "cd_admin" directory. If we choose your version,
we lose a directory level from the TDS. I would vote for the former, as
I'm already nervous about the TDS needing room for more directory levels.
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 15:22:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 13:18:52 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503222118.AA06458@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
NW sez, approximately:
I don't want to put any cdrom info inside the TDS, it doesn't belong
there. Maybe I'm confused. From this example:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
I would have thought that I could have a CD-ROM like this:
/READ.ME;1
/TEXMF
/CD_ADMIN
...
and that I could "mount -t iso9660 -r /dev/scd0 /cdrom" and get:
/cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
No.
The mount point counts as the top level, so your example would be:
/cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7 8
It also appears that we have been talking a bit at cross-purposes.
It was my assumption that <texmf> was a placeholder name, and that
a CD-ROM would mount up as:
/<mount point>/fonts/pk/public/cm/cx/dpi300/cmr10.pk
or
<mount point>:\FONTS\PK\PUBLIC\CM\CX\DPI300\CMR10.PK
If we use my interpretation, we do get some junk in the top-level
directory of the TDS. This can be kept down to a single name,
such as cd_admin, but it is still there. If we use your view, we
limit the TDS to the levels we are currently using, with *no* room
for expansion. I think my view is less damaging, in the long run.
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 15:31:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 13:24:36 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503222124.AA06463@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Ooops!
I had almost completed editing one response to Norm when I hit the wrong
button on my mailtool. It wasn't the "Deliver" button, so I thought the
response had just gone away. So, I hacked up a new version. Then I got
the first version back from the TDS alias. SIGH. Looking at it, I think
the revised version is both clearer and more informative.
So, please ignore the message dated
Date: Wed, 22 Mar 95 13:03:47 PST
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 15:47:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 22 Mar 1995 13:48:38 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503222148.NAA04058@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
It is certainly my recollection that $TEXMF could stand for any
root directory *or file system* in our original discussions,
and that E:\FONTS\ . . . is an entirely legitimate TDS tree.
(assuming that \FONTS stands for all the first-level
directories that normally cluster in <texmf>/)
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 15:52:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 1995 16:47:47 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503222147.QAA17044@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
References: <9503222118.AA06458@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 13:18:52, Rich Morin wrote:
> and that I could "mount -t iso9660 -r /dev/scd0 /cdrom" and get:
>
> /cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
> 1 2 3 4 5 6 7
>
> No.
>
> The mount point counts as the top level, so your example would be:
>
> /cdrom/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
> 1 2 3 4 5 6 7 8
How can that be? If I chose to mount it on /usr/local, wouldn't I
get
/usr/local/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7 8 9
And wouldn't that be legal?
> It also appears that we have been talking a bit at cross-purposes.
> It was my assumption that <texmf> was a placeholder name, and that
> a CD-ROM would mount up as:
>
> /<mount point>/fonts/pk/public/cm/cx/dpi300/cmr10.pk
> or
> <mount point>:\FONTS\PK\PUBLIC\CM\CX\DPI300\CMR10.PK
>
> If we use my interpretation, we do get some junk in the top-level
> directory of the TDS. This can be kept down to a single name,
> such as cd_admin, but it is still there. If we use your view, we
> limit the TDS to the levels we are currently using, with *no* room
> for expansion. I think my view is less damaging, in the long run.
To a large extent, this is a non-issue. The TDS can't tell anyone
that they can't put other stuff in the top level. Personally, I
probably would have expected "/texmf/ora_cd" or "texmf/ptf_cd", or
something like that, but "texmf/cd_admin" is fine.
The two methods arrive at the same thing if I select an alternate
mount point:
mount /richcd /usr/local/texmf
or
mount /normcd /usr/local
For DOS, I would have expected the mount point to look like
T:\TEXMF\FONTS, but if it's just T:\FONTS, I'm not going to be
too upset.
What interpretation did everyone else have?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 16:51:04 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503222251.XAA36421@spelunke.iti.informatik.th-darmstadt.de>
Subject: Re: Announce: 0.69 (8 levels, again)
To: TWG-TDS@SHSU.edu
Date: Wed, 22 Mar 1995 23:51:09 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> For DOS, I would have expected the mount point to look like
> T:\TEXMF\FONTS, but if it's just T:\FONTS, I'm not going to be
> too upset.
>
> What interpretation did everyone else have?
My interpretation:
1) The TDS placeholder $TEXMF (i.e., the root directory) may be the
top of some (logical) tree, e.g., T: on DOS or TEX$TEXMF: on VMS.
2) If it's not at the top of something, i.e., if our root name has
directories in front of <texmf>, then it's recommended to name
<texmf> `texmf', to have a name one can search for in a file
system.
Actually, I would consider rule (2) the `real' rule, and (1) the
exception. I.e., I would prefer to fix the name `texmf' and make an
exception for those installations where this name would be the only
(superfluous) directory in a whole tree.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 17:36:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 15:36:21 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503222336.AA06873@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Norm sez:
How can that be? If I chose to mount it on /usr/local, wouldn't I get
/usr/local/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7 8 9
And wouldn't that be legal?
Well, you *may* be getting confused by terminology. If you were to mount
a disc ON /usr/local, all of the existing files in /usr/local would be
hidden from view until you unmounted it. I don't think this is what you
would want, so let's talk about mounting on, say, /usr/local/texmf.
This would be legal, but you would have only seven levels on the CD-ROM:
/usr/local/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
1 2 3 4 5 6 7
As I understand it, the restriction can be thought of as meaning:
"there are only eight levels in which you can place things
on an ISO-9660 CD-ROM".
The top-level (mount point) counts as one, because you can put things into
it. Files aren't counted, as they are "things", but not "levels". So,
in your example, dpi300 is the lowest of seven levels on the disc. OK?
To a large extent, this is a non-issue. The TDS can't tell anyone
that they can't put other stuff in the top level. Personally, I
probably would have expected "/texmf/ora_cd" or "texmf/ptf_cd", or
something like that, but "texmf/cd_admin" is fine.
My only concern is that the CDs not step on some name needed by other
parts of the TDS, and there is quite a bit of name space left (:-).
The two methods arrive at the same thing if I select an alternate
mount point:
mount /richcd /usr/local/texmf
or
mount /normcd /usr/local
I'm not sure I understand this, but I think (from the discussion
above) that it is wrong. If something gets mounted on /usr/local,
any other use of /usr/local is hosed.
For DOS, I would have expected the mount point to look like
T:\TEXMF\FONTS, but if it's just T:\FONTS, I'm not going to be
too upset.
What interpretation did everyone else have?
I'd be interested in this, too!
-r
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Mar 1995 18:53:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Mar 95 18:10:24 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503221710.AA16091@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (LaTeX 2.09)
Joachim wrote:
> I have already started to work on that. It will be LaTeX2e specific,
> though.
While you're at it: This morning I couldn't resist some hacking and
tried to fix the problem with the BibTeX logo, which was actually a
problem with the \smsize macro. (I've send the fixes to Norm directly,
but I'll append them below again.)
> That's three different points:
>
> -- Is the indentation too large (2 quad currently)?
> -- Do others also like dots for alignment.
I'd suggest to try 1 quad instead of 2 quad. I'm not sure about dots
for alignment, though.
> The third point
>
> -- the descriptive text extends in the margin
>
> is more difficult. That this text is not broken, was an intentional
> decision; I thought that two-liners there would destroy the figure.
I'd suggest to use \small or \footnotesize for the figure, which would
a) allow to have more descriptive text on the same line without
exceeding the margins,
b) allow to fit the figure on a page of its own, provided that
it is turned into a float.
> PS: I look in the error message `missing \item' later this evening.
> The environment starts with `\trivlist \item\relax', I wonder where
> the \everypar binding gets discarded.
I didn't get such an error message when I tried to it this morning.
And I'm pretty sure that I have a standard LaTeX 2e, December release,
Patch Level 1.
Cheers, Ulrik.
P.S. I've checked that it still works without errors when removing
the \protect before \MF (the original definition in tdsguide.sty) and
\BibTeX. However, it would be a good idea to put some robustification
into the package level to avoid unpleasant surprises in the future.
*** tds-0.69-950321/tdsguide.sty Wed Mar 22 09:40:12 1995
--- tds-0.69-hacked/tdsguide.sty Wed Mar 22 14:12:58 1995
***************
*** 1,20 ****
\newenvironment{programlisting}{\bgroup\verbatim}{\endverbatim\egroup}
\def\smsize{%
! \ifdim\f@size pt=24.88pt\fontsize{18}{20pt}\selectfont\else%
! \ifnum\f@size=18\fontsize{14}{16pt}\selectfont\else%
! \ifnum\f@size=14\fontsize{11}{12pt}\selectfont\else%
! \ifnum\f@size=11\fontsize{9}{10pt}\selectfont\else%
! \ifnum\f@size=10\fontsize{8}{9pt}\selectfont\else%
! \ifnum\f@size=9\fontsize{7}{8pt}\selectfont\else%
! \ifnum\f@size=8\fontsize{6}{7pt}\selectfont\else%
! \typeout{smsize macro undefined for size \f@size!}\undefined%
! \fi%
! \fi%
! \fi%
! \fi%
! \fi%
! \fi%
\fi
}
--- 1,22 ----
\newenvironment{programlisting}{\bgroup\verbatim}{\endverbatim\egroup}
\def\smsize{%
! \ifdim\f@size pt=24.88pt \fontsize{18}{20pt}\selectfont\else
! \ifdim\f@size pt=17.28pt \fontsize{14}{16pt}\selectfont\else
! \ifdim\f@size pt=14.4pt \fontsize{11}{14pt}\selectfont\else
! \ifdim\f@size pt=12pt \fontsize{10}{12pt}\selectfont\else
! \ifdim\f@size pt=11pt \fontsize{9}{10pt}\selectfont\else
! \ifdim\f@size pt=10pt \fontsize{8}{9pt}\selectfont\else
! \ifdim\f@size pt=9pt \fontsize{7}{8pt}\selectfont\else
! \ifdim\f@size pt=8pt \fontsize{6}{7pt}\selectfont\else
! \typeout{smsize macro undefined for size \f@size!}\relax
! \fi
! \fi
! \fi
! \fi
! \fi
! \fi
! \fi
\fi
}
***************
*** 23,29 ****
\def\systemitem#1#2{\texttt{#2}}
\def\emphasis#1{\emph{#1}}
! \def\replaceable#1{{\fontfamily{cmtt}\fontshape{sl}\selectfont #1}}
\def\dir#1{\texttt{#1}}
\def\ext#1{\texttt{#1}}
\def\command#1{\textit{#1}}
--- 25,31 ----
\def\systemitem#1#2{\texttt{#2}}
\def\emphasis#1{\emph{#1}}
! \def\replaceable#1{\texttt{\textsl{#1}}}
\def\dir#1{\texttt{#1}}
\def\ext#1{\texttt{#1}}
\def\command#1{\textit{#1}}
***************
================================================================================
From owner-twg-tds@shsu.edu Thu, 23 Mar 1995 02:41:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 23 Mar 95 09:35:22 +0100
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503230835.AA16463@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: comments on 0.69
Here comes the next round of nit-picking...
* \subsection{Top Level Directories}
\item[\path|metafont|]
for (non-font) input files used by {\protect\MF}
(see \xref{Section 5, Non-font {\protect\MF} files}).
I think it would look nicer if this item could be reworded/shortened
to fit on a single line. All the other items here either fit on a line
or else occupy a full paragraph. A two-line item looks a little odd
in this context. (But that's just a cosmetic issue!)
\item[\path|bibtex|]
for files used by {\protect\BibTeX} (see \xref{Section 7, BibTeX}).
Use the \BibTeX logo in the section reference (or is this generated
automagically depending on whether you use it in the section title?)
Implementations can store configuration files, compiled {\TeX}
format files, pool files, {\protect\MF} bases, {\MP} mems,
\acronym{DLL}s, etc. in
their own directory. Utilities can store configuration files,
input files, etc. in their own directory.
What about putting ``pool files'' either before ``TeX formats'' or after
``MP mems''? (All three of TeX, Metafont, and MetaPost use pool files.)
* \section{Macros}
Although some of these formats can also
be used as macro packages; the \acronym{TDS} nevertheless stores
them as formats.
Why is there a semicolon here instead of a comma? Maybe I don't
understand those English punctuation rules either?
\item
The \replaceable{format} directory \path|hyphen| is reserved for
hyphenation patterns. Thes are used only by {\iniTeX} when a
^^^^^
format file is being built.
These are used ... (typo)
^^^^^
The \path|plain| directory is intended for files which are
useful with the Plain {\TeX} format and others compatible with Plain:
\path|fontchart.tex|, \path|testfont.tex|,
\path|manmac.tex|, \path|webmac.tex|, etc.,
Has anyone noticed that |fontchart.tex| is too long to fit into 8.3?
Should it be mentioned somewhere how best to handle long file names?
(emTeX and PubliC TeX presently use 5+3.3 to truncate them, AFAIK.)
* \section{Fonts}
\item[\replaceable{supplier}]
is the name of the font supplier or \path|public|.
\path|public|, \path|adobe|, \path|monotype|, and \path|ams|,
are examples of \replaceable{supplier}.
I find these sentences a little confusing. If ``supplier'' is either
a font supplier or ``public'', how can ``public'' be an example then?
It's a special case, not a typical example. I suggest taking out
\path|public| at the beginning of the second sentence.
The \path|latex|
typeface directory contains only the fonts distributed with
{\LaTeX} in the \emphasis{base} distribution.
Why is it \emphasis{base} here? The phrase ...base distribution...
appears elsewhere without emphasis or as ...``base'' documentation...
I suggest trying to make this consistent. If there is anything to
emphasize in this sentence, I'd say ...\empahsis{only} the fonts...
* \subsection{Font Bitmaps}
fonts with different device types (modes) are generally segregated
^^^^^
into separate directories.
Fonts with different ... (Uppercase. This starts a new paragraph.)
^^^^^
A complete set of {\protect\MF} modes is available from
CTAN:\path|fonts/modes/modes.mf|.
I think the CTAN reference belongs into the Appendix. In any case
this seems to be the only pseudo-URL-style reference in the draft and
it tends to look slightly ugly in this context. The following section
contains the phrase ...the complete modes.mf distribution from CTAN...
which sounds much better, IMHO.
If \path|GF| files are also to be kept, they would fall in:
$\ldots$\path|/gf/|\replaceable{supplier}...
I think this should start with \path|texmf/fonts/| instead of \ldots
(cf. \path|texmf/fonts/pk/|\replaceable{supplier}... in this section).
* \section{Non-font {\protect\MF} files}
\item
\path|misc| is reserved for {\protect\MF} packages consisting
of only a single file or a small number of files. One such
example is \path|modes.mf|.
Take out ...or a small number of files... (Already done in the MetaPost
section. Introducing this was my fault, I'm afraid. Sorry for that!)
BTW, there is no longer any mention of INIMF or base files in this
section anymore. Does anyone else think there should be?
What about rewording the introductory sentence. Something like:
! Most MF input files are fonts, however a few non-font input
! files do exist (...). Most notably this includes files used
! by INIMF when a base file is being built.
* \section{Documentation}
The \acronym{TDS} specifies:
This sounds a little rough like an incomplete sentence. I'd really
prefer to read complete sentences. Somethink like:
! The TDS specifies that documentation files shall be organized
! as follows:
BTW, it would be a good idea to check the usage of ``shall'' vs. ``should''
in all files. Someone else suggested to use ``shall'' because it is
more common in ``standard speek''.
Within the category tree, the directory
\path|base| is reserved for ``base'' documentation distributed
by the format's authors.
See above concerning the use of \emphasis{base} vs. base vs. ``base''.
\item[\path|html|]
for processed \acronym{HTML} documents.
What about \path|HTML| instead of \acronym here? (It's used both as
a file type as well as a markup language, so we two possibilities.)
* \section{Summary}
As noted elsewhere: Even if the indentation of the description text is
irrelevant for the LaTeX version it still matters for the HTML version.
Also use the proper logos and possibly use \path|...| for the examples.
\begin{tdsSummary}
<texmf>/ top-level directory for \acronym{TDS} tree
<<
. bibtex/ BibTeX input files
^^^^^^ {\BibTeX}
. . bib/ databases of common interest
. . bst/ style files
. bin/*/ binaries, by system type (optionally)
. doc/ user documentation
. . <format>/ name of a format (e.g., plain, eplain, amstex, latex)
<< ^^^^^ \path|plain|, etc. (?)
. . . base/ documentation of base distribution for format
. . . misc/ documentation of single-file packages
. . . <package>/ documentation of packages (e.g., graphics, amslatex)
. . html/ hypertext docs (produced by, e.g., texi2html or latex2html)
. . info/ processed Texinfo documents (processed by, e.g., makeinfo)
. . man/ Unix-style manual pages
. . general/ standalone documents
. . help/ meta-information (FAQs, etc.)
. . <program>/ TeX applications, by name (e.g., makeindx)
<<^^^ {\TeX} ^, dvips
. fonts/ font-related files
. . <type>/ file type (e.g., pk, vf, source, type1)
. . . <supplier>/ name of a font supplier (e.g., adobe, ams, public)
. . . . <typeface>/ name of a typeface (e.g., cm, euler, latex, times)
. . . . . <mode>/ type of output device (for pk and gf only)
. . . . . . <dpi>/ font resolution (for pk and gf only)
. metafont/ {\protect\MF} (non-font) input files
. . base/ base distribution
. . misc/ single-file packages
. . <package>/ name of a package (e.g., mfpic)
<<
. metapost/ {\MP} input and support files
. . base/ base distribution
. . misc/ single-file packages
. . <package>/ name of a package (for future use)
<<
. . support/ support files for METAPOST-related utiltities
^^^^^^^^ {\MP}
. <program>/ TeX applications, by name (e.g., makeindx, dvips)
<<^^^ {\TeX}
. source/ program source code
. tex/ TeX input files
^^^ {\TeX}
. . <format>/ name of a format (e.g., plain, eplain, amstex, latex)
<<
. . . base/ base distribution for format
. . . config/ configuration files for format
. . . misc/ single-file packages
. . . <package>/ name of a package (e.g., graphics, amslatex)
<<
. . generic/ format-independent packages
. . . misc/ single-file format-independent packages
. . . <package>/ name of a package (e.g., babel, german)
<<
. . hyphen/ hyphenation patterns
\end{tdsSummary}
* \section{References to Files \& Documents}
I'd say: ``Files and Documents'' instead of ``Files \& Documents''.
\citetitle{A User's Manual for MetaPost} and
\citetitle{Drawing Graphs with MetaPost}
are available as \acronym{CSTR} 162 and 164
from \path|ftp.netlib.att.com|. They are also included
as \path|mpman.ps| and \path|mpgraph.ps| in the {\MP}
distribution.
These are no longer cited in the current version, but there's probably
no harm in leaving them in (as if they were no-cited).
\citetitle{Filenames for {\TeX} fonts} can be found in the CTAN
archives in the \path|info/fontname| directory.
There's probably a lot more to add here:
- ``The TeXbook'' and ``The METAFONTbook''
- Michael Doob's ``Gentle Introduction''
- Joachim Schrod's ``Components of TeX''
- David Jones's macro index (How old is this?)
- modes.mf
- other files (Which ones? Where do we stop?)
So much for today's round of nit-picking. I hope we are making progress.
BTW, I like the new Appendix A and I didn't find anything to critizise
in that section. (Well, except that the email address should be given
in typewriter type.)
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Thu, 23 Mar 1995 05:59:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 23 Mar 95 11:59:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503231159.AA12598@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Hmm
so I gather that the answer to my question
Is my understanding of the `8 levels' restriction correct that the
... example, is in fact the *maximum* that could be allowed in the
TDS tree, if the CDROM ...
is Yes.
So the other question (which I purposefully did not ask last time) is
should a TDS CD look like that? (Or equivalently is it possible to
make an ISO-9660 CD that contains a TDS tree *in addition* to other
stuff (eg other useful text related widgits like an editor, or
ghostscript or ... ? )
If we want to claim all 8 levels for the TDS to cope with any future
file format that requires 8 levels, then it appears that we are saying
that putting a TDS tree on CD takes the entire directory structure of
the CD. I am not saying whether this is good or bad (I have no real
feeling for that, I'll let those of you contemplating making such a
thing decide) but perhaps the document should say something explicit
about this. It is clear that despite having the best part of a side of
the document devoted to this, there is still room for mis-interpretation
of the interaction between the TDS spec and CDroms.
Perhaps in the section `rooting the tree', one could say something along
the lines of.
For example, on a TDS cdrom, the top level directory on the CD would
correspond to the directory denoted as texmf in this document. If it
is mounted on /usr/local/texmf under unix, then the above file would
appear to the user as
/usr/local/texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
If the same CD were accessed from an MSDOS machine, with CDROM on
drive D:, the file would appear as
D:\FONTS\PK\PUBLIC\CM\CX\DPI300\CMR10.PK
David
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 09:56:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 10:52:42 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251552.KAA14932@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.69 notes
References: <9503220102.AA02851@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 21 March 1995 at 17:02:04, Rich Morin wrote:
> 1. page 5
>
> ... not including any directory or extension part,
> ... not including any directory path or extension,
check
>
> 2. page 6
>
> ... only sevel levels.
> ... only seven levels.
check
--norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 09:59:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 10:55:53 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251555.KAA14961@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
References: <9503221020.AA15440@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 11:20:05, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> [Re: Knuth's local/cm]
> > Any harm in putting such font sources in texmf/fonts/public/extracm ?
>
> Personally, I'd prefer ..fonts/public/cmlocal or some such because
> `extracm' might be associated with ..fonts/ams/extracm.
>
> And I really would like to see them included by default, so that one
> could write packages based on the assumption that they are present at
> a well-equipped site. (Some of them can be quite useful as they fill
> some holes of unavailable font shape combinations, e.g. cmssbxo10.)
> Incidently, most of them come from the font specimens in Volume E,
> but as they are not described in that volume, they aren't considered
> standard somehow. :-(
I'd be inclined to go with .../morecm or something like that.
"cmlocal" sounds like a local hack.
> doc/
> help/
> CTAN/ info about CTAN sites, catalog, macro index
> FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
> newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
>
> info/
> components/ ...
> lkurz/ ...
> lshort/ ...
> misc/ gentle.{tex,dvi}, ...
> ...
>
> general/
> errata/ errata.{tex,dvi}, errata[1-8].tex
> errorlog/ errorlog.{tex,dvi},
> tex82.bug, mf84.bug, cm85.bug,
> manuals/ texbook.tex, story.tex,
> mfbook.tex, mfman.nf, io.mf,
> (links to ../../tex or ../../metafont)
> triptrap/ tripman.{tex,dvi}, trip.tex,
> trapman.{tex,dvi}, trap.mf,
> (DVI files truncated after Appendix B!)
>
> web/ webman.{tex,dvi}, cwebman.{tex,dvi},
> web.{tex,dvi}, primes.web, glue.web (?),
>
> tex/ texbook.tex, story.tex, letter.tex (?)
>
> metafont/ mfbook.tex, mfman.mf, io.mf
>
> metapost/ mpman.{dvi,ps}, manfig.mp,
> mpgraph.{dvi,ps}, mpgraph.mp,
>
> dvips/ separate directorys for each of them (?)
> kpathsea/ .
> fontname/ .
> eplain/ .
>
> ams/
> amsfonts/ amsfonts.faq, amfndoc.{tex,dvi},
> amstex/ amsguide.{tex,dvi}, joyerr.tex,
> amslatex/ amslatex.faq, amsldoc.{tex,dvi},
> diff12.{tex,dvi}, technote.{tex,dvi},
> testmath.tex (?)
>
> latex/
> amslatex -> ../ams/amslatex
> base/ ltnews*.{tex,dvi}, *guide.{tex,dvi},
> manual.err, compan.err,
> small2e.tex, sample2e.tex,
> graphics/ grfguide.{tex,ps}
> german/ -> ../generic/german
> styles/ ...
>
> fonts/
> fontname -> ../fontname
> amsfonts -> ../ams/amsfonts
> oldgerm/ corkpapr.{tex,dvi}
> ...
>
> generic/
> german/ germdoc.{tex,dvi}
> babel/ ...
How does this look to everyone?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 10:10:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:06:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251606.LAA15053@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69
References: <9503221536.AA11679@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 15:36:35, David Carlisle wrote:
>
> > \section{\BibTeX}
> > [ NORM: THE {\protect\BibTeX} LOGO IS BOMBING TEX IN A SECTION TITLE! ]
>
> It wouldn't if you defined \smsize like this:
>
Ok. And doesn't this indicate that LaTeX needs a \textsizedelta{2pt}?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 10:21:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:13:03 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251613.LAA15085@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
References: <9503222336.AA06873@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 15:36:21, Rich Morin wrote:
> Well, you *may* be getting confused by terminology. If you were to mount
> a disc ON /usr/local, all of the existing files in /usr/local would be
> hidden from view until you unmounted it. I don't think this is what you
> would want, so let's talk about mounting on, say, /usr/local/texmf.
Yeah, I don't know what I was thinking.
> My only concern is that the CDs not step on some name needed by other
> parts of the TDS, and there is quite a bit of name space left (:-).
>
> The two methods arrive at the same thing if I select an alternate
> mount point:
>
> mount /richcd /usr/local/texmf
>
> or
>
> mount /normcd /usr/local
>
> I'm not sure I understand this, but I think (from the discussion
> above) that it is wrong. If something gets mounted on /usr/local,
> any other use of /usr/local is hosed.
It's wrong.
It looks like CD's should have /FONTS and /TEX, etc. in the root
directory.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 10:31:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:27:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251627.LAA15161@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: comments on 0.69
References: <9503230835.AA16463@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
On 23 March 1995 at 09:35:22, vieth@xerxes.thphy.uni-duesseldorf.de wrote:
> Here comes the next round of nit-picking...
>
> * \subsection{Top Level Directories}
>
> \item[\path|metafont|]
> for (non-font) input files used by {\protect\MF}
> (see \xref{Section 5, Non-font {\protect\MF} files}).
>
> I think it would look nicer if this item could be reworded/shortened
> to fit on a single line. All the other items here either fit on a line
> or else occupy a full paragraph. A two-line item looks a little odd
> in this context. (But that's just a cosmetic issue!)
Ok, I tried.
> \item[\path|bibtex|]
> for files used by {\protect\BibTeX} (see \xref{Section 7, BibTeX}).
>
> Use the \BibTeX logo in the section reference (or is this generated
> automagically depending on whether you use it in the section title?)
Automatically.
> Implementations can store configuration files, compiled {\TeX}
> format files, pool files, {\protect\MF} bases, {\MP} mems,
> \acronym{DLL}s, etc. in
> their own directory. Utilities can store configuration files,
> input files, etc. in their own directory.
>
> What about putting ``pool files'' either before ``TeX formats'' or after
> ``MP mems''? (All three of TeX, Metafont, and MetaPost use pool files.)
Ok.
> * \section{Macros}
>
> Although some of these formats can also
> be used as macro packages; the \acronym{TDS} nevertheless stores
> them as formats.
>
> Why is there a semicolon here instead of a comma? Maybe I don't
> understand those English punctuation rules either?
A comma works for me. But I was educated in American schools, maybe
I don't understand English punctuation either ;-)
>
> These are used ... (typo)
> ^^^^^
Chec.
> The \path|plain| directory is intended for files which are
> useful with the Plain {\TeX} format and others compatible with Plain:
> \path|fontchart.tex|, \path|testfont.tex|,
> \path|manmac.tex|, \path|webmac.tex|, etc.,
>
> Has anyone noticed that |fontchart.tex| is too long to fit into 8.3?
Bye, bye.
> Should it be mentioned somewhere how best to handle long file names?
> (emTeX and PubliC TeX presently use 5+3.3 to truncate them, AFAIK.)
No, I don't think so. Too implementation dependent.
> * \section{Fonts}
>
> \item[\replaceable{supplier}]
> is the name of the font supplier or \path|public|.
> \path|public|, \path|adobe|, \path|monotype|, and \path|ams|,
> are examples of \replaceable{supplier}.
>
> I find these sentences a little confusing. If ``supplier'' is either
> a font supplier or ``public'', how can ``public'' be an example then?
> It's a special case, not a typical example. I suggest taking out
> \path|public| at the beginning of the second sentence.
Check.
> The \path|latex|
> typeface directory contains only the fonts distributed with
> {\LaTeX} in the \emphasis{base} distribution.
>
> Why is it \emphasis{base} here? The phrase ...base distribution...
> appears elsewhere without emphasis or as ...``base'' documentation...
> I suggest trying to make this consistent. If there is anything to
> emphasize in this sentence, I'd say ...\empahsis{only} the fonts...
I took out the emphasis.
> * \subsection{Font Bitmaps}
>
> fonts with different device types (modes) are generally segregated
> ^^^^^
> into separate directories.
>
> Fonts with different ... (Uppercase. This starts a new paragraph.)
> ^^^^^
Check.
> A complete set of {\protect\MF} modes is available from
> CTAN:\path|fonts/modes/modes.mf|.
>
> I think the CTAN reference belongs into the Appendix.
Yep.
> If \path|GF| files are also to be kept, they would fall in:
>
> $\ldots$\path|/gf/|\replaceable{supplier}...
>
> I think this should start with \path|texmf/fonts/| instead of \ldots
> (cf. \path|texmf/fonts/pk/|\replaceable{supplier}... in this section).
Check.
> * \section{Non-font {\protect\MF} files}
>
> \item
> \path|misc| is reserved for {\protect\MF} packages consisting
> of only a single file or a small number of files. One such
> example is \path|modes.mf|.
>
> Take out ...or a small number of files... (Already done in the MetaPost
> section. Introducing this was my fault, I'm afraid. Sorry for that!)
Check.
> BTW, there is no longer any mention of INIMF or base files in this
> section anymore. Does anyone else think there should be?
I put it back, a l\'a metapost
> What about rewording the introductory sentence. Something like:
>
> ! Most MF input files are fonts, however a few non-font input
> ! files do exist (...). Most notably this includes files used
> ! by INIMF when a base file is being built.
Ok.
> * \section{Documentation}
>
> The \acronym{TDS} specifies:
>
> This sounds a little rough like an incomplete sentence. I'd really
> prefer to read complete sentences. Somethink like:
>
> ! The TDS specifies that documentation files shall be organized
> ! as follows:
Ok.
> BTW, it would be a good idea to check the usage of ``shall'' vs. ``should''
> in all files. Someone else suggested to use ``shall'' because it is
> more common in ``standard speek''.
Yes.
> Within the category tree, the directory
> \path|base| is reserved for ``base'' documentation distributed
> by the format's authors.
>
> See above concerning the use of \emphasis{base} vs. base vs. ``base''.
Check.
> \item[\path|html|]
> for processed \acronym{HTML} documents.
>
> What about \path|HTML| instead of \acronym here? (It's used both as
> a file type as well as a markup language, so we two possibilities.)
I dunno. I think it's the name of a markup language in the second
context.
> * \section{Summary}
>
> As noted elsewhere: Even if the indentation of the description text is
> irrelevant for the LaTeX version it still matters for the HTML version.
>
> Also use the proper logos and possibly use \path|...| for the examples.
Yep, yep.
> * \section{References to Files \& Documents}
>
> I'd say: ``Files and Documents'' instead of ``Files \& Documents''.
Check.
> \citetitle{Filenames for {\TeX} fonts} can be found in the CTAN
> archives in the \path|info/fontname| directory.
>
> There's probably a lot more to add here:
There sure are.
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 Sat, 25 Mar 1995 10:32:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:29:04 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251629.LAA15191@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
References: <9503231159.AA12598@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 23 March 1995 at 11:59:49, David Carlisle wrote:
> So the other question (which I purposefully did not ask last time) is
> should a TDS CD look like that? (Or equivalently is it possible to
> make an ISO-9660 CD that contains a TDS tree *in addition* to other
> stuff (eg other useful text related widgits like an editor, or
> ghostscript or ... ? )
Apparently not.
> If we want to claim all 8 levels for the TDS to cope with any future
> file format that requires 8 levels, then it appears that we are saying
> that putting a TDS tree on CD takes the entire directory structure of
> the CD. I am not saying whether this is good or bad (I have no real
> feeling for that, I'll let those of you contemplating making such a
> thing decide) but perhaps the document should say something explicit
> about this. It is clear that despite having the best part of a side of
> the document devoted to this, there is still room for mis-interpretation
> of the interaction between the TDS spec and CDroms.
Well, my feeling is that until we use all 8 levels, it's up to the blokes
that put together the CDs. I'm afraid that if we add too much CD-specific
stuff, it'll start to dilute the focus of the TDS. Maybe Joachim was
right and it belongs in an appendix...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 10:34:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:30:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251630.LAA15213@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Re: removal from twg-tds
References: <0098DD43.8C39AA44.43@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
On 24 March 1995 at 07:44:24, George D. Greenwade wrote:
> remove <te@INFORMATIK.UNI-HANNOVER.DE>
> quit
>
> Norm:
>
> cc'ing you on this (you possibly got the bounce as well) -- it appears that
> the site in question has something which creates indigestion in mail
> delivery:
> > Return-Path: <Mailer-Daemon@informatik.uni-hannover.de>
> >....
> > Date: Thu, 23 Mar 1995 02:49:27 +0100
> > From: Mailer-Daemon@informatik.uni-hannover.de (Mail Delivery Subsystem)
> > Subject: Returned mail: unknown mailer error 5
> > Message-ID: <9503230149.AH00178@wega.informatik.uni-hannover.de>
> > To: owner-twg-tds@SHSU.edu
> >
> > ----- Transcript of session follows -----
> > mail: Options MUST PRECEDE persons
> > 554 <te@informatik.uni-hannover.de>... unknown mailer error 5
>
> No clue how we can fix it on this end, so I zapped this subscriber.
Thanks for CC'ing me, George. I didn't see the bounce messages.
Does anyone else know how to reach Thomas Esser?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 10:57:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 11:07:23 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503251607.LAA15059@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (LaTeX 2.09)
References: <199503221615.RAA22279@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 22 March 1995 at 17:15:26, Joachim Schrod wrote:
> -- the descriptive text extends in the margin
>
> is more difficult. That this text is not broken, was an intentional
> decision; I thought that two-liners there would destroy the figure. I
> would like to hear more opinions on that: Shall I change the macros or
> shall Norm rewrite the explanations?
I'll rewrite.
> PS: I look in the error message `missing \item' later this evening.
> The environment starts with `\trivlist \item\relax', I wonder where
> the \everypar binding gets discarded.
David said he didn't have the problem. I'll try again....
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Join the club of the Redundancy Club.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 15:07:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 16:07:54 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503252107.AA17532@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
doc/
help/
CTAN/ info about CTAN sites, catalog, macro index
FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
I don't see the point of putting things together just because they
happen to be posted as ``FAQ''s.
newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
What are these? Why are there both old new versions? Sigh.
info/
components/ ...
lkurz/ ...
lshort/ ...
misc/ gentle.{tex,dvi}, ...
This isn't right. info/ is for stuff generated by makeinfo.
This stuff goes in general, I think.
manuals/ texbook.tex, story.tex,
mfbook.tex, mfman.nf, io.mf,
story.tex and io.mf should be in the input trees (i.e., under texmf/tex
and texmf/metafont), not the doc tree. (Or in both, though I don't
really see that they're documentation ...)
================================================================================
From owner-twg-tds@shsu.edu Sat, 25 Mar 1995 16:38:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 1995 17:32:22 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503252232.RAA19871@jasper.ora.com>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: twg-tds@shsu.edu
Subject: Mea culpa
Reply-To: TWG-TDS@SHSU.edu
Joachim,
Ignore my comment about "missing item" in tdsSummary. I was running
LaTeX from 6/94pl3 not the one from 12/94. I upgraded and all is well.
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
================================================================================
From owner-twg-tds@shsu.edu Sun, 26 Mar 1995 13:02:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 25 Mar 95 23:51:50 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503260751.AA21733@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Norm sez:
Well, my feeling is that until we use all 8 levels, it's up to the blokes
that put together the CDs. I'm afraid that if we add too much CD-specific
stuff, it'll start to dilute the focus of the TDS. Maybe Joachim was
right and it belongs in an appendix...
I don't care much where the information is located, although I happen to
feel it's about right as it is. I *do* think that the restriction needs
to be covered in the TDS (and checked, ultimately, by the TDS Registry
process) so that we don't get packages that can't be put on ISO-9660 discs.
-r
================================================================================
From owner-twg-tds@shsu.edu Sun, 26 Mar 1995 14:10:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503262010.WAA18980@spock.iti.informatik.th-darmstadt.de>
Subject: Re: doc files again.
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sun, 26 Mar 1995 22:10:35 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
> newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
>
> What are these? Why are there both old new versions? Sigh.
The old c.t.t FAQ (actually, the one that still gets posted) should be
dumped from all distributions. It's way out of date, more than 50% of
its information is not valid any more.
Robin Fairbarnes and a bunch of volunteers looked over the FAQ and
produced a new one, for publication in UK-TUG's Baskerville. AFAIK, he
doesn't plan to support if further.
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, 27 Mar 1995 01:46:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 09:47:25 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503270747.AA01061@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Karl wrote:
> doc/
> help/
> FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
>
> I don't see the point of putting things together just because they
> happen to be posted as ``FAQ''s.
Well, maybe one could do with separate directories, or maybe another
level under doc/help/FAQ? The old comp.text.tex FAQs are mostly
outdated anyway and comp.fonts has so many files that it deserves
its own directory indeed.
> newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
>
> What are these? Why are there both old new versions? Sigh.
I think Joachim has already answered this. One could probably ditch
the old versions in favour of this anyway. (BTW, Karl, aren't you
mentioned as a contributer in there as well?)
> info/
> components/ ...
> lkurz/ ...
> lshort/ ...
> misc/ gentle.{tex,dvi}, ...
> This isn't right. info/ is for stuff generated by makeinfo.
> This stuff goes in general, I think.
Yeah, right. I was confused by the similarly organized help/ and info/
directories on CTAN, but sure, they belong in doc/general here.
> manuals/ texbook.tex, story.tex,
> mfbook.tex, mfman.nf, io.mf,
> story.tex and io.mf should be in the input trees (i.e., under texmf/tex
> and texmf/metafont), not the doc tree. (Or in both, though I don't
> really see that they're documentation ...)
It was indeed my intention to put them in both places using symbolic
links where possible. One might well consider these as documentation
accompanying texbook.tex and mfbook.tex. (BTW, expr.mf probably belongs
here as well.)
Cheers, Ulrik.
P.S. In the meantime I've started to build a new texmf tree from scratch
and writing some INDEX.html files to navigate through the texmf/ tree.
There's a still a lot of do and many links are currently missing, but
just in case anyone is interested, you might want to have a look at
http://xerxes.thphy.uni-duesseldorf.de/~vieth/texmf/INDEX.html
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 02:27:05 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Date: Mon, 27 Mar 1995 09:26:28 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:236070:950327082648"@cl.cam.ac.uk>
> The old c.t.t FAQ (actually, the one that still gets posted) should be
> dumped from all distributions. It's way out of date, more than 50% of
> its information is not valid any more.
very true
> Robin Fairbarnes and a bunch of volunteers looked over the FAQ and
> produced a new one, for publication in UK-TUG's Baskerville. AFAIK, he
> doesn't plan to support if further.
oh no, we *are* planning to keep it up to date. the WWW version
changes as and when Robin is informed of changes. we originally hoped
Bodenheimer would take it on board, but thet doesnt look likely.
please tell anyone who cares to report fixes to the New FAQ to Robin;
we'll republish at intervals. the UKTUG committee attaches a lot of
importance to this exercise.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 03:02:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 09:59:17 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503270759.AA01072@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
[Rich:]
>> I'm not sure I understand this, but I think (from the discussion
>> above) that it is wrong. If something gets mounted on /usr/local,
>> any other use of /usr/local is hosed.
[Norm:]
> It's wrong.
>
> It looks like CD's should have /FONTS and /TEX, etc. in the root
> directory.
I think this depends on whether you'd really want to mount it directly
on /usr/local. I admit that I don't have much experience with CD-ROMs
on Unix, but I seriously doubt if anyone really wants to do it like that.
I guess it's more likely that people would want to mount the CD-ROM
on a special mount-point like /cdrom and then copy whatever they want
to /usr/local/texmf. In that case it wouldn't matter if the files
showed up as /cdrom/texmf/...
If your really wanted, you could set up a link from /usr/local/texmf
pointing to /cdrom/texmf or you could create a rudimentary tree below
/usr/local/texmf containg a ``link farm'' or something like that.
Besides, I'd think that it wouldn't be practical to mount the whole
texmf/ tree on read-only media. There are some configuration files
you might want to tune for your site, and what happens if MakeTeXPK
suddenly wants to install newly created files on texmf/fonts/pk/...
Personally, I'd favor having the texmf/ level show up on the CD-ROM
for clarity, and because that allows to put other stuff there as well.
If that prevents you from mounting it directly on /usr/local/texmf,
I wouldn't care much, because there are ways to get around this.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 03:40:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 10:41:35 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503270941.AA03036@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Ulrick
Personally, I'd favor having the texmf/ level show up on the CD-ROM
for clarity, and because that allows to put other stuff there as well.
If that prevents you from mounting it directly on /usr/local/texmf,
I wouldn't care much, because there are ways to get around this.
The point about having texmf as a directory on the CD or just
implicitly the top level of the CD is not really how it looks when
mounted, it is that with the former you have 7 available levels for
the texmf tree on the CD and with the latter you have 8.
So although we only use 7 levels at present, if we want to claim that
a future TDS extension will have an 8-level branch, then `texmf' must
be the top level of the CD, not a directory.
Although I would agree with Ulrick that having the CD have an
explicit texmf tree, thus allowing the CD to have other stuff as well
might be nice, so I am not sure we rerally should claim all 8 levels
if we can not think of any use for more than 7 levels.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 07:22:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 1995 14:19:49 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950327141949.22456a9c@vms.rhbnc.ac.uk>
Subject: ``Is the search order well-defined'': a real users asks...
Just thought you might be interested to see that ``real users'' care about
the search-order/tree-traversing-algorithm.
** Phil.
--------
Date: Sat, 25 Mar 1995 18:23:39 -0400 (EDT)
From: "Wonkoo Kim, EE, U. of Pittsburgh" <WKIM@vms.cis.pitt.edu>
Subject: Search order?
To: emtex-user@methan.chemie.fu-berlin.de
This is a simple question.
I wonder about the order of directory searching of emTeX.
If I had emTeX search all subdirectories (by adding "!!"), then in what order
of directories does the emTeX program look for a file?
I've read emTeX's doc, but it's not clear about the order of directories of
between the first level and the sucessive levels. (This question arised due
to the existence of two switches: "!" and "!!".)
If I had subdirs:
\texinput
\texinput\sub-a
\texinput\sub-a\subsub-a
\texinput\sub-a\subsub-a\subsubsub-a
...
\texinput\sub-a\subsub-b
...
\texinput\sub-b
\texinput\sub-b\subsub-a
\texinput\sub-b\subsub-b
then, does tex search input files in the above order?
Or, does it look all directories of the first level (sub-X's in the above)
first before seeing any further level of directories?
(Of course \texinput is the first. :) )
(It would be nice if first levels are searched first before further levels.)
Thanks.
Wonkoo Kim
wkim@vms.cis.pitt.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 11:32:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 1995 10:54:47 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503271554.AA06870@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: doc files again.
Well, maybe one could do with separate directories, or maybe another
level under doc/help/FAQ?
I suggest directories directly under doc/help.
There aren't *that* many involved.
The old comp.text.tex FAQs are mostly
outdated anyway and comp.fonts has so many files that it deserves
its own directory indeed.
I agree.
(BTW, Karl, aren't you
mentioned as a contributer in there as well?)
Probably, but when people ask me for descriptions or whatever I just
send the answers, and don't try to remember where it's going to be used :-).
I was confused by the similarly organized help/ and info/
directories on CTAN, but sure, they belong in doc/general here.
I have argued for renaming the info/ directory on CTAN for
precisely this reason.
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 11:33:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 1995 10:49:22 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503271549.AA06759@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
might be nice, so I am not sure we rerally should claim all 8 levels
if we can not think of any use for more than 7 levels.
I agree.
The advantage of claiming 8 levels is for an unknown future extension.
If there were no downside, it would be fine. But
installations/CD-ROM's/etc. today may be less clear/usable if we stick
to it...
Although using T: for texmf/ made sense to me when it was suggested, the
argument of having a real directory named `texmf', for the sake of
having something known to search for, also makes sense to me.
I don't think the TDS should specify anything about what (if anything)
should be siblings to texmf/ on a CD or wherever. (I think we all pretty
much agree on that.) All we need do is point out that we use only seven
levels, so a top-level texmf/ directory will work.
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 11:35:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 09:01:38 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503271701.AA28106@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
If the CD-ROM is just being used as a distribution medium, the mount point
is irrelevant, but then so is the directory layout. (The installation code
can unpack, shuffle, etc, on the fly.)
The real question has to do with mounting the disc as a reference volume,
to allow (for instance) small sites to have easy access to large amounts of
TeX-related materials, without installing masses of files. In this case, I
also think the disc would get its own location (e.g., /usr/local/texcd).
It is true that there may be some problems with the use of read-only media
getting in the way of installation of configuration files, etc. Understand,
however, that CD-ROMs are only one instance of read-only media, at least
from the viewpoint of the user. Consider the following scenario:
~<user>/texmf
/usr/<project>/texmf
/usr/local/texmf
/<cdrom>/texmf
/<server>/texmf
A user could easily have several texmf trees to call upon, depending on
personal, project-related, local, and other needs. Ultimately, the TeX
software will have to deal with this sort of thing.
DC> I am not sure we rerally should claim all 8 levels
DC> if we can not think of any use for more than 7 levels.
WRONG!
I recently mounted a new 9.1 GB disk drive on SunOS. I had to split the
thing up into five partitions to use all the space, because the BSD guys
never conceived that anyone would need a filesystem bigger than two GB.
Later this year, when the next generation of disks come out, I won't be
able to use them fully under SunOS, because it only allows 8 partitions.
(16 GB maximnum). There are many other examples of limiting standards;
this is only the most recent I've encountered.
It is *always* a good idea to plan for the possibility of growth. More,
as some of the directories under the TDS are specifically left up to the
package designers, we should leave them as many levels as possible for
their needs.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 12:18:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 18:59:36 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503271759.AA03260@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
R> WRONG!
R> ...
R> It is *always* a good idea to plan for the possibility of
R> growth....
Well I agree, but.... As Karl just said, this is planning for possible
future growth but giving up real functionality *now* in order to
achieve it. While clearly a TDS is likely to grow in size, there is
only a small possibility of any new file type requiring 8 levels, but I
would have thought it quite likely that someone would want to make a
mountable CD that contained a TDS tree in addition to some other
software. So it not a case of thinking that hard limits are a good
thing, rather just an assesment (based on no good grounds at all:-)
that the balance of probabilities more favours `mixed' CDs (hence a
7-level TDS) rather than an extended deep (8-level) TDS.
But you are the one in the CD business, so I don't know why I'm
arguing with you on this point...
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 12:29:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503271822.UAA14717@spice.iti.informatik.th-darmstadt.de>
Subject: Re: ``Is the search order well-defined'': a real users asks...
To: TWG-TDS@SHSU.edu
Date: Mon, 27 Mar 1995 20:22:56 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> Just thought you might be interested to see that ``real users'' care about
> the search-order/tree-traversing-algorithm.
Was this ever questioned?
The point of discussion was: ``Is the TDS concerned with
search orders and/or tree-traversing-algorithms at all?''
Two questions:
(1) search order.
The TDS draft uses the term `search path' but does not define
it. OK, let's do it: A search path is a list of sets of
filenames identifying existing files. (Standard algebraic
specs assumed for `list' and `set'.) As with every set,
filenames have to be uniq, there must not two files with the
same name in a search path element. I.e., search order is not
relevant for the TDS.
(2) tree-traversing-algorithms
The only point here is the hint that any algorithm, for any
search method, without caching will not be performant enough
for large set of files, in particular in a network-based
environment. I.e., the tree-traversing-algorithm is mentioned
neither.
That whole business is an implementation issue, and we should educate
users accordingly. But they will always care about implementation
issues, even if they shouldn't. (And they will most often care about
the wrong issues; to wit: search-order instead of caching... :( )
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, 27 Mar 1995 12:30:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 10:30:37 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503271830.AA28492@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
The really ironic part of this whole discussion is that almost every
OS supports several levels past the defined 8. It's just that we are
trying oh so hard to be CORRECT.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 12:55:08 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503271822.UAA14717@spice.iti.informatik.th-darmstadt.de>
Subject: Re: ``Is the search order well-defined'': a real users asks...
To: TWG-TDS@SHSU.edu
Date: Mon, 27 Mar 1995 20:22:56 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> Just thought you might be interested to see that ``real users'' care about
> the search-order/tree-traversing-algorithm.
Was this ever questioned?
The point of discussion was: ``Is the TDS concerned with
search orders and/or tree-traversing-algorithms at all?''
Two questions:
(1) search order.
The TDS draft uses the term `search path' but does not define
it. OK, let's do it: A search path is a list of sets of
filenames identifying existing files. (Standard algebraic
specs assumed for `list' and `set'.) As with every set,
filenames have to be uniq, there must not two files with the
same name in a search path element. I.e., search order is not
relevant for the TDS.
(2) tree-traversing-algorithms
The only point here is the hint that any algorithm, for any
search method, without caching will not be performant enough
for large set of files, in particular in a network-based
environment. I.e., the tree-traversing-algorithm is mentioned
neither.
That whole business is an implementation issue, and we should educate
users accordingly. But they will always care about implementation
issues, even if they shouldn't. (And they will most often care about
the wrong issues; to wit: search-order instead of caching... :( )
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, 27 Mar 1995 13:01:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503271852.UAA14759@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS Registry
To: TWG-TDS@SHSU.edu
Date: Mon, 27 Mar 1995 20:52:16 +0200 (MESZ)
Content-Type: text
Rich wrote, about a week ago:
>
> I have looked over Joachim's guidelines. I think they look very useful,
> if a bit rough in spots. (No rougher than some of the TDS drafts! :-)
> I think, in fact, that the guidelines should receive some editorial help
> and attention, and that they might well become a *very* useful guide.
I do appreciate any comments on the LaTeX bundle guidelines, as I
would like to improve that memo. [*] That should be done off-line,
though -- I don't consider these guidelines as relevant to any TDS
discussion. (Well, except that they should point to TDS documents.)
That's because they are concerned with source distributions, whereas
the TDS is concerned with binary distribution & installation.
Some short remarks on topics that were addressed in later postings
(starting with the the TDS-related ones).
-- Every person can add as many fields to Catalog as he or she wants.
It's just that they should use standard fields in the standard
way. (That's what I meant with RFC822-like. Seems I have to add a
glossary where I explain that in more detail.)
-- If the TDS wants me to add some more standard fields -- that's
fine with me. They should start with a common prefix, e.g., `TDS-'.
-- CATALOGs for bundles that are not freely distributable make no
sense at all. Remember, they are for handling a moderated CTAN
area. They may be fed automatically to some other place, though;
e.g., to a TDS registry. I'll process each contribution anyhow by
a Perl script.
-- If an author has given a personal reference site, that site will
be mirrored, to ease her contribution. CTAN clients will get
informed about this procedure.
Cheers,
Joachim
[*] A personal remark, nevertheless: The _very_ informal style of the
bundle memo was chosen by intent. First drafts used a more `serious'
tone, and not many people reacted to them. With the switch to the
sloppy tone I got much more feedback -- and positive one, in
addition. As this is not the work of some TWG, but is my personal
playground, I was able to do that switch. I don't consider it
appropriate for a `standards document' like the TDS specs, though.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 14:18:19 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: ``Is the search order well-defined'': a real users asks...
Date: Mon, 27 Mar 1995 21:18:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"gannet.cl.ca:208880:950327201904"@cl.cam.ac.uk>
i dont equate "i wonder" with "i really care because i have a
real-life application".....
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 14:46:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 1995 15:46:34 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503272046.AA10011@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Rich, is the real-life CD-limitation 8 levels,
or is that a bogus ``standard'' limitation?
From owner-twg-tds@SHSU.edu Mon Mar 27 13:34:27 1995
Date: Mon, 27 Mar 95 10:30:37 PST
From: rdm@cfcl.com (Rich Morin)
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
The really ironic part of this whole discussion is that almost every
OS supports several levels past the defined 8. It's just that we are
trying oh so hard to be CORRECT.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 15:49:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 95 13:49:31 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503272149.AA29208@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
KB> Rich, is the real-life CD-limitation 8 levels,
KB> or is that a bogus ``standard'' limitation?
I don't know of any particular OS that actually enforces the 8-level
limitation. I *have* been told that MS-DOG enforces the 256 byte
limit on full pathnames. I hadn't brought up that limit previously,
because it is subsumed by the 8-level/8-character combination.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 27 Mar 1995 16:41:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 27 Mar 1995 17:38:00 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503272238.RAA26405@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
References: <9503272149.AA29208@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 27 March 1995 at 13:49:31, Rich Morin wrote:
> KB> Rich, is the real-life CD-limitation 8 levels,
> KB> or is that a bogus ``standard'' limitation?
>
> I don't know of any particular OS that actually enforces the 8-level
> limitation. I *have* been told that MS-DOG enforces the 256 byte
> limit on full pathnames. I hadn't brought up that limit previously,
> because it is subsumed by the 8-level/8-character combination.
The limit on pathnames in MS-DOS is nowhere near as generous as 256 bytes.
It's actually 64 bytes (even on a hard disk where the number of levels
is not strictly limited). But the TDS isn't approaching that limit, so
I don't think we need bother mention it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 28 Mar 1995 04:26:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 28 Mar 1995 11:26:50 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950328112650.22428068@vms.rhbnc.ac.uk>
Subject: Re: Announce: 0.69 (8 levels, again)
>> I don't know of any particular OS that actually enforces the 8-level
>> limitation.
Sadly I have to report that the One True Operating System (a.k.a. VMS)
enforces that very restriction; concealed rooted logical names can
ameliorate the situation but not entirely circumvent it.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 28 Mar 1995 07:59:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 28 Mar 1995 09:00:06 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503281400.AA29952@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
Well, my feeling is that until we use all 8 levels, it's up to the blokes
that put together the
The question is, are we changing things to specify the top-level
directory always be named `texmf', or leaving things so that `texmf' is
a placeholder (e.g., for t:).
================================================================================
From owner-twg-tds@shsu.edu Tue, 28 Mar 1995 15:06:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 28 Mar 1995 16:02:27 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503282102.QAA19870@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.70
Reply-To: TWG-TDS@SHSU.edu
Folks,
I've put 0.70 up. In all it's glory:
ftp://jasper.ora.com/private/twg-tds/tdsguide.{tex,texi,info,ps,dvi}
ftp://jasper.ora.com/private/twg-tds/*.sgm
ftp://jasper.ora.com/private/twg-tds/*.sty
http://jasper.ora.com/private/twg-tds
I've added the example documentation tree, fixed a bunch of things, and
had it copy-edited.
I'd like to shoot for an April 15 public release of our draft.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 28 Mar 1995 18:34:22 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 28 Mar 1995 16:35:17 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503290035.QAA15242@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu, norm@ora.com
Subject: Re: 0.70
I see that many of the TWG are identified by capsule biogrtaphies.
For the same of completeness, I will supply two more. I supply
Elizabeth's because I know from long experience that she would
refuse to admit that she had any part in this. It is virtually
impossible to get her to take the credit that is due her.
Tachikawa, Elizabeth (\literal{unixtex@u.washington.edu}). Formerly
associate director, Northwest Computing Support Center, at the
University of Washington, and the organizing
genius behind much of the best part of UnixTeX. Some of the original
inspiration for the \acronym{TDS} comes from Elizabeth's
early work to rationalize UnixTeX. Continues to contribute advice
and support to UnixTeX.
MacKay, Pierre (\literal{mackay@cs.washington.edu}). Professor, Dept.
of Classics and Dept. of Near Eastern Languages, University of
Washington. Together with Richard Furuta took over as Unix
Site-Coordinator for the distribution of {\TeX} from Robert Morris,
too many years ago to be remembered. Continues to support UnixTeX and
the production of beautiful books, particularly in the humanities.
================================================================================
From owner-twg-tds@shsu.edu Wed, 29 Mar 1995 04:01:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 29 Mar 95 11:08:18 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503290908.AA03593@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.70
> Folks,
> I've put 0.70 up. In all it's glory:
> I've added the example documentation tree, fixed a bunch of things, and
> had it copy-edited.
Hi Norm,
it's nice to see that you've include my example doc tree. However,
I'm afraid you've introduced a few mistakes and kept some that have
been pointed out already by others in the meantime.
doc/
. help/
. . CTAN/ info about CTAN sites, catalog, macro index
. . FAQ/ FAQs of comp.text.tex, comp.fonts, etc.
It was suggested to have separate directories for these. So maybe
something like this, although I'm not happy about the 8-charater names.
! . . cmp_fnts/ FAQs of comp.fonts (various formats)
! . . cmp_tex/ FAQs of comp.text.tex (if any)
. . newfaq/ newfaq-cm.dvi, newfaq.{dvi,ps}, newfaq.pdf
. info/
^^^^^
This should be general/ as pointed out by Karl.
. . components/ ...
. . lkurz/ ...
. . lshort/ ...
. . misc/ gentle.{tex,dvi}, ...
I guess this coud get its own directory as well if DVI and PS files
are kept, even though there is only one .tex file.
. general/
^^^^^^^^
I've decided to rename this to knuth/ in my personal doc tree,
because it's some sort of special systems documentation, that's
somewhat different from the other stuff that goes into general/.
. . errata/ errata.{tex,dvi}, errata[1-8].tex
. . errorlog/ errorlog.{tex,dvi}, tex82.bug, mf84.bug, cm85.bug,
. . . manuals/ texbook.tex, story.tex, mfbook.tex, mfman.nf, io.mf,
^^ mf
. . . triptrap/ tripman.{tex,dvi}, trip.tex, trapman.{tex,dvi},
^ trap.mf
This is one level to much for manuals/ and triptrap/. All of these
should be at the same level.
. web/ webman.{tex,dvi}, cwebman.{tex,dvi},
. tex/ texbook.tex, story.tex, letter.tex (?)
^^^^^^^^^^ I've left this out.
. metafont/ mfbook.tex, mfman.mf, io.mf
^ I've added expr.mf here.
. metapost/ mpman.{dvi,ps}, manfig.mp, mpgraph.{dvi,ps}, mpgraph.mp,
. dvips/ separate directorys for each of them (?)
. kpathsea/ .
. fontname/ .
. eplain/ .
. ams/
. . amsfonts/ amsfonts.faq, amfndoc.{tex,dvi},
. . amstex/ amsguide.{tex,dvi}, joyerr.tex,
. . amslatex/ amslatex.faq, amsldoc.{tex,dvi},
. latex/
. . amslatex/ -> ../ams/amslatex
Two problems here: (a) the idea of symbolic links is Unix-centristic,
(b) the OT1-encoding gives the wrong symbols here:
`>' turns into an inverted question mark
`{' and `}' have disappeared, unsurprisingly
. . base/ ltnews*.{tex,dvi}, *guide.{tex,dvi},
. . . graphics/ grfguide.{tex,ps}
. . . german/ -> ../generic/german
. . . styles/ ...
Again, this is one level too much for graphics/, styles/, etc.
All of them should be on the same level. (Is that correct, David?)
. fonts/
. . . fontname/ -> ../fontname
. . . amsfonts/ -> ../ams/amsfonts
. . . oldgerm/ corkpapr.{tex,dvi}
. generic/
. . . german/ germdoc.{tex,dvi}
. . . babel/ ...
Again, all of these are one level too deep. There shouldn't be
a need for more than two levels anywhere in this tree, I believe.
Apart from all this, the file and directory names in the descriptions
should be in typewriter type, which might cause problems with limited
line length, again.
Another question is whether directories should be sorted alphabetically
or logically here. Using a non-alphabetical ordering, however,
might open room for discussion about how things should be sorted...
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 29 Mar 1995 09:06:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 29 Mar 1995 17:06:46 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Announce: 0.69 (8 levels, again)
To: TWG-TDS@SHSU.edu
Message-ID: <01HOPRXT998Y9YCYBZ@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
VMS has the 8 levels limitation. It was mentioned here long ago.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Wed, 29 Mar 1995 12:10:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 29 Mar 95 10:10:37 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503291810.AA07274@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: n/n, 0.70
1. Section 2.1, paragraph 6:
... for VMS.
... for VMS. Thw TWG has adopted the {\em de facto} standard
syntax (//) for specifying subdirectory searching:
.:/foo/nosearch/:/bar/search//
2. pages 15,17
Both figures extend into the margin.
No "Figure" indication is given for either of these, despite the
fact that the latter is referenced (on page 16) as Figure 10.1
3. Appendix D
... editor of ``Prime ...
... Editor of ``Prime ...
... time, she works as a Quality Engineer for Taligent.
... time, she is employed as a Quality Engineer.
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Mar 1995 06:03:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Mar 1995 07:04:05 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199503301204.AA05770@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: n/n, 0.70
Thw TWG has adopted the {\em de facto} standard
syntax (//) for specifying subdirectory searching:
.:/foo/nosearch/:/bar/search//
I thought we intentionally left out the // stuff because it was
unsuitable on VMS (already has its syntax) and other systems.
I'm not sure what emtex uses to specify subdir searching,
but I don't think it's //, so it's not really a standard.
Better to say nothing at the moment, I think.
Perhaps another poll of implementors would be useful (at some point, not
before the draft), asking what their preferred subdir searching syntax
would be. Then maybe we can attempt to codify that.
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Mar 1995 06:43:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Mar 1995 13:40:54 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950330134054.224540c7@vms.rhbnc.ac.uk>
Subject: RE: n/n, 0.70
>> I thought we intentionally left out the // stuff because it was
>> unsuitable on VMS (already has its syntax) and other systems.
>> I'm not sure what emtex uses to specify subdir searching,
>> but I don't think it's //, so it's not really a standard.
VMS uses [.*] to indicate <and all direct subdirectories thereof>,
[...] to indicate <and all direct and indirect subdirectories thereof>,
and <comma> to separate disjoint entities;
emTeX uses trailing ! to indicate <and all direct subdirectories thereof>,
!! to indicate <and all direct and indirect subdirectories thereof>,
and <semi-colon> to separate disjoint entities;
PubliC TeX uses trailing \\ to indicate <and all subdirectories thereof>,
but the documentation does not clarify whether this means just direct,
or direct + indirect; I believe the latter. It uses semi-colon to
separate disjoint entities.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Mar 1995 06:43:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Mar 1995 07:39:37 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199503301239.HAA27897@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: n/n, 0.70
References: <199503301204.AA05770@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 30 March 1995 at 07:04:05, K. Berry wrote:
> Thw TWG has adopted the {\em de facto} standard
> syntax (//) for specifying subdirectory searching:
>
> .:/foo/nosearch/:/bar/search//
Where does this statement occur? I don't see it in 0.70 at all.
> I thought we intentionally left out the // stuff because it was
We did. (Although it turns up in the example about a local tree;
however, I don't see that as a problem.)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Mar 1995 12:51:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Mar 95 10:51:59 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9503301851.AA11545@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Well, shut my mouth!
I guess this got discussed before I got on the list. I had *no idea* that
things were in such a muddle (sigh). Well, it might still be worth noting
what is meant by the syntax in the document, and that the syntax is *not*
specified, if only to avoid confusing people. How about:
Thw TWG does not require any particular syntax for specifying
subdirectory searching. In this document, we follow the ?web2c?
practice of using a doubled slash (//). Here are some of the
syntax variations known to exist in current packages:
/foo/nosearch/:/bar/search// ??? web2c ???
[foo.nosearch],[bar.search.*] ??? VMS ???
\foo\nosearch\;\bar\search! ??? emTeX ???
\foo\nosearch\;\bar\search\\ ??? PubliC TeX ???
-r
P.S. I think it would be lovely to recommend a secondary syntax for
all TeX packages to follow, but this seems like far too big a
can of worms to open in the TDS. Sigh. -r
================================================================================
From owner-twg-tds@shsu.edu Fri, 31 Mar 1995 01:40:34 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Well, shut my mouth!
Date: Fri, 31 Mar 1995 08:40:05 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:005700:950331074017"@cl.cam.ac.uk>
as has been sai d in the past, athe apparently logical \\ in DOS means
something very specific in Novel Networks, which are extremely
common. i'd go with Rich and just list what people have done. Please
note that Y&Y TeX supports // (and \\ as well i think, but berthold
probably doesnt have a network)
sebastian
From owner-twg-tds@shsu.edu Sun, 02 Apr 1995 07:09:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 2 Apr 1995 09:10:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504021310.AA12261@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.70
. . misc/ gentle.{tex,dvi}, ...
I guess this coud get its own directory as well if DVI and PS files
are kept, even though there is only one .tex file.
By that argument any documentation at all would get its own directory.
There are too many directories already, IMHO.
. metafont/ mfbook.tex, mfman.mf, io.mf
^ I've added expr.mf here.
expr.mf as a doc file?
. . errata/ errata.{tex,dvi}, errata[1-8].tex
. . errorlog/ errorlog.{tex,dvi}, tex82.bug, mf84.bug, cm85.bug,
Is there any big reason to have separate directories here?
. . . manuals/ texbook.tex, story.tex, mfbook.tex, mfman.nf, io.mf,
^^ mf
manuals? What does this mean? How about just dropping this directory?
Everything in there is in other places as well.
. dvips/ separate directorys for each of them (?)
The comment should not stay.
Two problems here: (a) the idea of symbolic links is Unix-centristic,
It's just an example. Have to have a directory with a README pointing to
the real directory in a maximally portable distribution.
For that matter, having the same file in more than one place is also
dubious, for the same reason.
================================================================================
From owner-twg-tds@shsu.edu Sun, 02 Apr 1995 11:15:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 2 Apr 95 09:15:24 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504021615.AA24107@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: TDSR thoughts
I have been thinking about the question of reserving space in the TDS.
My initial notion was that the applicant would ask for specific paths:
texmf/doc/latex/martian
texmf/doc/plain/martian
texmf/tex/hyphen/martian
texmf/tex/latex/martian
texmf/tex/plain/martian
texmf/fonts/source/public/martian
texmf/fonts/tfm/public/martian
On reflection, I wonder if this might not lead to errors and confusion.
Instead, I'd like to propose a system in which the developer submits a
name and one or more types (<name:type[,...]>, and automagically gets
allocated appropriate space, as:
TR-Usage martian:font
This method would, of necessity, allocate more name space than any single
package would actually need. (Martian might not *have* an ams version :)
I don't see this as a problem: name space is cheap, and I think we would
be just as happy *not* to have two "martian" packages running around in
the Registry.
For related reasons, I'm a bit unclear on the "type" question. It seems
to me that the TDSR should probably allow multiple types with the same
name, but only by the same supplier. This would make conflicts within a
given name into the supplier's problem, much as the DNS and IP registries
leave subsidiary names to the organizations involved.
Please consider this an informal request for comment: I'd like to know
about things I'm missing, misunderstand, etc.
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 03 Apr 1995 04:55:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 3 Apr 95 11:10:39 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504030910.AA05671@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: 0.70 (doc)
Karl wrote:
> . . misc/ gentle.{tex,dvi}, ...
>
> I guess this coud get its own directory as well if DVI and PS files
> are kept, even though there is only one .tex file.
>
> By that argument any documentation at all would get its own directory.
> There are too many directories already, IMHO.
Well, in this case it is indeed a question of judgement. If a doucment
consists of several source files, it is quite clear that it should have
a separate directory and the .dvi and .ps files can go there as well.
But what if a document consists of only a single source file but there
are several files for that document after producing .dvi and .ps files?
I really don't know what's best. Perhaps keeping the source files in
subdirectories but putting all the .dvi and .ps files at the top level?
> . metafont/ mfbook.tex, mfman.mf, io.mf
> ^ I've added expr.mf here.
> expr.mf as a doc file?
It's not quite a doc file, but a file that should accompany mfbook.tex.
Chapter 8 tells you to type it and do some experiments. Besides, it is
not just an utility program to evaluate expressions online. There is
some extra junk at the beginning that's used for example purposes only.
> . . errata/ errata.{tex,dvi}, errata[1-8].tex
> . . errorlog/ errorlog.{tex,dvi}, tex82.bug, mf84.bug, cm85.bug,
>
> Is there any big reason to have separate directories here?
One might argue that errata/ contains changes to Volumes A--E that might
be interesting to users, wheras errorlog/ contains changes to the sources
that are only of interest to hackers. Knuth himself puts them together
in one directory, so maybe this distinction isn't that important.
> . . . manuals/ texbook.tex, story.tex, mfbook.tex, mfman.nf, io.mf,
>
> manuals? What does this mean? How about just dropping this directory?
> Everything in there is in other places as well.
Well, my original idea was to make this stuff easy to find by putting
it into several places. One might find it by category doc/knuth/manuals
or by program doc/tex. The latter might contain various stuff related
to TeX, so not just texbook.tex, but also tripman.tex or tex82.bug.
However, I'm not sure if this is the best way to do it. I didn't mean
to put this into the current draft when I posted it in the first place.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 03 Apr 1995 08:33:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 3 Apr 1995 09:32:31 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504031332.AA21502@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.70 (doc)
I really don't know what's best. Perhaps keeping the source files in
subdirectories but putting all the .dvi and .ps files at the top level?
We already agreed that subdirectories based on file types like `dvi' and
`ps' is the wrong thing.
I vote for single-document sources going in misc/, like we do with
everything else. If there are .dvi/.ps versions, put them there too. A
couple of files is better and easier to navigate through than another
directory. IMHO.
One might argue that errata/ contains changes to Volumes A--E that might
be interesting to users, wheras errorlog/ contains changes to the sources
that are only of interest to hackers. Knuth himself puts them together
in one directory, so maybe this distinction isn't that important.
I suggest we merge them.
Well, my original idea was to make this stuff easy to find by putting
it into several places. One might find it by category doc/knuth/manuals
or by program doc/tex. The latter might contain various stuff related
To be honest, I don't think texbook.tex and mfbook.tex are all that
critical that we need to worry about putting them in a billion
places. They're not easy to search in.
I think I like the idea of doc/knuth, though, for all the things Knuth
himself wrote, as opposed to all of us Johnny-come-lately's. Judging by
the mail I get, many users are interested in this.
(That is, doc/knuth *in addition to* the ``logical'' locations, not
instead of. And if you can't have links in your medium, don't bother.)
================================================================================
From owner-twg-tds@shsu.edu Mon, 03 Apr 1995 18:38:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 3 Apr 1995 19:38:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504032338.AA01165@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: damian.cugley@prg.ox.ac.uk
Subject: official tds abbreviation
Damian mentioned that it would be helpful to have an official
abbreviation for the TDS report. I think all that may be needed is to
put (TDS) into the title, i.e.,
TeX Directory Structure (TDS) 1.0
If that doesn't suit, I suppose it could go in the first paragraph or
something.
Then people won't hesitate about referring to it as TDS 1.0 or whatever.
================================================================================
From owner-twg-tds@shsu.edu Tue, 04 Apr 1995 05:09:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 4 Apr 1995 06:03:42 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504041003.GAA18904@jasper.ora.com>
To: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
CC: twg-tds@shsu.edu
Subject: Re: Problems finding included graphics file
References: <9503310343.AA0175@loon.econ.wisc.edu> <199504031356.PAA26780@azu.informatik.uni-stuttgart.de>
Reply-To: TWG-TDS@SHSU.edu
On 3 April 1995 at 15:56:56, Eberhard Mattes wrote:
> T. Scott Thompson writes:
>
> > SET DVIDRVGRAPH=C:\EMTEX\TEXINPUT!;C:\EMTEX\DOC
>
> The DVI drivers no longer support ! and !!.
Just for graphics, or in general!?
I haven't tried to install the new release yet, and haven't followed
the mail too closely, so I appologize if you've already answered this,
but why did you elect not to support subdirectory searching in the
drivers?
I'm chairing the TUG Working Group on a TeX Directory Structure (TDS)
and one of the hard decisions that we made early on was that a decent
TDS would require subdirectory searching. The font area has
subsequently been rearranged to make the volume of material that has
to be searched smaller, but I still think searching is "the right
thing".
Your thoughts would be greatly appreciated.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 05 Apr 1995 06:44:20 CDT
Sender: owner-twg-tds@SHSU.edu
From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 5 Apr 1995 13:43:59 +0200
Message-ID: <199504051143.NAA26021@azu.informatik.uni-stuttgart.de>
To: norm@ora.com
CC: twg-tds@shsu.edu
Subject: Re: Problems finding included graphics file
> Just for graphics, or in general!?
Just for templates. There is no longer an option for specifying the
search path for TFM files, therefore ! and !! still work for TFM
files.
Eberhard
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 11:31:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Apr 1995 19:25:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504132325.AA04836@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: vojta@math.berkeley.edu
Subject: [vojta@math.berkeley.edu: tds question]
A question from Paul.
My own theory on this is that the answer is no -- this is beyond the
tds' purview. Obviously the new font has to be stored in a separate
directory, outside the standard texmf tree, and the location of such a
directory must of necessity be left to the local administrators.
Perhaps this would be worth mentioning in the standard as something we
explicitly do not standardize. It's a relatively common problem in its
various guises.
Date: Wed, 12 Apr 1995 16:33:51 -0700
From: vojta@math.berkeley.edu (Paul Vojta)
To: kb@cs.umb.edu
Subject: tds question
Karl:
Is there a TDS-standard way of dealing with the following setup:
texmf is rooted at /usr/lib/texmf
texmf contains all of the cm fonts at magsteps 0, 1/2, 1, 2, 3, 4, 5
/usr is mounted read-only
MakeTeXPK creates a font (at some other size)
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 11:31:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 1995 11:56:18 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504141556.AA15043@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: mft files
We don't mention mft files.
Should we?
Traditionally we've put mft files into tex/mft, but with the explosion
of top-level directories, maybe they should go there?
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 11:31:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 1995 11:56:16 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504141556.AA15027@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: doc/
Norm put up a new draft yesterday at my request. Wording comments in the
next message. The only substantive comment:
The doc/ tree is still a mess. Ulrik, would you mind taking another look
and trying to get something consistent out of it? Right now there is the
tree in the complete TDS skeleton figure, the doc/ skeletong figure, and
the text. All are inconsistent with each other. The TDS example figure
seems more or less correct as far as it goes, but it doesn't go far
enough.
Independent of what the final contents of doc/ are, I suggest the
complete TDS skeleton figure just have a single line
doc/ see figure x.y.
since doc/ is really irrelevant to our main work, and people will get
freaked when they see html/texinfo/etc./etc. there.
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 19:21:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 1995 15:00:19 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504141900.PAA12803@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: mft files
Reply-To: TWG-TDS@SHSU.edu
> We don't mention mft files.
> Should we?
>
> Traditionally we've put mft files into tex/mft, but with the explosion
> of top-level directories, maybe they should go there?
Aren't they documentation of a sort?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 19:21:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 1995 15:00:01 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504141900.PAA12761@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: [vojta@math.berkeley.edu: tds question]
Reply-To: TWG-TDS@SHSU.edu
> A question from Paul.
>
> My own theory on this is that the answer is no -- this is beyond the
> tds' purview. Obviously the new font has to be stored in a separate
> directory, outside the standard texmf tree, and the location of such a
> directory must of necessity be left to the local administrators.
>
> Perhaps this would be worth mentioning in the standard as something we
> explicitly do not standardize. It's a relatively common problem in its
> various guises.
>
> Date: Wed, 12 Apr 1995 16:33:51 -0700
> From: vojta@math.berkeley.edu (Paul Vojta)
> To: kb@cs.umb.edu
> Subject: tds question
>
> Is there a TDS-standard way of dealing with the following setup:
>
> texmf is rooted at /usr/lib/texmf
> texmf contains all of the cm fonts at magsteps 0, 1/2, 1, 2, 3, 4, 5
> /usr is mounted read-only
> MakeTeXPK creates a font (at some other size)
>
> --Paul Vojta, vojta@math.berkeley.edu
If 'texmf' is on a writable disk, I'm not sure it's "wrong" in a standards
sense to put the PK files into the texmf tree. That's the way I handle
it here (where I trust everyone enough to leave texmf/pk world writable).
If you can't (or aren't willing) to write to texmf, you can put a second
PK tree in your "local" texmf tree (see page 8 of 0.71).
I hacked MakeTeXPK so that it put things in the right place...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 19:24:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Apr 1995 16:01:55 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504132001.QAA15372@jasper.ora.com>
To: twg-tds@SHSU.edu
Subject: Toward a public draft ... 0.71
Reply-To: TWG-TDS@SHSU.edu
I think we're getting closer to a publicly draft. I don't think we'll
make the Apr 15 deadline that I suggested, in part because I've been
fighting fires all week.
At Karl's suggestion, draft 0.71 is now called "tds.{ps,dvi,tex}"
instead of tdsguide.
ftp://jasper.ora.com/private/tds.*
I didn't bother to produce TeXinfo or HTML versions this time around.
So shoot me.
The outstanding content issues are:
- The documentation section. I've worked it over a little bit, and
modified the figure again, but do we like it yet? If not, what do
we need to do?
- The references section. What else needs to go there.
- The file format appendix. Maybe the public draft will initially
go out without it?
- The about the committee appendix. If you want to be there, tell me
NOW. I would like *everyone* to be on the list and I was going to
be inclusive by default, but since some folks
who are listening on the list explicitly wanted to be excluded, I
decided it was safer to be exclusive by default. Stand up and be
counted!
- Is the copyright notice reasonable for this document? Does TUG
approve of being the copyright holder? Do they approve of the
"permission to reproduce" statement? (I suppose it'll have to be
"copyright TUG, portions copyright ORA" when we add the extension
appendix).
The outstanding formatting issues are:
- Logos and fonts. Does the document use the right ones now?
- Joachim didn't have time to send me the single-file style wrapper.
- The ltxguide.sty style does a crummy job on figure titles (I think
prepending "Figure <figure number>" would be a good idea; especially
now that they float).
Am I missing anything?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 19:56:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 95 17:50:27 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504150050.AA04485@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
> ftp://jasper.ora.com/private/tds.*
Actually, ftp://jasper.ora.com/private/twg-tds/tds.*
-r
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 20:45:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 95 18:36:46 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504150136.AA04808@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: Toward a public draft ... 0.71
> - The file format appendix. Maybe the public draft will initially
> go out without it?
Well, I won't be able to do anything about it for at least a week, as
I'm killing myself to get a release out. So, if you're waiting for me
to do it, I think we'll have to punt on the initial draft.
BTW (and I *know* this is late in the game to mention it), I'm beginning
to get concerned about the fact that there doesn't seem to be any way
to separate out OS-specific versions of files, other than in the bin
directory. How is a network server (or a CD-ROM) supposed to handle the
need for varying formats of TeX-related files?
-r
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 22:33:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 95 20:31:43 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504150331.AA05160@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: 0.71 notes
Page 1:
Several forms of this document are available from the directory:
ftp://jasper.ora.com/pub/twg-tds
DVI The DVI file for this document is available as tds.dvi.
LaTeX The LaTeX (2e) sources are available as tds.tex.
PostScript The PostScript for this document is available as tds.ps.
Texinfo The Texinfo sources are available as tds.texi.
HTML This document is available on the WorldWideWeb as:
http://jasper.ora.com/pub/twg-tds/tds.htm
page 5, par. 6:
... left to the implmentor ...
... left to the implementor ...
page 8, footnote:
The name spsun413 is one possible (ISO-9660 compliant) abbreviation
for SPARC SunOS 4.1.3.
page 9, footnote:
It's really tacky to spread a footnote onto two pages! I see one
place (the end of the generic bullet item) where a line could
probebly be trimmed. Find another and you're home free!
page 17 (for the Nth time!):
The expression "e.g." does not require more than one example. It
particularly does not need to be closed with ", etc." Please try:
Package (e.g., graphics) documentation
Name of a font supplier (e.g., ams)
TeX applications, by name (e.g., dvips)
Multi-file formats (e.g., graphics)
Multi-file packages (e.g., babel)
Page 19:
Can SPQR or someone please assign a spot in the CTAN for the TDS
Registry, so we can kill off the "???"? Also, I wonder about the
propriety of tying the registry email address to a single, profit-
making enterprise. Can we install a mirror account, perhaps at
SHSU, for this purpose?
page 21, item 3:
... editor of ...
... Editor of ...
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 22:39:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 95 20:38:58 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504150338.AA05202@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Ooops!
Page 1:
Several forms of this document are available from the directory:
ftp://jasper.ora.com/pub/twg-tds/
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Apr 1995 23:31:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Apr 1995 11:56:17 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504141556.AA15035@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 0.71 comments
\author{The TUG Working Group on a {\TeX} Directory Structure}
Here I would add ``(TWG-TDS)'', so people see our two common
abbreviations up front. On a separate line, if you can coerce latex into it.
(I like the new front page a lot!)
\emphasis{This is a draft specification. This is only a draft.}
This is a draft. It is only a draft. In the event of a real release, you
would be informed ...
:-). (No, I'm not suggesting you change the text.) (Non-American folks
probably won't get this; never mind, it's not worth explaining.)
The LaTeX (2e) sources are available from
\LaTeX
\path|ftp://jasper.ora.com/pub/twg-tds/tds.tex|.
I assume jasper will be replaced by CTAN in the real release?
Also, it's kind of confusing because the damn path breaks in a different
place every time. I wonder if it would be simpler to say:
This document is available in several formats from from jasper.ora.com:
\path|ftp://jasper.ora.com/pub/twg-tds/tds.tex| LaTeX (2e) source.
\path|ftp://jasper.ora.com/pub/twg-tds/tds.dvi| DVI
...
\path|http://jasper.ora.com/pub/twg-tds/tds.htm| HTML
A single line each, is the key.
And don't forget the .info format.
install it. This has resulted in hundreds of slightly (or not so
slightly) different installed configurations.
Suggest deleting `slightly (or not so slightly)'. Not in a standard.
directory structure for macros, fonts, and other such
TeX directory structure (TDS) for ...
local system uses the {\TeX} Directory Structure (\acronym{TDS}) recommended here.
Can then delete the `(\acronym{TDS})' here.
a nightmare: it is impossible to determine what files are used by
difficult: ...
which formats, what files need to be updated when a new release is
formats => packages [for consistency with all other cases]
which formats, what files need to be updated when a new release is
release => version
more macro packages happen to have input files with the same name.
Delete `macro'. We're using `package' in a general sense here.
Therefore, the TWG felt each package and typeface should be in a
Delete `and typeface'.
packages and typefaces a site may wish to install. Aside from
Delete `and typefaces'.
Also, installing or removing a new package would mean
Also, if all directories are explicitly listed, installing ...
On systems without some form of runtime configuration,
some => any
As a result, the TWG concluded that a comprehensive \acronym{TDS} required
that implementations of {\TeX} must support some form of implicit subdirectory
searching. In other words, it must be possible to specify that {\TeX},
... required implicit subdirectory searching. That is, it must ...
The TWG recognizes that subdirectory searching places an extra burden
...
database, performance is irrelevant: the file won't be found at all.)
I think this entire paragraph should be moved as-is to B.2 (better way
for fonts). It's just discussion, not really part of the spec.
As a consequence of the search strategy outlined above, the presence
...
respective subtrees in the desired search order.
Note, also, that the \acronym{TDS} does not specify the order in which
...
differently on different systems.
These two paragraphs are saying the same thing in two different
ways. Here's my consolidation:
The \acronym{TDS} does not specify the order in which subdirectories are
descended. It follows that two identically named files in a search path
leads to ambiguity. The \acronym{TDS} does not define which one is
found. In order to resolve this ambiguity, a search path must be
specified that lists the respective subtrees in the desired search
order.
Among systems that support subdirectory searching, there are several
[...]
interoperability wherever possible.
How about simply: The TDS does not specify a syntax for specifying
recursive searching, but we encourage implementors to provide
interoperability wherever possible. See A.3 for a list.
[Then make a new section A.3 that lists extant subdir searching syntaxes
-- I seem to recall such a thing being posted earlier.]
Having accepted that subdirectory searching is necessary, the \acronym{TWG}
Having accepted the necessity for subdirectory searching, ...
The other constraints arise because it must be possible to implement
These other ... possible to use
The \acronym{TWG} found that the most constraining
environment was the {\acronym{ISO}-9660} \acronym{CD-ROM} format.
The specifications of this environment are detailed below.
I would delete this (in concert with other changes below).
A special note about filenames: many, but not all, operating systems
...
the space required for all the files.
How about a subsection `Alphabetic case in filenames' or some such for
these two paragraphs.
One use of the \acronym{TDS} will be the creation of mountable generic
In particular, one use ...
Filenames may have extensions of up to three characters.
may not exceed three
Names and extensions may \emphasis{only} be made up of the
character set \literal{A}--\literal{Z},
\literal{0}--\literal{9}, and underscore.
... may consist of \emph{only} the characters A-Z, 0-9, and _ (underscore).
Note that any alphabetic characters must be in uppercase.
Suggest deleting, because we have all that text saying that we don't
require uppercase names.
(e.g., \path|FILENAME.EXT;1|, \path|FILENAME.;32767|).
This breaks confusingly, so I'd delete the second example name.
lowercase, removing extensions and trailing periods, etc.
extensions => version numbers [I assume]
directory \path|texmf|, but the actual name of the directory is
``\path|texmf|''
(I wonder if \replaceable{texmf} would be better.)
{\TeX} system, (including {\protect\MF}, {\MP}, {\protect\BibTeX}, etc., not just {\TeX}
delete comma before (
itself) and it is
add comma after )
implementation (such as \path|emtex|, or \path|pctex|).
(e.g., \path|emtex|)
[why have two examples here? It just confuses things, given the next
paragraph.]
Not all of these directories
are needed at all sites.
A site may omit any unneeded directories.
the \acronym{TDS}. For example, Unix sites may wish to place all
Unix \TeX administrators
formats) in the \path|texmf| tree. This greatly simplifies
administration, especially if the {\TeX} tree is maintained by someone
other than the system administrator. Moreover, it allows the
... tree, especially if ...
It may be convenient to store
implementations (\application{em{\TeX}}, \application{PC{\TeX}},
etc.) as well as utilities (\command{dvips},
\command{MakeIndex}, etc.) in their own directories.
Implementations can store configuration files, compiled {\TeX}
format files, {\protect\MF} bases, {\MP} mems, pool files, \acronym{DLL}s, etc. in
their own directory. Utilities can store configuration files,
input files, etc. in their own directory.
... implementation-specific files (configuration files, compiled {\TeX}
format files, {\protect\MF} bases, {\MP} mems, pool files,
\acronym{DLL}s, etc.) and utility-specific files (configuration files,
input files), in their own directories.
The name \path|spsun413| is one possible
abbreviation
for \path|sparc-sunos-4.1.3| that could be made {\acronym{ISO}-9660}
compliant.
... possible ISO 9660-compliant abbreviation for \path|sparc-sunos-4.1.3|.
sources (for example, \application{Web2C} sources could go in
Delete `could'.
Note that the \path|texmf| tree provides no explicit location
for ``local'' files. Consequently, to avoid possible name collisions,
The standard texmf tree ... files, since that would require duplicating
the entire tree. Consquently,
[it's for more reasons than name collisions]
By providing a format directory, subdirectory searching can be
subdirectory => path
By adjusting the \systemitem{ENVIRONVAR}{TEXINPUTS} search
TEXINPUTS => \TeX inputs (regular type)
[we're not talking about the impl-specific environment variable here]
path, it is still straightforward to use them as macro packages under
Delete `still'.
codes of Plain {\TeX} and does not rely on any particular format.
\path|null.tex| is an example of a \emphasis{generic}
{\TeX} file.
format (e.g., \path|null.tex|).
[the \emphasis is wrong, in any case]
The \path|plain| directory is intended for files which are
[...]
\path|texnames.sty|, \path|null.tex|, etc.
I don't think this paragraph should be part of the list, sinc eit's
really an explanation leading up to the next paragraph.
It may be necessary to search other directories as well.
Other directoried may be searched as well.
are examples of \replaceable{packages}.
packages => package
[you don't add the `s' in any other section]
\replaceable{packages} as described in this document are
\emphasis{not} {\LaTeXe} packages, even though there exist {\LaTeX}
packages with the names listed above. {\LaTeX} packages are style files
that add more macro code to document classes. \acronym{TDS} packages are
sets of files distributed, installed, and maintained as
units.
I think this should go in the conventions section.
in the \replaceable{format} directory. For example,
directory, instead of `format/base'. For ...
Like macros, fonts need to be stored in a hierarchical structure in order to
As with macros, the TDS stores fonts in ...
\subsection{Font Sources}
I don't think this should be a subsection.
You talk about more than sources, and we don't break up the other
sections. (Maybe we should.)
Admittedly that means the other subsection (on bitmaps) is kind of
hidden after all this text, but I see no alternative.
\path|monotype|, and \path|ams|, are
Delete the comma after ams.
purpose: it designates fonts for which there are no licensing problems
if/when they are redistributed.
... fonts which can be freely redistributed.
Fonts with different device types (modes) are generally segregated
into separate directories.
Following common practice, the TDS segregates fonts with different
device types (modes) into separate directories.
\path|cmr10.pk| in the directory \path|dpi300|.
the => a
For {\PS} fonts rendered as bitmaps with the \command{ps2pk}
program, the mode \path|ps2pk| shall be used.
\command{gsftopk} is handled analogously.
For PS fonts rendered as bitmaps by a program that does not distinguish
between different output devices, the \replaceable{mode} name shall be
that of the program (e.g., `ps2pk', `gsftopk').
If \path|GF| files are also to be kept, they would fall in:
GF files are stored in a parallel structure:
There was considerable discussion about how the disadvantages of this
scheme could be minimized. One result of that discussion was the
... how to minimize the disadvantages of this scheme.
[I still don't like the way this paragraph is worded -- for purposes of
the std, the discussion is irrelevant, if you see what I mean.]
information is \emphasis{already} in your \path|PK|
No need to emphasize?
must be made to your local modes file and all \path|PK| files
must be rebuilt.
can be made to your local modes file and the PK files rebuilt.
Most {\protect\MF} input files are fonts; however a few non-font input files do
are fonts (see the previous section); however, a ...
The files used by {\iniMF} when building
a new base also fall into this catagory.
They do? cmbase.mf doesn't go here. I don't get it. Suggesting deleting.
[Also, `category' is misspelled.]
This includes files used by
{\iniMF} when dumping base files
containing preloaded macro definitions.
Again, suggest deleting.
itself and the canonical example \path|story.tex|,
from \citetitle{The {\TeX}book}.
[this is out of order, sorry]
You don't say `from the mfbook' for io.mf, so I'd delete `from the
texbook' here. They can get it other ways besides typing it in ...
{\MP} utility programs.
These files include things like a font map, a character adjustment table,
programs, including a font map, ...
[``things like''? surely you jest :-)]
{\protect\BibTeX} databases of common interest shall be stored in
\path|texmf/bibtex/bib|.
databases of common interest => database files
[you don't say `of common interest' for anything else, so let's not do
it here. We don't mean anything different.]
keep the documentation together and (2) make it straightforward for users to
... as straightforward as possible ...
[let's be humble]
Joachim Schrod's \citetitle{Components of {\TeX}},
I thought components was multiple files.
Anyway, it seems a shame to use up general/ for single-file
docs, when we call it misc/ everywhere else. Maybe general/errata,
general/misc, etc, general/componen, etc.? Ulrik, where are you :-)?
See \xref{Figure 8.1}.
Is it possible to make this come out inline, right here, with nothing
following? (Filling out the current page with blank space if necessary.)
I find the floating figure pretty confusing, both here and when I'm
reading the next section.
\begin{figure}{An example of \acronym{TDS} documentation}
Rewrite of caption: A skeleton of the TDS example tree under texmf/doc.
1) The number `8.1' does not come out anywhere.
2) If you put doc/ in the caption, everything else can move over. I
think that's just as clear, if not more so.
3) all directories should have a / after their names
4) all filenames should be typewriter
5) help!
For example, a package for Martian language typesetting might be distributed
... typesetting that works with plain \TeX and \LaTeX ...
\xref{Figure 10.1} presents a graphical view of the \acronym{TDS}.
\begin{figure}{A general example of \acronym{TDS} implementation}
1) Again, I'd like to see this table not float to a new page.
2) I really really like this table. How about if we put it in chapter 1,
as a bird's-eye view of what will follow?
3) Rewrite of caption: A skeleton of the TDS texmf tree.
(Then everything else can move over)
4) I hate to say it, but I think all the one-line descriptions should
start with lowercase (unless a proper noun, of course), since they're
not sentences.
5) I would delete etc. in all cases. Saying `e.g.' is enough.
6) As I said in my earlier msg, I think the doc/ stuff should get moved
to the doc/ figure, not expanded here.
. . bib/ Databases of common interest
. . bst/ Style files
Add `\BibTeX' to the beginning of these descriptions.
. . base/ Base distribution
(e.g., plain.mf)
. . misc/ Single-file packages
(e.g., modes.mf)
. . base/ Base distribution
(e.g., plain.mp)
. . misc/ Single-file packages
Any e.g.?
. . <package>/ Name of a package (for future use)
Can delete `for future use' here, I think.
. source/ Program source code
... by name (e.g., web2c, latex)
. . . base/ Base distribution for format
\replaceable{format} (optional if single file)
We recognzie that adoption of \acronym{TDS} will not be immediate or
universal.
recognize
some adventurous {\TeX} administrators will set up
\acronym{TDS}-compliant trees,
delete `adventurous' -- let's be hopeful.
This ``Beta Testing'' will flush out problems that were not obvious
``Beta Testing'' -> testing
[weird capitalization, anyway]
conservative {\TeX} administrators will begin to adopt the \acronym{TDS}.
even conservative ...
should peruse CTAN:??? or send email to \literal{tdsr@cfcl.com}.
??? indeed.
\section{References to Files and Documents}
How about just `Related References'.
This appendix is for pointers to files and other documents we mention
in this draft.
... related files and other documents.
[I want to include things we don't mention elsewhere, too.]
We should say here what CTAN: means.
Let's point to ftp.math.utah.edu:pub/tex/bib for a huge bibtex
collection (both db's and styles).
\citetitle{Filenames for {\TeX} fonts} can be found in the CTAN archives
in the \path|info/fontname| directory.
How about doc/fontname instead? Since we use info/ to mean something else.
Also: ``This distribution includes recommended supplier and typeface names''.
A complete set of {\protect\MF} modes is available from
CTAN:\path|fonts/modes/modes.mf|.
This distirbution includes recommended mode names.
TUG '94). All discussions were held by email. (The discussions
are archived on ???.)
shsu.edu:[twg.tds]
I think this reference should be in the references section.
Eplain, \path|modes.mf|, et. al.
No period after `et'.
MacKay, Pierre (\literal{mackay@cs.washington.edu}). Professor, Dept.
Missing \ after `Dept.'. [You're getting an end-of-sentence space.]
Work}. (\acronym{TDS} Committee Chair).
Period inside the ) or not at all?
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 08:37:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 1995 09:36:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504151336.AA01777@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: mft files
> Traditionally we've put mft files into tex/mft, but with the explosion
> of top-level directories, maybe they should go there?
Aren't they documentation of a sort?
No, they are input files read by the mft program.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 08:42:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 1995 09:41:38 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504151341.AA01786@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Toward a public draft ... 0.71
- The file format appendix. Maybe the public draft will initially
go out without it?
I forgot we planning on this.
I suggest we drop it for now.
Does it really belong in the TDS document, anyway?
- Is the copyright notice reasonable for this document?
Seemed ok to me.
Does TUG approve of being the copyright holder? Do they approve of the
"permission to reproduce" statement?
Since we are a TUG committee, I think this all comes out in the wash.
Barbara, is there anything to do?
(I suppose it'll have to be
"copyright TUG, portions copyright ORA" when we add the extension
appendix).
As long as the permissions don't change.
- Logos and fonts. Does the document use the right ones now?
I didn't notice any errors this time around.
- The ltxguide.sty style does a crummy job on figure titles (I think
prepending "Figure <figure number>" would be a good idea; especially
now that they float).
It absolutely has to say Figure x.y if we're going to refer to them that way.
And I don't think they should float, as I said.
Am I missing anything?
I responded at length yesterday ...
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 09:16:56 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504151416.QAA20121@spock.iti.informatik.th-darmstadt.de>
Subject: Re: mft files
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Apr 1995 16:16:14 +0200 (MESZ)
Content-Type: text
You wrote:
>
> We don't mention mft files.
> Should we?
>
> Traditionally we've put mft files into tex/mft, but with the explosion
> of top-level directories, maybe they should go there?
As MFT is just (yet another) utility, texmf/mft/ is the correct place,
isn't it?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 09:19:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504151418.QAA17058@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Toward a public draft ... 0.71
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Apr 1995 16:18:55 +0200 (MESZ)
Content-Type: text
Rich wrote:
>
> BTW (and I *know* this is late in the game to mention it), I'm beginning
> to get concerned about the fact that there doesn't seem to be any way
> to separate out OS-specific versions of files, other than in the bin
> directory. How is a network server (or a CD-ROM) supposed to handle the
> need for varying formats of TeX-related files?
May you please elaborate a bit?
Which files (besides executables and FMT files) give the headache?
(FMT files go below texmf/<port-name>/.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 10:36:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 17:37:57 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151537.AA16997@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: mft files
Joachim wrote:
>>
>> We don't mention mft files.
>> Should we?
>>
>> Traditionally we've put mft files into tex/mft, but with the explosion
>> of top-level directories, maybe they should go there?
> As MFT is just (yet another) utility, texmf/mft/ is the correct place,
> isn't it?
I'd say this depends on where MFT searches for .mft style files. In the
Web2C implementation this is currently the TEXINPUTS paths, so they must
go somewhere below texmf/tex. Of course, it would be possible to put
them somewhere else, possibly below texmf/mf if that makes more sense.
But then, one might also introduce another search path environment
variable and a new top-level directory for three files just as well.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 10:44:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 17:44:37 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151544.AA17005@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: doc/
Karl wrote:
> The doc/ tree is still a mess. Ulrik, would you mind taking another look
> and trying to get something consistent out of it? Right now there is the
> tree in the complete TDS skeleton figure, the doc/ skeletong figure, and
> the text. All are inconsistent with each other. The TDS example figure
> seems more or less correct as far as it goes, but it doesn't go far
> enough.
I think I already commented on some of the inaccuracies in the doc tree
figure shortly after the last draft. I'm not really sure about what's
the best way to organize it either. In case of doubt, I'd personally
leave out the separate doc figure and just keep the TDS skeleton figure
more or less as it is now.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 10:44:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 17:44:37 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151544.AA17005@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: doc/
Karl wrote:
> The doc/ tree is still a mess. Ulrik, would you mind taking another look
> and trying to get something consistent out of it? Right now there is the
> tree in the complete TDS skeleton figure, the doc/ skeletong figure, and
> the text. All are inconsistent with each other. The TDS example figure
> seems more or less correct as far as it goes, but it doesn't go far
> enough.
I think I already commented on some of the inaccuracies in the doc tree
figure shortly after the last draft. I'm not really sure about what's
the best way to organize it either. In case of doubt, I'd personally
leave out the separate doc figure and just keep the TDS skeleton figure
more or less as it is now.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 10:46:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 15 Apr 1995 11:45:33 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
To: TWG-TDS@SHSU.edu
Message-ID: <797960733.631000.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re copyright notice and "permission to reproduce", i think they're
quite clear, and that's really what matters. i think it's just fine.
(the tug pubs committee has never objected to my judgment in matters
of this nature.)
one comment on abbreviations/logos -- if they're all caps, please
set them up so that end-of-sentence is handled properly. here are
a couple of examples from the tugboat styles:
\def\CTAN{{\SMC CTAN}\spacefactor1000 }
\def\TeX{T\kern-.1667em\lower.424ex\hbox{E}\kern-.125emX\spacefactor1000 }
i recommend this technique (affirmed by knuth) for TWG and TDS at least.
i'm boggled by the absence of figure numbers; especially 8.1 which
happens by sheer bad luck to fall right after the sentence introducing
the "martian" package.
re the full-page figures, karl thinks they shouldn't float. i'd like
to reinforce the other part of what he said if that's put into effect:
do, please, keep each one on its own separate page. i find this very
easy to comprehend, and, better, i can make a copy and stick it in
front of a sysadmin's nose and say "here it is, can we live with it
or not?"
karl did miss a few typos; i will try to send in a list soon, but
at the moment i'm just taking a few minutes out from unpacking boxes
and sorting/throwing out the accumulation of many years, having lost
over 30 linear feet of filing/shelf space and having been ordered
to have all boxes out of existence by monday-day-after-tomorrow.
(let me tell you, tossing some of this stuff breaks my heart. if
i can't keep it here, i will take home my bounty-hunter's edition
of the metafontbook, with the indexing terms in the upper right
corner of each page.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 11:00:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 18:01:00 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151601.AA17023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Norm wrote:
> The outstanding content issues are:
> - The documentation section. I've worked it over a little bit, and
> modified the figure again, but do we like it yet? If not, what do
> we need to do?
I'm not sure about it. I already commented on some of inaccuracies
earlier (e.g. `info' should be `generic', wrong indentation levels).
I also wonder if the format of the figure is really appropriate because
we might need more than one line for each directory if we want to list
individual files that might go there. Perhaps a more generic verbal
description might be more suitable here.
> - The about the committee appendix. If you want to be there, tell me
> NOW. I would like *everyone* to be on the list and I was going to
> be inclusive by default, but since some folks
> who are listening on the list explicitly wanted to be excluded, I
> decided it was safer to be exclusive by default. Stand up and be
> counted!
Vieth, Ulrik (\literal{vieth@thphy.uni-duesseldorf.de}), graduate student
in theoretical physics, maintainer of a local {\TeX} installation for
a few months, adapted {\MP} to work with \application{Web2C} when it
was released in early 1995, suggested inclusion of a chapter on {\MP}
1;1;0in the \acronym{TDS} draft.
> The outstanding formatting issues are:
>
> - Logos and fonts. Does the document use the right ones now?
I still think that the logo font should be used for the METAFONT logo.
For the MetaPost logo this depends, but if possible it should be used
as well, at least when the draft goes into print for TUGboat.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 11:00:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 18:01:00 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151601.AA17023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Norm wrote:
> The outstanding content issues are:
> - The documentation section. I've worked it over a little bit, and
> modified the figure again, but do we like it yet? If not, what do
> we need to do?
I'm not sure about it. I already commented on some of inaccuracies
earlier (e.g. `info' should be `generic', wrong indentation levels).
I also wonder if the format of the figure is really appropriate because
we might need more than one line for each directory if we want to list
individual files that might go there. Perhaps a more generic verbal
description might be more suitable here.
> - The about the committee appendix. If you want to be there, tell me
> NOW. I would like *everyone* to be on the list and I was going to
> be inclusive by default, but since some folks
> who are listening on the list explicitly wanted to be excluded, I
> decided it was safer to be exclusive by default. Stand up and be
> counted!
Vieth, Ulrik (\literal{vieth@thphy.uni-duesseldorf.de}), graduate student
in theoretical physics, maintainer of a local {\TeX} installation for
a few months, adapted {\MP} to work with \application{Web2C} when it
was released in early 1995, suggested inclusion of a chapter on {\MP}
1;1;0in the \acronym{TDS} draft.
> The outstanding formatting issues are:
>
> - Logos and fonts. Does the document use the right ones now?
I still think that the logo font should be used for the METAFONT logo.
For the MetaPost logo this depends, but if possible it should be used
as well, at least when the draft goes into print for TUGboat.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 11:40:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 09:39:54 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151639.AA07189@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Vicki Brown has moved from Taligent to Apple. Please amend her bio.
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 12:00:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 10:00:37 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151700.AA07271@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: OS-dependent files
JS> Which files (besides executables and FMT files) give the headache?
JS> (FMT files go below texmf/<port-name>/.)
Well, I'm afraid I'm not knowledgeable enough to answer this question
very specifically. Here's some hand-waving, however.
1. Any text (ASCII) file that must be read by a program will be
OS-dependent to the extent that the target OS's demand some
particular form of line termination (CR, LF, CR/LF, etc.)
2. I can't find my notes on the subject, but I recall someone on
this list telling me that not all of the binary files used by
TeX (etc) are machine-independent. Can someonhelp out here?
-r
================================================================================
From owner-twg-tds@shsu.edu Sat, 15 Apr 1995 12:20:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 15 Apr 95 10:19:57 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504151719.AA07296@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
KB> extensions => version numbers [I assume]
Please consider the filename "ABCDEFGH.IJK;1". "ABCDEFGH" is the basename,
"IJK" is the extension, and ";1" is the version number.
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 05:10:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 06:10:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161010.AA10127@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
KB> extensions => version numbers [I assume]
Please consider the filename "ABCDEFGH.IJK;1". "ABCDEFGH" is the basename,
"IJK" is the extension, and ";1" is the version number.
I understand that.
And so I doubt very much that when you do `ls' on a CD-ROM mounted on a
Sun, you get abcdefgh;1. Instead, you get abcdefgh.ijk. What it removes
is the version number, not the extension.
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 05:14:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 06:13:55 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161013.AA10138@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: OS-dependent files
1. Any text (ASCII) file that must be read by a program will be
OS-dependent to the extent that the target OS's demand some
particular form of line termination (CR, LF, CR/LF, etc.)
I thought most TeX ports accept either way. I know web2c does. Anyway,
we can't possibly duplicate every file in the tree just because of line
terminations. It will just have to be up to the distributor which format
to use. Perhaps the TDS should mention this as explicitly unstandardized.
2. I can't find my notes on the subject, but I recall someone on
this list telling me that not all of the binary files used by
TeX (etc) are machine-independent. Can someonhelp out here?
.fmt/.base files aren't, but they are already in the texmf/<port> directory.
(Actually, they're more implementation-dependent than system-dependent.)
All other files are. Well, modulo blocking issues on VMS, but again, I
can't see duplicating the whole tree just for that.
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 05:16:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 06:16:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161016.AA10147@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
I still think that the logo font should be used for the METAFONT logo.
It causes too much headache in the formatting, and which version of the
font to use, etc., etc. I'm all for leaving it the way it is.
earlier (e.g. `info' should be `generic', wrong indentation levels).
Where did generic/ come from? I don't remember that.
How about using general/misc and general/<multifile-doc>, analogous to
everything else?
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 05:18:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 06:18:22 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161018.AA10151@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
re the full-page figures, karl thinks they shouldn't float. i'd like
to reinforce the other part of what he said if that's put into effect:
do, please, keep each one on its own separate page. i find this very
I agree with Barbara.
I still think they shouldn't float, either. It just confuses things.
We don't really need to conserve that extra half-page or so.
karl did miss a few typos; i will try to send in a list soon, but
I didn't mention some typos because they were in text that I wanted to
rewrite anyway :-).
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 05:21:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 06:21:08 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161021.AA10162@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: mft files
them somewhere else, possibly below texmf/mf if that makes more sense.
texmf/mf doesn't make sense, or I would have been storing them there
along. mft files have a lot more to do with tex than with mf.
As you imply, the top-level directory for the three files seems like
overkill. Can we say texmf/tex/mft instead? Or is it better to swallow
the pain?
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 06:25:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 1995 07:23:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161123.AA10451@terminus.cs.umb.edu>
To: csg0070@queens-belfast.ac.uk, kahn@math.toronto.edu, dlaser@sable.ox.ac.uk, Andreas_Schrell@rs.maus.de, Robin.Fairbairns@cl.cam.ac.uk, beebe@csc-sun.math.utah.edu, damian.cugley@prg.ox.ac.uk, rokicki@cs.stanford.edu, te@informatik.uni-hannover.de, abrahams@acm.org
CC: twg-tds@shsu.edu
Subject: fontname 1.91
Another new version of the fontname document is on
ftp.cs.umb.edu:private/tex/fontname-1.91.tar.gz. I've done some major
rewriting and reorganization. As usual, all comments are welcome.
I'm cc-ing this to the tds list because the tds does refer to this now,
so if any of you folks are interested, you should know about it.
One plaintive request -- really really appreciate it if someone could
get interested in writing a script to generate names for the fonts in
monotype.more which use already-assigned typefaces. (I'm willing to let
the rest be unassigned until someone asks, since there are so many.) I
suppose I will do this myself before the real announcement of fontname 2
if no one else does, but ...
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 10:50:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504161550.RAA15226@spock.iti.informatik.th-darmstadt.de>
Subject: Re: mft files
To: TWG-TDS@SHSU.edu
Date: Sun, 16 Apr 1995 17:50:16 +0200 (MESZ)
Content-Type: text
You wrote:
>
> As you imply, the top-level directory for the three files seems like
> overkill. Can we say texmf/tex/mft instead?
I don't care. But: If we do so, TDS must name this exception, as `mft'
is not a format-related directory. (texmf/mft/ wouldn't need any
mentioning, as it's subsumed under texmf/<utility>/.)
Btw, I don't buy the TEXINPUTS argument from Ulrik. One simply needs
for MFT an other (default) value than for TeX. But that's the same
with BibTeX & some other tools, too. But, as said above, it's not
really a matter of interest for me.
Joachim
PS: I've just started to check the macros; had been away the last two
weeks.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sun, 16 Apr 1995 13:23:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 16 Apr 95 11:22:59 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504161822.AA10910@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
Sorry, KB, I blithely assumed that you had been in error. Silly me!
There is an egregious error in the text, and you rightly spotted it.
Mea Maxima etc.
-r
P.S. If KB is also right about the level of OS-compatibility problems,
it may be largely a non-issue. I think I'll try to use CR/LF
for all text files on TeXcetera, possibly enforce VMS-style
blocking, and let it go at that. Would someone please send me a
specific description of what has to be done to make binary files
VMS-readable?
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Apr 1995 07:07:13 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 notes
Date: Wed, 19 Apr 1995 13:03:22 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:155050:950419120332"@cl.cam.ac.uk>
Rich asks about CTAN and TDS registry; i'd be inclined to say it will
got at the top level, in /tex-archive/tds, along with anything else
related to this game. we want it to be as high profile as possible.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 19 Apr 1995 12:56:11 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504191755.TAA24210@spice.iti.informatik.th-darmstadt.de>
Subject: RFC: Your opinion on layout issues
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 19 Apr 1995 19:55:33 +0200 (MESZ)
Content-Type: text
I have worked a bit on the TDS macros.
Please fetch the file
ftp://ftp.th-darmstadt.de/pub/tex/TDS/misc/tds.tar.gz ,
look at the DVI files therein and tell me your opinion.
In particular:
-- The table with the summary has prompted some critics. I tried to
improve it. Two (subsequent) transformations:
tst-table-quad.dvi no horizontal space before & after the
columns; only one quad in between; dir
levels are only indented by one quad
tst-table-dots.dvi dir level indentation is shown by dots,
just like in the input.
Compare them with the one in the last draft. Which do you like
best?
-- I made a document class out of all these macros, tdsguide.cls.
Two options: `draft' tells that this is still a draft; `mflogo'
tells to use the logo font.
Options may be specified in a tdsguide.cfg file. In particular,
one can specify `mflogo' there, as is done for the tds-*.dvi files
in the archive. I.e., these files demand current version of logo
fonts. Norm, don't be shocked. Just rename tdsguide.cfg, LaTeX
again, and it will be typeset in Roman, like in draft 0.71.
I expect the distributed version to use Roman, but personal
versions made on up-to-date TeX installations can use logos.
-- Layout: First, some small changes:
tds-headline+dbend.dvi
A headline that shows the current revision number. (I had so many
printouts at home and missed that in the past.)
`draft' option puts `DRAFT!' into headline as well.
How about the nice dangerous bend on the first page?
Btw, these two sentences are created by `draft' option now, not be
putting them explicitly in the text.
-- Then, more rearrangements:
tds-uniform+sf.dvi
More uniform vertical spacing.
Sans-serif head lines.
So, what's your preferred layout? Original-One (tm), slight changes,
or the last one?
Oh yes, and the TODO file tells about more stuff I would like to know:
-- should the appendices start on a new page?
all of them? only the first?
-- centered TDS summaries? or left, as they are now?
Hope to hear from you,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Apr 1995 18:06:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 21 Apr 95 12:14:26 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504211014.AA20822@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
Joachim wrote:
> I have worked a bit on the TDS macros.
> Please fetch the file
> ftp://ftp.th-darmstadt.de/pub/tex/TDS/misc/tds.tar.gz ,
> look at the DVI files therein and tell me your opinion.
Nice work!
> In particular:
>
> -- The table with the summary has prompted some critics. I tried to
> improve it. Two (subsequent) transformations:
>
> tst-table-quad.dvi no horizontal space before & after the
> columns; only one quad in between; dir
> levels are only indented by one quad
> tst-table-dots.dvi dir level indentation is shown by dots,
> just like in the input.
>
> Compare them with the one in the last draft. Which do you like
> best?
One quad indentation looks much better than two quad, especially in
the case of directory names shorter than four letters (e.g. doc, tex).
Using dots to indicate the dir levels also seems to make it easier
to read.
> -- I made a document class out of all these macros, tdsguide.cls.
> Two options: `draft' tells that this is still a draft; `mflogo'
> tells to use the logo font.
> I expect the distributed version to use Roman, but personal
> versions made on up-to-date TeX installations can use logos.
Also a very good idea. However I have few specific comments on the
macros in tdsguide.cls.
> \RequirePackage{alltt} % alltt environment
> \RequirePackage{path} % file names & email addresses
The versions of alltt.sty and path.sty in your directory are not
the latest. They are probably the same as mirrored from Norm.
In particular, there is a 2e version of alltt.sty in latex/base
and a more recent version of path.sty (3.04) in eplain-2.6.
> \RequirePackage{mflogo} % MF & MP logos (but see below)
This is troublesome, because you can't rely on that it is available
everywhere unless you put it up with the other .sty files. (And please
use the updated version (with spacefactor correction) I provided here
some time ago. I still didn't make it to update the version on CTAN,
in particular rewriting the documentation.)
> \def\replaceable#1{\texttt{\textsl{\selectfont #1}}}
There is a spurious \selectfont, which doesn't do any harm however.
> \def\dir#1{\texttt{#1}}
> \def\ext#1{\texttt{#1}}
Are they used anywhere? If not, they should vanish, so that no-one
would ever consider using them again in place of \path|...|.
> \def\AmS
cf. the definition from amsdtx.cls:
\def\AmS{{\protect\usefont{OMS}{cmsy}{m}{n}%
A\kern-.1667em\lower.5ex\hbox{M}\kern-.125emS}}
> % Use a small caps fake for BibTeX's `ib'. This way we can typeset it
> % in bold face or sans-serif, too. The code is copied from the LaTeX
> % logo definition, from ltlogos.dtx.
>
> \DeclareRobustCommand\tds@smsize
What about using this for \acroynm?
Now back to the rest of your suggestions:
> -- Layout: First, some small changes:
>
> tds-headline+dbend.dvi
>
> A headline that shows the current revision number. (I had so many
> printouts at home and missed that in the past.)
>
> `draft' option puts `DRAFT!' into headline as well.
Good idea, but I don't see the need for putting `DRAFT!' in the headline
twice. Putting it there once would be enough, I think.
> How about the nice dangerous bend on the first page?
It's cute when used occasionally. But I'm afraid it might get silly
when used too often, e.g. in every document that uses this draft option.
> -- Then, more rearrangements:
>
> tds-uniform+sf.dvi
>
> More uniform vertical spacing.
The spacing around list environments is much better, but I'd like to see
a little more whitespace between paragraphs. I think this is too narrow
in your layout. And then there's no whitespace after the introductory
sentence in the overview figure. I'd consider that a bug of your layout.
> Sans-serif head lines.
Not sure. To mee they look too thin, especially in subsubsections (see
`Valid font bitmaps', starting with one quad indentation in normalsize
and without a number). Have you tried sans-serif demibold condensed?
> So, what's your preferred layout? Original-One (tm), slight changes,
> or the last one?
Not quite the last one. More uniform spacing: yes, sans-serif: not sure!
> Oh yes, and the TODO file tells about more stuff I would like to know:
>
> -- should the appendices start on a new page?
> all of them? only the first?
Probably the first one only, if any at all. Perhaps it would be better
to flush pages before full-page figures, so that the next section won't
start before the figure is output, independently of whether they appear
in the main matter or in the appendix.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Apr 1995 23:31:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Apr 1995 14:58:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504201858.AA02879@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RFC: Your opinion on layout issues
Joachim, thanks for doing this work.
About the table. Out of three choices:
1) qquad indentation (last draft)
2) quad indentation (tst-table-quad)
3) dot indentation (tst-table-dots)
I much prefer #2, after looking at them all side-by-side.
Also, no matter which style of indentation is used, I still believe that
(1) the top-level `texmf' should be moved into the caption, thereby
moving everything else to the left by one level; and
(2) the doc/ part of the summary table should be a single line:
doc see table doc-table
instead of trying to spell anything out here.
I will work on the doc-table and corresponding text
I think it's important to include it.
On the other changes:
A headline that shows the current revision number. (I had so many
printouts at home and missed that in the past.)
Good.
`draft' option puts `DRAFT!' into headline as well.
Good, but please, no exclamation points. I get distracted easily. Just
say `draft TDS version 0.71', centered? (I'm not crazy about the small
caps, either, would prefer plain roman. But whatever.) In the
non-draft version, it can say `TDS version 1.0'.
How about the nice dangerous bend on the first page?
Good :-).
BTW, in the permission statement following, I think `modifications' should
be `modification'. Norm, are you listening?
So, what's your preferred layout? Original-One (tm), slight changes,
or the last one?
The last one. I especially like the uniform (and smaller) vertical spaces.
The sans serif I'm not quite so sure about, but I think I like it.
(I only looked at page three, by the way.)
I say do the next draft in the new style, and see how it goes.
-- should the appendices start on a new page?
all of them? only the first?
None of them, IMHO. Nothing else starts on a new page, and I don't see
any reason to make it so.
-- centered TDS summaries? or left, as they are now?
Left, as they are now, IMHO.
================================================================================
From owner-twg-tds@shsu.edu Fri, 21 Apr 1995 23:31:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Apr 1995 19:09:36 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504202309.AA11673@claude.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: doc table
Well, here's my attempt at the doc/ tree. I got rid of the doc/ level itself.
Norm, ready to do another (maybe the last -- ha!) draft?
help/ meta-information
. ctan/ info about CTAN sites, \path|TeX-index|, etc.
. faq/ FAQs of \path|comp.text.tex|, etc.
general/ across programs, generalities
. componen/ \citetitle{Components of {\TeX}}
. errata/ \path|errata.\{tex,dvi\}|, \path|errata[1-8].tex|
. lkurz/ xx what is this? xx
. lshort/ xx and this? xx
<format>/ name of a format (\path|latex| example follows)
. base/ for the base format
. misc/ for single-file packages
. <package>/ for <package> (\path|amslatex|, etc.)
latex/
. base/ \path|ltnews*.\{tex,dvi\}|, \path|*guide.\{tex,dvi\}|, etc.
. . graphics/ \path|grfguide.\{tex,ps\}|
generic/ for non-format specific {\TeX} packages
. . german/ \path|germdoc.\{tex,dvi\}|
. . babel/
<program>/ {\TeX} applications, by name (examples follow)
tex/ \path|texbook.tex|, \path|gentle.tex|, etc.
metafont/ \path|mfbook.tex|, \path|metafont-for-beginners|, etc.
metapost/ \path|mpman.\{dvi,ps\}|, \path|manfig.mp|, etc.
ams/
. amsfonts/ \path|amsfonts.faq|, \path|amfndoc|.\{tex,dvi\},
. amstex/ amsguide.\{tex,dvi\}, joyerr.tex,
. amslatex/ amslatex.faq, amsldoc.\{tex,dvi\},
web/ \path|webman.\{tex,dvi\}|, \path|cwebman.\{tex,dvi\}|
fontname/ \citetitle{Filenames for {\TeX} fonts}
kpathsea/
fonts/
. oldgerm/ corkpapr.\{tex,dvi\}
. malvern/
man/ Unix-style manual pages
html/ html files
info/ GNU info files, made from {\TeXinfo} sources
================================================================================
From owner-twg-tds@shsu.edu Sat, 22 Apr 1995 08:37:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 22 Apr 1995 09:37:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504221337.AA25221@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
and a more recent version of path.sty (3.04) in eplain-2.6.
The change wasn't significant (adding a hook variable or something), as
I recall, so don't worry about it unless you want to.
What about using this for \acroynm?
What about renaming \acronym to \abbreviation, if we're gonna be finicky :-)?
Using dots to indicate the dir levels also seems to make it easier
to read.
... but I'd like to see a little more whitespace between
paragraphs. I think this is too narrow
... sans-serif: not sure!
Joachim, I bet all of us will be happy with whatever you decide on these
formatting details.
Perhaps it would be better
to flush pages before full-page figures,
I absolutely agree (having already made a nuisance of myself with this
same suggestion :-).
================================================================================
From owner-twg-tds@shsu.edu Sun, 23 Apr 1995 09:45:56 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504231438.QAA13813@spock.iti.informatik.th-darmstadt.de>
Subject: Re: RFC: Your opinion on layout issues
To: TWG-TDS@SHSU.edu
Date: Sun, 23 Apr 1995 16:38:30 +0200 (MESZ)
Content-Type: text
Just an ack that I received the layout comments. If any of you
received error messages from our mail system, it's OK again. (Some
boozo here got 50 MB of email and overflowed our mail queue.)
And since I'm at it:
Karl wrote:
> Perhaps it would be better
> to flush pages before full-page figures,
>
> I absolutely agree (having already made a nuisance of myself with this
> same suggestion :-).
I have to say I don't understand that suggestion. Do you say we
should not flow the table, i.e., drop the figure element at all?
(Actually, that has nothing to do at all with macros, it's a matter
of markup.)
Btw, I'll wait if more comments drop in before I start to change
macros again... :-)
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, 24 Apr 1995 05:39:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 24 Apr 1995 06:38:45 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504241038.AA24645@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
I have to say I don't understand that suggestion. Do you say we
should not flow the table, i.e., drop the figure element at all?
Now I'm confused.
Here's what I (and Ulrik, I'm pretty) was suggesting:
Right now, the text around the summary figure looks like this. On page 16:
10 Summary
Figure 10.1 presents a graphical view of the TDS.
A Implementation Issues
We believe ... for TeX.
---------- page break --------
On page 17 is Figure 10.1.
What I want is for the `appendix A' text to appear *after* the figure,
not before, even if that means page 16 ends short. (I find that hard to
read, and don't see any need for the confusion in a document this short.)
Put another way, I don't want the figures to float.
Put another way, I want the figures to be \vbox{...} rather
than \midinsert{...}. (Yes, yes, I know, this is latex, not tex, but
you get the idea.)
Does that make more sense?
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Apr 1995 05:52:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 24 Apr 95 11:51:46 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504241051.AA06902@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
Karl> Here's what I (and Ulrik, I'm pretty) was suggesting:
I wondered what you looked like:-)
Karl> Put another way, I want the figures to be \vbox{...} rather
Karl> than \midinsert{...}. (Yes, yes, I know, this is latex, not tex, but
Karl> you get the idea.)
Alternatively modify the defn of \appendix (to add \clearpage) to stop
floats drifting out of the body of the document. (This has the same
effect in this particular case, and I agree it would be better if the
table did not drift into the appendices.)
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 24 Apr 1995 05:53:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504241053.MAA22431@spice.iti.informatik.th-darmstadt.de>
Subject: Re: RFC: Your opinion on layout issues
To: TWG-TDS@SHSU.edu
Date: Mon, 24 Apr 1995 12:53:13 +0200 (MESZ)
Content-Type: text
You wrote:
>
> I have to say I don't understand that suggestion. Do you say we
> should not flow the table, i.e., drop the figure element at all?
>
> Put another way, I don't want the figures to float.
>
> Put another way, I want the figures to be \vbox{...} rather
> than \midinsert{...}. (Yes, yes, I know, this is latex, not tex, but
> you get the idea.)
>
> Does that make more sense?
Yes, that's what I meant with ``drop the figure element.''
Since you, Ulrik, and barbara seem to want that kind of behaviour,
I'd say we should go for it. I'll implement a new environment
(`nofloat-figure' or such -- does such a beast already exist
somewhere?).
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, 24 Apr 1995 06:34:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 24 Apr 95 13:35:05 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504241135.AA21917@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
> Since you, Ulrik, and barbara seem to want that kind of behaviour,
> I'd say we should go for it. I'll implement a new environment
> (`nofloat-figure' or such -- does such a beast already exist
> somewhere?).
I think FoilTeX for LaTeX2e implements figures as non-floating figures.
But maybe there might be some other alternatives (float.sty, perhaps).
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 17:01:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 17:56:43 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252156.RAA11654@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.71 notes
Reply-To: TWG-TDS@SHSU.edu
> Page 1:
>
> Several forms of this document are available from the directory:
>
> ftp://jasper.ora.com/pub/twg-tds
>
> DVI The DVI file for this document is available as tds.dvi.
> LaTeX The LaTeX (2e) sources are available as tds.tex.
> PostScript The PostScript for this document is available as tds.ps.
> Texinfo The Texinfo sources are available as tds.texi.
>
> HTML This document is available on the WorldWideWeb as:
>
> http://jasper.ora.com/pub/twg-tds/tds.htm
I agree, these should line up, but it's a style issue. Since we haven't
picked a final style file yet, I'm not going to worry about it now...
> page 5, par. 6:
>
> ... left to the implmentor ...
> ... left to the implementor ...
Check.
> page 8, footnote:
>
> The name spsun413 is one possible (ISO-9660 compliant) abbreviation
> for SPARC SunOS 4.1.3.
Ok.
> page 9, footnote:
>
> It's really tacky to spread a footnote onto two pages! I see one
> place (the end of the generic bullet item) where a line could
> probebly be trimmed. Find another and you're home free!
I tried, we'll see if I succeeded...
> page 17 (for the Nth time!):
>
> The expression "e.g." does not require more than one example. It
> particularly does not need to be closed with ", etc." Please try:
>
> Package (e.g., graphics) documentation
> Name of a font supplier (e.g., ams)
> TeX applications, by name (e.g., dvips)
> Multi-file formats (e.g., graphics)
> Multi-file packages (e.g., babel)
The N+1th time's a charm.
> Page 19:
>
> Can SPQR or someone please assign a spot in the CTAN for the TDS
> Registry, so we can kill off the "???"? Also, I wonder about the
> propriety of tying the registry email address to a single, profit-
> making enterprise. Can we install a mirror account, perhaps at
> SHSU, for this purpose?
Sebastian, what say you?
> page 21, item 3:
>
> ... editor of ...
> ... Editor of ...
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 17:02:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 17:47:43 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252147.RAA11517@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: doc/
Reply-To: TWG-TDS@SHSU.edu
> Independent of what the final contents of doc/ are, I suggest the
> complete TDS skeleton figure just have a single line
> doc/ see figure x.y.
>
> since doc/ is really irrelevant to our main work, and people will get
> freaked when they see html/texinfo/etc./etc. there.
Agreed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 17:03:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 17:46:57 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252146.RAA11509@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu, damian.cugley@prg.ox.ac.uk
Subject: official tds abbreviation
Reply-To: TWG-TDS@SHSU.edu
> Damian mentioned that it would be helpful to have an official
> abbreviation for the TDS report. I think all that may be needed is to
> put (TDS) into the title, i.e.,
> TeX Directory Structure (TDS) 1.0
>
> If that doesn't suit, I suppose it could go in the first paragraph or
> something.
>
> Then people won't hesitate about referring to it as TDS 1.0 or whatever.
Unfortunately, the title is actually "A Directory Structure for TeX Files"
so "TDS" doesn't really work there. I thought about rewording the title
to have "TeX Directory Structure (TDS)" in it, but didn't like any of
the arrangements.
Since the document will be distributed as tds.tex, and it does use "tds"
throughout, I don't think there will be any confusion.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 17:03:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 17:46:57 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252146.RAA11509@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu, damian.cugley@prg.ox.ac.uk
Subject: official tds abbreviation
Reply-To: TWG-TDS@SHSU.edu
> Damian mentioned that it would be helpful to have an official
> abbreviation for the TDS report. I think all that may be needed is to
> put (TDS) into the title, i.e.,
> TeX Directory Structure (TDS) 1.0
>
> If that doesn't suit, I suppose it could go in the first paragraph or
> something.
>
> Then people won't hesitate about referring to it as TDS 1.0 or whatever.
Unfortunately, the title is actually "A Directory Structure for TeX Files"
so "TDS" doesn't really work there. I thought about rewording the title
to have "TeX Directory Structure (TDS)" in it, but didn't like any of
the arrangements.
Since the document will be distributed as tds.tex, and it does use "tds"
throughout, I don't think there will be any confusion.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 17:57:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 18:52:30 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252252.SAA12648@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.71 comments
Reply-To: TWG-TDS@SHSU.edu
> \author{The TUG Working Group on a {\TeX} Directory Structure}
>
> Here I would add ``(TWG-TDS)'', so people see our two common
> abbreviations up front. On a separate line, if you can coerce latex into it.
> (I like the new front page a lot!)
Check.
> \emphasis{This is a draft specification. This is only a draft.}
>
> This is a draft. It is only a draft. In the event of a real release, you
> would be informed ...
> :-). (No, I'm not suggesting you change the text.) (Non-American folks
> probably won't get this; never mind, it's not worth explaining.)
My favorite example along these lines is:
This is a test. This is only a test. Had this been a real emergency,
we would have fled in terror and you would not have been informed.
(For those of you who don't understand the joke, American TV and radio
stations issue periodic tests of "the emergency broadcast system".
These tests always begin with a long, annoying tone (beeeeeeeeeep)
followed by an announcer who reads "This is a test of the emergency
broadcast system, this is only a test. In the event of a real
emergency...". The EBS is used to warn of impending natural disasters
like tornados, but we all know it started during the cold war in case
we were 30 minutes away from the end of the world.)
> The LaTeX (2e) sources are available from
>
> \LaTeX
Check.
> \path|ftp://jasper.ora.com/pub/twg-tds/tds.tex|.
>
> I assume jasper will be replaced by CTAN in the real release?
> Also, it's kind of confusing because the damn path breaks in a different
> place every time. I wonder if it would be simpler to say:
>
> This document is available in several formats from from jasper.ora.com:
>
> \path|ftp://jasper.ora.com/pub/twg-tds/tds.tex| LaTeX (2e) source.
> \path|ftp://jasper.ora.com/pub/twg-tds/tds.dvi| DVI
> ...
> \path|http://jasper.ora.com/pub/twg-tds/tds.htm| HTML
>
> A single line each, is the key.
> And don't forget the .info format.
Yes, it probably would be better. And someone from CTAN should tell me
what the real path is going to be ;-)
> install it. This has resulted in hundreds of slightly (or not so
> slightly) different installed configurations.
>
> Suggest deleting `slightly (or not so slightly)'. Not in a standard.
Check.
> directory structure for macros, fonts, and other such
>
> TeX directory structure (TDS) for ...
Check.
> local system uses the {\TeX} Directory Structure (\acronym{TDS}) recommended here.
>
> Can then delete the `(\acronym{TDS})' here.
Check.
> a nightmare: it is impossible to determine what files are used by
>
> difficult: ...
Check.
> which formats, what files need to be updated when a new release is
>
> formats => packages [for consistency with all other cases]
Check.
> which formats, what files need to be updated when a new release is
>
> release => version
Check.
> more macro packages happen to have input files with the same name.
>
> Delete `macro'. We're using `package' in a general sense here.
Check.
> Therefore, the TWG felt each package and typeface should be in a
>
> Delete `and typeface'.
>
> packages and typefaces a site may wish to install. Aside from
>
> Delete `and typefaces'.
Check.
> Also, installing or removing a new package would mean
>
> Also, if all directories are explicitly listed, installing ...
Check.
> On systems without some form of runtime configuration,
>
> some => any
Check.
> As a result, the TWG concluded that a comprehensive \acronym{TDS} required
> that implementations of {\TeX} must support some form of implicit subdirectory
> searching. In other words, it must be possible to specify that {\TeX},
>
> ... required implicit subdirectory searching. That is, it must ...
>
> The TWG recognizes that subdirectory searching places an extra burden
> ...
> database, performance is irrelevant: the file won't be found at all.)
>
> I think this entire paragraph should be moved as-is to B.2 (better way
> for fonts). It's just discussion, not really part of the spec.
Ok.
> As a consequence of the search strategy outlined above, the presence
> ...
> respective subtrees in the desired search order.
>
> Note, also, that the \acronym{TDS} does not specify the order in which
> ...
> differently on different systems.
>
> These two paragraphs are saying the same thing in two different
> ways. Here's my consolidation:
>
> The \acronym{TDS} does not specify the order in which subdirectories are
> descended. It follows that two identically named files in a search path
> leads to ambiguity. The \acronym{TDS} does not define which one is
> found. In order to resolve this ambiguity, a search path must be
> specified that lists the respective subtrees in the desired search
> order.
Check.
> Among systems that support subdirectory searching, there are several
> [...]
> interoperability wherever possible.
>
> How about simply: The TDS does not specify a syntax for specifying
> recursive searching, but we encourage implementors to provide
> interoperability wherever possible. See A.3 for a list.
> [Then make a new section A.3 that lists extant subdir searching syntaxes
> -- I seem to recall such a thing being posted earlier.]
Check.
> Having accepted that subdirectory searching is necessary, the \acronym{TWG}
>
> Having accepted the necessity for subdirectory searching, ...
Ok.
> The other constraints arise because it must be possible to implement
>
> These other ... possible to use
Check.
> The \acronym{TWG} found that the most constraining
> environment was the {\acronym{ISO}-9660} \acronym{CD-ROM} format.
> The specifications of this environment are detailed below.
>
> I would delete this (in concert with other changes below).
Ok.
>
> A special note about filenames: many, but not all, operating systems
> ...
> the space required for all the files.
>
> How about a subsection `Alphabetic case in filenames' or some such for
> these two paragraphs.
Ok, but then what do we call the section that starts below these two
paragraphs?
> One use of the \acronym{TDS} will be the creation of mountable generic
>
> In particular, one use ...
Well, if we start a new section here, I think "In particular" doesn't
work very well.
> Filenames may have extensions of up to three characters.
>
> may not exceed three
Check.
> Names and extensions may \emphasis{only} be made up of the
> character set \literal{A}--\literal{Z},
> \literal{0}--\literal{9}, and underscore.
>
> ... may consist of \emph{only} the characters A-Z, 0-9, and _ (underscore).
Check.
> Note that any alphabetic characters must be in uppercase.
Check.
> (e.g., \path|FILENAME.EXT;1|, \path|FILENAME.;32767|).
>
> This breaks confusingly, so I'd delete the second example name.
Ok.
> lowercase, removing extensions and trailing periods, etc.
>
> extensions => version numbers [I assume]
Check.
> directory \path|texmf|, but the actual name of the directory is
>
> ``\path|texmf|''
Check.
> (I wonder if \replaceable{texmf} would be better.)
I'll try it.
> {\TeX} system, (including {\protect\MF}, {\MP}, {\protect\BibTeX}, etc., not just {\TeX}
>
> delete comma before (
>
> itself) and it is
>
> add comma after )
Check.
> implementation (such as \path|emtex|, or \path|pctex|).
>
> (e.g., \path|emtex|)
> [why have two examples here? It just confuses things, given the next
> paragraph.]
Ok.
> Not all of these directories
> are needed at all sites.
>
> A site may omit any unneeded directories.
Check.
> the \acronym{TDS}. For example, Unix sites may wish to place all
>
> Unix \TeX administrators
Check.
> formats) in the \path|texmf| tree. This greatly simplifies
> administration, especially if the {\TeX} tree is maintained by someone
> other than the system administrator. Moreover, it allows the
>
> ... tree, especially if ...
Check.
> It may be convenient to store
> implementations (\application{em{\TeX}}, \application{PC{\TeX}},
> etc.) as well as utilities (\command{dvips},
> \command{MakeIndex}, etc.) in their own directories.
> Implementations can store configuration files, compiled {\TeX}
> format files, {\protect\MF} bases, {\MP} mems, pool files, \acronym{DLL}s, etc. in
> their own directory. Utilities can store configuration files,
> input files, etc. in their own directory.
>
> ... implementation-specific files (configuration files, compiled {\TeX}
> format files, {\protect\MF} bases, {\MP} mems, pool files,
> \acronym{DLL}s, etc.) and utility-specific files (configuration files,
> input files), in their own directories.
Check.
>
> The name \path|spsun413| is one possible
> abbreviation
> for \path|sparc-sunos-4.1.3| that could be made {\acronym{ISO}-9660}
> compliant.
>
> ... possible ISO 9660-compliant abbreviation for \path|sparc-sunos-4.1.3|.
Rich already suggested a replacement for this...
> sources (for example, \application{Web2C} sources could go in
>
> Delete `could'.
Check.
> Note that the \path|texmf| tree provides no explicit location
> for ``local'' files. Consequently, to avoid possible name collisions,
>
> The standard texmf tree ... files, since that would require duplicating
> the entire tree. Consquently,
> [it's for more reasons than name collisions]
Check.
> By providing a format directory, subdirectory searching can be
>
> subdirectory => path
Check.
> By adjusting the \systemitem{ENVIRONVAR}{TEXINPUTS} search
>
> TEXINPUTS => \TeX inputs (regular type)
> [we're not talking about the impl-specific environment variable here]
Check.
> path, it is still straightforward to use them as macro packages under
>
> Delete `still'.
Check.
> codes of Plain {\TeX} and does not rely on any particular format.
> \path|null.tex| is an example of a \emphasis{generic}
> {\TeX} file.
>
> format (e.g., \path|null.tex|).
> [the \emphasis is wrong, in any case]
Check.
> The \path|plain| directory is intended for files which are
> [...]
> \path|texnames.sty|, \path|null.tex|, etc.
>
> I don't think this paragraph should be part of the list, sinc eit's
> really an explanation leading up to the next paragraph.
Ok.
> It may be necessary to search other directories as well.
>
> Other directoried may be searched as well.
Check.
> are examples of \replaceable{packages}.
>
> packages => package
> [you don't add the `s' in any other section]
Check.
> \replaceable{packages} as described in this document are
> \emphasis{not} {\LaTeXe} packages, even though there exist {\LaTeX}
> packages with the names listed above. {\LaTeX} packages are style files
> that add more macro code to document classes. \acronym{TDS} packages are
> sets of files distributed, installed, and maintained as
> units.
>
> I think this should go in the conventions section.
Ok.
> in the \replaceable{format} directory. For example,
>
> directory, instead of `format/base'. For ...
Check.
> Like macros, fonts need to be stored in a hierarchical structure in order to
>
> As with macros, the TDS stores fonts in ...
Check.
> \subsection{Font Sources}
>
> I don't think this should be a subsection.
> You talk about more than sources, and we don't break up the other
> sections. (Maybe we should.)
>
> Admittedly that means the other subsection (on bitmaps) is kind of
> hidden after all this text, but I see no alternative.
The argument from the copyeditor that I had review this was that no
section should have a single subsection...
> \path|monotype|, and \path|ams|, are
>
> Delete the comma after ams.
Ok.
> purpose: it designates fonts for which there are no licensing problems
> if/when they are redistributed.
>
> ... fonts which can be freely redistributed.
Check.
> Fonts with different device types (modes) are generally segregated
> into separate directories.
>
> Following common practice, the TDS segregates fonts with different
> device types (modes) into separate directories.
Check.
>
> \path|cmr10.pk| in the directory \path|dpi300|.
>
> the => a
Check.
> For {\PS} fonts rendered as bitmaps with the \command{ps2pk}
> program, the mode \path|ps2pk| shall be used.
> \command{gsftopk} is handled analogously.
>
> For PS fonts rendered as bitmaps by a program that does not distinguish
> between different output devices, the \replaceable{mode} name shall be
> that of the program (e.g., `ps2pk', `gsftopk').
Check.
> If \path|GF| files are also to be kept, they would fall in:
>
> GF files are stored in a parallel structure:
Ok.
> There was considerable discussion about how the disadvantages of this
> scheme could be minimized. One result of that discussion was the
>
> ... how to minimize the disadvantages of this scheme.
> [I still don't like the way this paragraph is worded -- for purposes of
> the std, the discussion is irrelevant, if you see what I mean.]
Ok, maybe someone'll suggest moving it in 0.72 ;-)
> information is \emphasis{already} in your \path|PK|
>
> No need to emphasize?
Nah.
> must be made to your local modes file and all \path|PK| files
> must be rebuilt.
>
> can be made to your local modes file and the PK files rebuilt.
Check.
> Most {\protect\MF} input files are fonts; however a few non-font input files do
>
> are fonts (see the previous section); however, a ...
Ok.
> The files used by {\iniMF} when building
> a new base also fall into this catagory.
>
> They do? cmbase.mf doesn't go here. I don't get it. Suggesting deleting.
> [Also, `category' is misspelled.]
Check.
> This includes files used by
> {\iniMF} when dumping base files
> containing preloaded macro definitions.
>
> Again, suggest deleting.
Check.
> itself and the canonical example \path|story.tex|,
> from \citetitle{The {\TeX}book}.
>
> [this is out of order, sorry]
> You don't say `from the mfbook' for io.mf, so I'd delete `from the
> texbook' here. They can get it other ways besides typing it in ...
Ok.
> {\MP} utility programs.
> These files include things like a font map, a character adjustment table,
>
> programs, including a font map, ...
> [``things like''? surely you jest :-)]
Yeah, probably. ;-)
> {\protect\BibTeX} databases of common interest shall be stored in
> \path|texmf/bibtex/bib|.
>
> databases of common interest => database files
> [you don't say `of common interest' for anything else, so let's not do
> it here. We don't mean anything different.]
Ok.
> keep the documentation together and (2) make it straightforward for users to
> ... as straightforward as possible ...
> [let's be humble]
Ok.
> Joachim Schrod's \citetitle{Components of {\TeX}},
>
> I thought components was multiple files.
> Anyway, it seems a shame to use up general/ for single-file
> docs, when we call it misc/ everywhere else. Maybe general/errata,
> general/misc, etc, general/componen, etc.? Ulrik, where are you :-)?
I'm leaving the doc stuff till I've read the rest of my email...
> See \xref{Figure 8.1}.
>
> Is it possible to make this come out inline, right here, with nothing
> following? (Filling out the current page with blank space if necessary.)
> I find the floating figure pretty confusing, both here and when I'm
> reading the next section.
I'll work on the floating stuff...
> \begin{figure}{An example of \acronym{TDS} documentation}
>
> Rewrite of caption: A skeleton of the TDS example tree under texmf/doc.
Ok.
> 1) The number `8.1' does not come out anywhere.
I know.
> 2) If you put doc/ in the caption, everything else can move over. I
> think that's just as clear, if not more so.
sounds good.
> 3) all directories should have a / after their names
Yeah, is this a formatting bug, they do in the source???
> 4) all filenames should be typewriter
Right! This still needs a lot of work.
> 5) help!
Yes.
> For example, a package for Martian language typesetting might be distributed
>
> ... typesetting that works with plain \TeX and \LaTeX ...
check.
> \xref{Figure 10.1} presents a graphical view of the \acronym{TDS}.
> \begin{figure}{A general example of \acronym{TDS} implementation}
>
> 1) Again, I'd like to see this table not float to a new page.
Yes.
> 2) I really really like this table. How about if we put it in chapter 1,
> as a bird's-eye view of what will follow?
Hmmm...
> 3) Rewrite of caption: A skeleton of the TDS texmf tree.
> (Then everything else can move over)
Ok.
> 4) I hate to say it, but I think all the one-line descriptions should
> start with lowercase (unless a proper noun, of course), since they're
> not sentences.
Oh, allright.
> 5) I would delete etc. in all cases. Saying `e.g.' is enough.
Been there, done that.
> 6) As I said in my earlier msg, I think the doc/ stuff should get moved
> to the doc/ figure, not expanded here.
Yes.
>
> . . bib/ Databases of common interest
> . . bst/ Style files
>
> Add `\BibTeX' to the beginning of these descriptions.
Ok.
>
> . . base/ Base distribution
>
> (e.g., plain.mf)
Ok.
> . . misc/ Single-file packages
>
> (e.g., modes.mf)
Ok.
> . . base/ Base distribution
>
> (e.g., plain.mp)
Ok.
> . . misc/ Single-file packages
>
> Any e.g.?
???
> . . <package>/ Name of a package (for future use)
>
> Can delete `for future use' here, I think.
Ok.
> . source/ Program source code
>
> ... by name (e.g., web2c, latex)
Ok
> . . . base/ Base distribution for format
>
> \replaceable{format} (optional if single file)
Ok.
> We recognzie that adoption of \acronym{TDS} will not be immediate or
> universal.
>
> recognize
Ok.
> some adventurous {\TeX} administrators will set up
> \acronym{TDS}-compliant trees,
>
> delete `adventurous' -- let's be hopeful.
Ok.
> This ``Beta Testing'' will flush out problems that were not obvious
>
> ``Beta Testing'' -> testing
> [weird capitalization, anyway]
Ok.
> conservative {\TeX} administrators will begin to adopt the \acronym{TDS}.
>
> even conservative ...
Ok.
> \section{References to Files and Documents}
>
> How about just `Related References'.
Ok.
> This appendix is for pointers to files and other documents we mention
> in this draft.
>
> ... related files and other documents.
> [I want to include things we don't mention elsewhere, too.]
Ok.
> We should say here what CTAN: means.
yes.
> Let's point to ftp.math.utah.edu:pub/tex/bib for a huge bibtex
> collection (both db's and styles).
Ok.
> \citetitle{Filenames for {\TeX} fonts} can be found in the CTAN archives
> in the \path|info/fontname| directory.
>
> How about doc/fontname instead? Since we use info/ to mean something else.
> Also: ``This distribution includes recommended supplier and typeface names''.
But this is a reference on CTAN, no?
> A complete set of {\protect\MF} modes is available from
> CTAN:\path|fonts/modes/modes.mf|.
>
> This distirbution includes recommended mode names.
Ok.
> TUG '94). All discussions were held by email. (The discussions
> are archived on ???.)
>
> shsu.edu:[twg.tds]
> I think this reference should be in the references section.
Yes.
> Eplain, \path|modes.mf|, et. al.
>
> No period after `et'.
Ok.
> MacKay, Pierre (\literal{mackay@cs.washington.edu}). Professor, Dept.
>
> Missing \ after `Dept.'. [You're getting an end-of-sentence space.]
Ok.
> Work}. (\acronym{TDS} Committee Chair).
>
> Period inside the ) or not at all?
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 18:15:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 19:09:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252309.TAA12968@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: mft files
Reply-To: TWG-TDS@SHSU.edu
> > Traditionally we've put mft files into tex/mft, but with the explosion
> > of top-level directories, maybe they should go there?
>
> Aren't they documentation of a sort?
>
> No, they are input files read by the mft program.
Any objection to tex/mft? I don't particularly like the top-level
explosion...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 18:16:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 19:11:36 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252311.TAA12975@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Toward a public draft ... 0.71
Reply-To: TWG-TDS@SHSU.edu
> - The file format appendix. Maybe the public draft will initially
> go out without it?
>
> I forgot we planning on this.
> I suggest we drop it for now.
> Does it really belong in the TDS document, anyway?
I don't remember why we thought it was a good thing. I'm willing to let
it go.
> (I suppose it'll have to be
> "copyright TUG, portions copyright ORA" when we add the extension
> appendix).
>
> As long as the permissions don't change.
They won't on my account ;-)
> - The ltxguide.sty style does a crummy job on figure titles (I think
> prepending "Figure <figure number>" would be a good idea; especially
> now that they float).
>
> It absolutely has to say Figure x.y if we're going to refer to them that way.
> And I don't think they should float, as I said.
I agree about the floating...maybe I should just force the page breaks
so they don't split across pages but not let them float?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 18:18:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 19:13:08 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252313.TAA12981@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: doc/
Reply-To: TWG-TDS@SHSU.edu
> Karl wrote:
>
> > The doc/ tree is still a mess. Ulrik, would you mind taking another look
> > and trying to get something consistent out of it? Right now there is the
> > tree in the complete TDS skeleton figure, the doc/ skeletong figure, and
> > the text. All are inconsistent with each other. The TDS example figure
> > seems more or less correct as far as it goes, but it doesn't go far
> > enough.
>
> I think I already commented on some of the inaccuracies in the doc tree
> figure shortly after the last draft. I'm not really sure about what's
> the best way to organize it either. In case of doubt, I'd personally
> leave out the separate doc figure and just keep the TDS skeleton figure
> more or less as it is now.
Now Karl has suggested trimming the doc part of the TDS skeleton and
pointing to the doc figure. I think that's a good idea, but it forces
us to fix the doc figure...
(there's probably still more about this in mail I haven't read yet...)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If the automobile had followed the same
Production Tools Specialist | development cycle as the computer, a Rolls-Royce
O'Reilly & Associates, Inc. | would today cost $100, get a million miles per
90 Sherman Street | gallon, and explode once a year, killing
Cambridge, MA 02140 | everyone inside. -- Robert X. Cringely
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 18:20:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 19:15:25 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252315.TAA13002@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Reply-To: TWG-TDS@SHSU.edu
> one comment on abbreviations/logos -- if they're all caps, please
> set them up so that end-of-sentence is handled properly. here are
> a couple of examples from the tugboat styles:
>
> \def\CTAN{{\SMC CTAN}\spacefactor1000 }
> \def\TeX{T\kern-.1667em\lower.424ex\hbox{E}\kern-.125emX\spacefactor1000 }
Will
\def\acronym#1{\textsc{#1}\spacefactor1000}
cut it?
> i'm boggled by the absence of figure numbers; especially 8.1 which
> happens by sheer bad luck to fall right after the sentence introducing
> the "martian" package.
Yeah, it's *gotta* be fixed.
> re the full-page figures, karl thinks they shouldn't float. i'd like
> to reinforce the other part of what he said if that's put into effect:
> do, please, keep each one on its own separate page. i find this very
> easy to comprehend, and, better, i can make a copy and stick it in
> front of a sysadmin's nose and say "here it is, can we live with it
> or not?"
Yep.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 18:23:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 1995 19:17:52 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504252317.TAA13008@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Reply-To: TWG-TDS@SHSU.edu
> > - The about the committee appendix. If you want to be there, tell me
> > NOW. I would like *everyone* to be on the list and I was going to
> > be inclusive by default, but since some folks
> > who are listening on the list explicitly wanted to be excluded, I
> > decided it was safer to be exclusive by default. Stand up and be
> > counted!
>
> Vieth, Ulrik (\literal{vieth@thphy.uni-duesseldorf.de}), graduate student
> in theoretical physics, maintainer of a local {\TeX} installation for
> a few months, adapted {\MP} to work with \application{Web2C} when it
> was released in early 1995, suggested inclusion of a chapter on {\MP}
> 1;1;0in the \acronym{TDS} draft.
Check.
> > The outstanding formatting issues are:
> >
> > - Logos and fonts. Does the document use the right ones now?
>
> I still think that the logo font should be used for the METAFONT logo.
> For the MetaPost logo this depends, but if possible it should be used
> as well, at least when the draft goes into print for TUGboat.
For TUGboat, I'll let the formatters do what they like; but for distribution,
I think we need to absolutely minimize the number of systems that it might
not format or print on.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 25 Apr 1995 21:07:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 25 Apr 95 18:51:16 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504260151.AA15809@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
*My* favorite example along these lines is:
This life is only a test. Had this been your real life,
you would have been told where to go and what to do.
Incidentally, the recent slides in California demostrated (once again)
just how ineffective thie system is. SIGH.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 04:48:10 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
Date: Wed, 26 Apr 1995 10:25:42 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:178770:950426092612"@cl.cam.ac.uk>
didnt i suggest the CTAN location be /tex-archive/tds, so as to right
up[front and obvious?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 05:42:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 06:42:41 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504261042.AA23792@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: 0.71 comments
> \subsection{Font Sources}
>
> I don't think this should be a subsection.
> You talk about more than sources, and we don't break up the other
> sections. (Maybe we should.)
>
> Admittedly that means the other subsection (on bitmaps) is kind of
> hidden after all this text, but I see no alternative.
The argument from the copyeditor that I had review this was that no
section should have a single subsection...
I don't follow that argument.
Anyway, either the subsection in question should be renamed or removed.
As it stands, it's wrong.
There was another place where I suggested making a subsection and it
didn't seem to make sense to you. I don't remember the specifics any
more, so just forget that and we'll see what happens on the next round.
> How about doc/fontname instead? Since we use info/ to mean something else.
> Also: ``This distribution includes recommended supplier and typeface names''.
But this is a reference on CTAN, no?
Yes, but ctan/doc == ctan/info, so we might as well use the
non-confusing name.
Any objection to tex/mft? I don't particularly like the top-level
This is current practice, so we might as well standardize on it, I guess.
Yes, it's a special case, which is bad, but it's also just a few files,
so giving it a top-level directory is also bad.
> http://jasper.ora.com/pub/twg-tds/tds.htm
I agree, these should line up, but it's a style issue. Since we haven't
picked a final style file yet, I'm not going to worry about it now...
Well, it's not just a style issue, it's a matter of making it separate
sentences vs. a table vs. whatever ...
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 05:43:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 95 11:42:48 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504261042.AA08827@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
> > \def\CTAN{{\SMC CTAN}\spacefactor1000 }
> > \def\TeX{T\kern-.1667em\lower.424ex\hbox{E}\kern-.125emX\spacefactor1000 }
>
> Will
>
> \def\acronym#1{\textsc{#1}\spacefactor1000}
>
> cut it?
In fact if you are using sc fonts (and lowercase input) you don't need
to reset the spacefacter at all (although it does no harm).
ie \textsc{ctan} is OK with no special kludges. The example above
needs it as the input is CTAN not ctan.
Also \TeX already has the spacefactor correction (\@) in its LaTeX
definition.
David
If we are discussing \spacefactor spacing, we must be *really* close
to the end:-)
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 08:13:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 14:03:10 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950426140310.20e04b0c@vms.rhbnc.ac.uk>
Subject: Re: Toward a public draft ... 0.71
>> Will
>> \def\acronym#1{\textsc{#1}\spacefactor1000}
>> cut it?
NNNNNNNNNNNNNNOOOOOOOOOOOOOOOOOO.
It was bad enough when Christina made that mistake (well, actually she wrote
10000, which was even worse). It _must_ have a space or a \relax to terminate
the number 1000, otherwise it will soak up any following digit.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 09:50:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 10:44:49 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261444.KAA04189@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.71 comments
Reply-To: TWG-TDS@SHSU.edu
>
> didnt i suggest the CTAN location be /tex-archive/tds, so as to right
> up[front and obvious?
Probably. Sorry I forgot.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 10:29:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504261528.RAA17931@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Toward a public draft ... 0.71
To: TWG-TDS@SHSU.edu
Date: Wed, 26 Apr 1995 17:28:45 +0200 (MESZ)
Content-Type: text
You wrote:
>
> > > \def\CTAN{{\SMC CTAN}\spacefactor1000 }
> > > \def\TeX{T\kern-.1667em\lower.424ex\hbox{E}\kern-.125emX\spacefactor1000 }
> >
> > Will
> >
> > \def\acronym#1{\textsc{#1}\spacefactor1000}
>
> In fact if you are using sc fonts (and lowercase input) you don't need
> to reset the spacefacter at all (although it does no harm).
Hmmm,
(a) but he does not use lowercase letters.
(b) what are the differences between cmcsc & cmr uppercase letters anyhow?
(c) tdsguide.cls has fixed such deficiencies already.
Why do you discuss the old macros?
What is more of interest (IMHO): Shall acronyms really be typeset a
bit smaller? (Really in lowercase small caps? or something in
between?).
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 10:31:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 11:26:29 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261526.LAA05143@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: doc table
Reply-To: TWG-TDS@SHSU.edu
>
> Well, here's my attempt at the doc/ tree. I got rid of the doc/ level itself.
Done.
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
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 10:33:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 11:28:31 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261528.LAA05174@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RFC: Your opinion on layout issues
Reply-To: TWG-TDS@SHSU.edu
> On the other changes:
>
> A headline that shows the current revision number. (I had so many
> printouts at home and missed that in the past.)
>
> Good.
>
> `draft' option puts `DRAFT!' into headline as well.
>
> Good, but please, no exclamation points. I get distracted easily. Just
> say `draft TDS version 0.71', centered? (I'm not crazy about the small
> caps, either, would prefer plain roman. But whatever.) In the
> non-draft version, it can say `TDS version 1.0'.
Sounds good.
> BTW, in the permission statement following, I think `modifications' should
> be `modification'. Norm, are you listening?
Yep.
> I say do the next draft in the new style, and see how it goes.
I'll give it a whirl.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 10:38:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 11:33:20 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261533.LAA05291@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
Reply-To: TWG-TDS@SHSU.edu
> > \RequirePackage{alltt} % alltt environment
> > \RequirePackage{path} % file names & email addresses
>
> The versions of alltt.sty and path.sty in your directory are not
> the latest. They are probably the same as mirrored from Norm.
> In particular, there is a 2e version of alltt.sty in latex/base
> and a more recent version of path.sty (3.04) in eplain-2.6.
I've removed the local alltt.sty; Karl says not to worry about path.sty
so I'm going to leave it until I install a new eplain...
> > \def\dir#1{\texttt{#1}}
> > \def\ext#1{\texttt{#1}}
>
> Are they used anywhere? If not, they should vanish, so that no-one
> would ever consider using them again in place of \path|...|.
Say bye-bye...
> > tds-uniform+sf.dvi
> >
> > More uniform vertical spacing.
>
> The spacing around list environments is much better, but I'd like to see
> a little more whitespace between paragraphs. I think this is too narrow
> in your layout. And then there's no whitespace after the introductory
> sentence in the overview figure. I'd consider that a bug of your layout.
>
> > Sans-serif head lines.
>
> Not sure. To mee they look too thin, especially in subsubsections (see
> `Valid font bitmaps', starting with one quad indentation in normalsize
> and without a number). Have you tried sans-serif demibold condensed?
>
> > So, what's your preferred layout? Original-One (tm), slight changes,
> > or the last one?
>
> Not quite the last one. More uniform spacing: yes, sans-serif: not sure!
>
> > Oh yes, and the TODO file tells about more stuff I would like to know:
> >
> > -- should the appendices start on a new page?
> > all of them? only the first?
>
> Probably the first one only, if any at all. Perhaps it would be better
> to flush pages before full-page figures, so that the next section won't
> start before the figure is output, independently of whether they appear
> in the main matter or in the appendix.
>
> Cheers,
> Ulrik.
>
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 10:39:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 10:39:56 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261439.KAA04039@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.71 comments
Reply-To: TWG-TDS@SHSU.edu
> > \subsection{Font Sources}
> >
> > I don't think this should be a subsection.
> > You talk about more than sources, and we don't break up the other
> > sections. (Maybe we should.)
> >
> > Admittedly that means the other subsection (on bitmaps) is kind of
> > hidden after all this text, but I see no alternative.
>
> The argument from the copyeditor that I had review this was that no
> section should have a single subsection...
>
> I don't follow that argument.
>
> Anyway, either the subsection in question should be renamed or removed.
> As it stands, it's wrong.
Fine, I'll heave it over the side.
> There was another place where I suggested making a subsection and it
> didn't seem to make sense to you. I don't remember the specifics any
> more, so just forget that and we'll see what happens on the next round.
Ok.
> > How about doc/fontname instead? Since we use info/ to mean something else.
> > Also: ``This distribution includes recommended supplier and typeface names''.
>
> But this is a reference on CTAN, no?
>
> Yes, but ctan/doc == ctan/info, so we might as well use the
> non-confusing name.
Oh, ok, I forgot about that.
> Any objection to tex/mft? I don't particularly like the top-level
>
> This is current practice, so we might as well standardize on it, I guess.
> Yes, it's a special case, which is bad, but it's also just a few files,
> so giving it a top-level directory is also bad.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The most likely way for the world to be
Production Tools Specialist | destroyed, most experts agree, is by accident.
O'Reilly & Associates, Inc. | That's where we come in; we're computer
90 Sherman Street | professionals. We cause accidents. -- Nathaniel
Cambridge, MA 02140 | Borenstein
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 26 Apr 1995 11:39:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Apr 1995 11:33:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199504261533.LAA05322@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: RFC: Your opinion on layout issues
Reply-To: TWG-TDS@SHSU.edu
> What about using this for \acroynm?
>
> What about renaming \acronym to \abbreviation, if we're gonna be finicky :-)?
How about \abbr then ;-P
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Apr 1995 16:22:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Apr 95 16:45:25 BST
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504281545.AA01542@boothp1.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: official tds abbreviation
> Since the document will be distributed as tds.tex, and it does use "tds"
> throughout, I don't think there will be any confusion.
I think it would be easy and useful to include a paragraph saying
explictly something like "This specification may be referred to as
`TWG-TDS 0.61' for short, or just `TDS' when the context makes it clear
which TDS is meant."
I have said "TWG-TDS" rather than just "TDS" because there are already
other TeX directory structures in existance. "TDS" (standing for "TeX
Directory Structure") should be considered ambiguous without some
qualifying name -- something like "Web2C TDS 6.x" (or should that be
"Kpathsea TDS 2.x"?).
This is important if someone wanted to discuss TWG-TDS compared with
some other TDS (converting from the old sub-directory-free TDS, say).
Remember how we had to make up names for the Cork encoding so we could
compare it with the Adobe encoding or the TeX Text encodings.
-- Damian
================================================================================
From owner-twg-tds@shsu.edu Fri, 28 Apr 1995 23:31:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Apr 1995 13:32:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199504281732.AA00173@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: da@dcs.ed.ac.uk
Subject: where does the mode go?
I'm sorry to have to do this, but here's a question something other than
editiorial matters. (It's very fortuitious you wrote when you did, David!)
A user (cc-d here) with multiple output devices has been actually trying
out the TDS structure, and has run into a problem.
The current PK structure is:
texmf/fonts/pk/supplier/typeface/mode/dpiNNNN/file.pk
Now, consider making the subdirectory specification for a dvi
driver. You've told the driver you want mode cx. To avoid listing all
the suppliers and typefaces (the whole point in the first place), you
have to do this:
PKFONTS=$TEXMF/fonts/pk//cx//
... which requires subdir searching in the middle, which is verboten for
the TDS.
So, I propose we move the mode up:
texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
Then the spec can be this:
PKFONTS=$TEXMF/fonts/pk/cx//
Problems? Objections? Other solutions?
In our earlier discussions about this, we decided to keep the dpiNNN
down at the end (so dpiNNN/foo.pk and fooNNN.pk can be easily dealt
with), but we didn't have any concrete reasons to keep the mode down
there -- it was just to ``be with'' the other low-level stuff. (I admit
I didn't look up the old mail, but I have a vivid memory of that part of
our maunderings :-)
================================================================================
From owner-twg-tds@shsu.edu Sat, 29 Apr 1995 05:37:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 29 Apr 95 11:37:53 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9504291037.AA11117@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC da@dcs.ed.ac.uk
In-reply-to: <199504281732.AA00173@terminus.cs.umb.edu> (kb@cs.umb.edu)
Subject: Re: where does the mode go?
pk/mode
sounds OK to me.
================================================================================
From owner-twg-tds@shsu.edu Sun, 30 Apr 1995 19:51:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 30 Apr 1995 20:51:21 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
To: TWG-TDS@SHSU.edu
Message-ID: <799289481.842999.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
regarding acronyms and small caps, while i was away last week i
happened on a statement that the new york times style is that
acronyms of three letters or more (or perhaps it was more than
three letters, i'm not certain; if anyone cares, i can perhaps
find the reference) are to be set smaller than the regular caps.
(okay, i don't remember either if regular small caps were to be
used, or only "smaller" caps.)
i personally find regular small caps to be too small for acronyms
(though they're just fine for things like author names in a program
or citation), which is why the tugboat style uses "smaller" caps,
one point size smaller than the nominal text size. this practice
also enables acronyms to be emboldened in bold headings, etc., etc.
joachim asks
(b) what are the differences between cmcsc & cmr uppercase letters anyhow?
i'm pretty sure that the only real difference is that the parameter
values for stroke width and similar features are larger for the
cmcsc "lowercase" than for the cmr caps of the same height; easily
checked in volume e of computers & typesetting, of which i don't
have a copy here at home. (i'm just off a plane.) the stroke
widths of regular caps are usually just a tad wider than those of
the true lowercase with the same design size, which is why "phony"
postscript small caps made by optically reducing the size of regular
caps to (say) the x-height always look too scrawny. however, caps
of a size intermediate between full text caps and true small caps are
likely to have stroke widths that are not so drastically reduced,
so the color remains reasonably uniform.
phil has already pointed out why a space or \relax is required
following \spacefactor1000 .
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sun, 30 Apr 1995 23:36:14 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 30 Apr 1995 21:36:17 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505010436.VAA13836@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
CC: mackay@cs.washington.edu
As a different take on Small Caps, the commonest description, which
is not, though I had thought it was, in Frank Romano's TypEncyclopaedia,
is 75% height of regular caps spread over 90% width. DEK's adjustments
tend to come fairly close to that. The text in TypeEncyclopaedia is
given the lie by the examples on the same page. What it says is,
"True-cut small caps are the same height as the x-height and are usually equato the mnormal cap width:" which is a bit bizarre, and certainly
does not correspond with any of the examples let into the text.
Even the 90% X 75% recipe won't work for a font such as Goudy OldStyle.
It makes the uppercase O look like a rugby ball (not an American football)
but it works for most narrower fonts.
I don't know what Frank Romano had in mind in saying that the width
of true-cut Small Caps is the same as regular caps. Maybe it includes
wider side-bearings, which would not be surprising, since most designers
insist on at least one unit of letterspacing with modern PostScript
type1 SmallCaps.
(Maybe "watermelon" would have been a better comparison than "rugby ball")
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
From owner-twg-tds@shsu.edu Thu, 04 May 1995 11:36:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 4 May 95 18:37:33 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505041637.AA01221@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: search paths for TeX formats
I'm currently working on setting up a complete new TeX installation,
following the texmf/tex/format/{base,config,misc,...} arrangement
for every package that might potentially be used as a format as well.
Now, I'm working on the search path specification for the individual
formats to put into my texmf.cnf file.
My reasoning is as follows. Please tell me if you agree with it or
if there is anything wrong:
- texmf/tex/generic is for files that can be used with any format
including both latex and the plain-based formats. Therefore every
format has to search this subtree as well as their own subtree.
For LaTeX(2e) and LaTeX209 that's it already. So far my texmf.cnf
reads as follows:
TEXINPUTS.latex209 = .:!!$TEXMF/tex/latex209//:!!$TEXMF/tex/generic//
TEXINPUTS.latex2e = .:!!$TEXMF/tex/latex2e//:!!$TEXMF/tex/generic//
TEXINPUTS.latex = $TEXINPUTS.latex2e
Now for the interesting part:
- texmf/tex/plain is for files that can be used with Plain TeX and
any other plain-based format, but not with LaTeX. Therefore every
plain-based format has to look into this subtree, as well as into
their own subtrees and texmf/tex/generic.
For AmS-TeX, eplain, and texinfo this means that I'll have to specify
at least three directories explicitely, just for the case that they
might be used as invidual formats, even if they usually aren't.
For Plain TeX itself, the story gets even worse: Apart from its own
texmf/tex/plain subdirectory and texmf/tex/generic, I'll have to search
all the subdirectories of the plain-based formats so that they will
be found in the usual case that they are not used as separate formats.
Altogether this means that I'll have to specify at least five subtrees.
This is really getting ugly! Isn't there any better solution than this?
TEXINPUTS.plain = .:!!$TEXMF/tex/plain//:!!$TEXMF/tex/generic//:!!$TEXMF/tex/eplain//:$TEXMF/tex/amstex//:!!TEXMF/tex/texinfo
TEXINPUTS.eplain = .:!!$TEXMF/tex/eplain//:!!$TEXMF/tex/plain//:!!$TEXMF/tex/generic//
TEXINPUTS.amstex = .:!!$TEXMF/tex/amstex//:!!$TEXMF/tex/plain//:!!$TEXMF/tex/generic//
TEXINPUTS.texinfo = .:!!$TEXMF/tex/texinfo:!!$TEXMF/tex/plain//
TEXINPUTS.tex = $TEXINPUTS.plain
Faced with this mess, I fell tempted to violate the TDS specification
and throw out the separate format-level directories for some of the
extra plain-based formats (amstex, eplain and most strikingly texinfo).
What would you do about this?
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Thu, 04 May 1995 12:07:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505041707.TAA19860@spice.iti.informatik.th-darmstadt.de>
Subject: Re: search paths for TeX formats
To: TWG-TDS@SHSU.edu
Date: Thu, 4 May 1995 19:07:31 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> I'm currently working on setting up a complete new TeX installation,
> following the texmf/tex/format/{base,config,misc,...} arrangement
> for every package that might potentially be used as a format as well.
If it's written that way in the TDS, it should be changed. Not
`potentially be used', but `effectively written for such usage'.
Effectively, this means one finds some \everyjob in the macros. :-)
> Faced with this mess, I fell tempted to violate the TDS specification
> and throw out the separate format-level directories for some of the
> extra plain-based formats (amstex, eplain and most strikingly texinfo).
>
> What would you do about this?
I did set up a respective texmf.cnf for the TDS-example distribution.
(For the umpteenth time: ftp.th-darmstadt.de:pub/tex/TDS/archives/*/.)
The relevant section for TeX is:
----------------
% Where the wild files are. You can set an environment variable to
% override this if you're testing a new TeX tree, without changing
% anything else.
TEXMF = /usr/local/lib/texmf
% TeX input files -- i.e., anything to be found by \input or \openin,
% including .sty, .eps, etc.
tex = $TEXMF/tex
% Notation: DB_<var> means that the directory (list) named by var is
% _only_ accessed by ls-R database.
DB_TEXMF=!!/usr/local/lib/texmf
DB_tex=$DB_TEXMF/tex
DB_fonts=$DB_TEXMF/fonts
% LaTeX2e specific macros are stored in latex/, macros that can only
% be used with 2.09 in latex209/. In addition, we feature the
% directory latex_2/ that holds macros that were written for 2.09 and
% do not mention 2e at all, but can be used with 2e.
latex209_inputs = .:$DB_tex/latex209//:$DB_tex/latex_2//:$DB_tex/generic//
latex2e_inputs = .:$DB_tex/latex//:$DB_tex/latex_2//:$DB_tex/generic//
TEXINPUTS.latex209 = $latex209_inputs
TEXINPUTS.latex2e = $latex2e_inputs
TEXINPUTS.latex = $latex2e_inputs
% plain TeX
% The command "tex" shall check all directories as last resort, it may
% read in plain-compatible stuff from everywhere. Those who use plain
% TeX must know what they do.
plain_inputs = $DB_tex/plain//:$DB_tex/generic//
TEXINPUTS.tex = .:$plain_inputs:$DB_tex//
% other plain-based formats
TEXINPUTS.amstex = .:$DB_tex/amstex//:$plain_inputs
TEXINPUTS.ftex = .:$DB_tex/formate//:$plain_inputs
TEXINPUTS.texinfo = .:$DB_tex/texinfo//:$plain_inputs
% INITEX
% Search also on disk; this is seldom done and INITEX is sometimes
% used directly after files have been added, when ls-lR is not up to
% date.
TEXINPUTS.initex = .:$tex//
% Earlier entries override later ones, so put this last.
TEXINPUTS = .:$DB_tex//
----------------
Note that I don't search on disk as the actuality of ls-R is asserted
by my installation scripts.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 08:32:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 09:32:30 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505051332.JAA25976@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Toward a public draft ... 0.71
Reply-To: TWG-TDS@SHSU.edu
> > In fact if you are using sc fonts (and lowercase input) you don't need
> > to reset the spacefacter at all (although it does no harm).
>
> Hmmm,
>
> (a) but he does not use lowercase letters.
OOOOoopps! I'll fix that...
> What is more of interest (IMHO): Shall acronyms really be typeset a
> bit smaller? (Really in lowercase small caps? or something in
> between?).
Well, smaller for sure. I'll let you decide what looks best.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 08:48:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 09:49:00 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505051349.JAA26327@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: official tds abbreviation
Reply-To: TWG-TDS@SHSU.edu
> I think it would be easy and useful to include a paragraph saying
> explictly something like "This specification may be referred to as
> `TWG-TDS 0.61' for short, or just `TDS' when the context makes it clear
> which TDS is meant."
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 08:49:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 09:50:14 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505051350.JAA26349@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: where does the mode go?
Reply-To: TWG-TDS@SHSU.edu
> So, I propose we move the mode up:
> texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
Sounds like we gotta do it.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 11:32:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 12:32:54 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505051632.MAA02170@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.72 Online...
Reply-To: TWG-TDS@SHSU.edu
In ftp://jasper.ora.com/private/twg-tds/tds.ps
Joachim,
I formatted this with one of your test versions of tdsguide.cls. Please
let me know where there's a more recent version (if there's a more recent
version).
TARGETING A PUBLIC RELEASE FOR 15 MAY 95, WE NEED TO GET THIS OUT THERE!
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 14:09:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 5 May 1995 11:40:07 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505051840.LAA02881@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
> So, I propose we move the mode up:
> texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
OK. Here goes. The following
public/
cm/
pk/
cx/
ricoh/
sunview/
source/
tfm/
concrete/
pk/
cx/
source/
tfm/
latex/
pk/
cx/
ricoh/
sunview/
source/
tfm/
logo/
pk/
cx/
sunview/
source/
tfm/
misc/
pk/
cx/
source/
tfm/
pandora/
pk/
cx/
source/
tfm/
punk/
pk/
source/
tfm/
scyrillic/
pk/
cx/
source/
tfm/
Expands to: (And I'm not even showning the source/ and tfm/ trees)
pk/
CanonCX/
adobe/
ams/
cyrillic/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
euler/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
extracm/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
symbols/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
bitstream/
public/
cm/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
concrete/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
latex/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
logo/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
misc/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
pandora/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
punk/
scyrillic/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
urw/
Ricoh/
adobe/
ams/
cyrillic/
euler/
extracm/
symbols/
bitstream/
public/
cm/
dpi300/
dpi329/
dpi360/
concrete/
latex/
dpi300/
dpi329/
dpi360/
logo/
misc/
pandora/
punk/
scyrillic/
urw/
ljfour/
pcscreen/
adobe/
ams/
cyrillic/
euler/
extracm/
symbols/
bitstream/
public/
cm/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
concrete/
latex/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
logo/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
misc/
pandora/
punk/
scyrillic/
urw/
What have we done?!
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 14:38:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 5 May 1995 11:40:07 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505051840.LAA02881@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
> So, I propose we move the mode up:
> texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
OK. Here goes. The following
public/
cm/
pk/
cx/
ricoh/
sunview/
source/
tfm/
concrete/
pk/
cx/
source/
tfm/
latex/
pk/
cx/
ricoh/
sunview/
source/
tfm/
logo/
pk/
cx/
sunview/
source/
tfm/
misc/
pk/
cx/
source/
tfm/
pandora/
pk/
cx/
source/
tfm/
punk/
pk/
source/
tfm/
scyrillic/
pk/
cx/
source/
tfm/
Expands to: (And I'm not even showning the source/ and tfm/ trees)
pk/
CanonCX/
adobe/
ams/
cyrillic/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
euler/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
extracm/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
symbols/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
bitstream/
public/
cm/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
concrete/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
latex/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
logo/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
misc/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
pandora/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
punk/
scyrillic/
dpi300/
dpi329/
dpi360/
dpi432/
dpi518/
dpi622/
dpi746/
urw/
Ricoh/
adobe/
ams/
cyrillic/
euler/
extracm/
symbols/
bitstream/
public/
cm/
dpi300/
dpi329/
dpi360/
concrete/
latex/
dpi300/
dpi329/
dpi360/
logo/
misc/
pandora/
punk/
scyrillic/
urw/
ljfour/
pcscreen/
adobe/
ams/
cyrillic/
euler/
extracm/
symbols/
bitstream/
public/
cm/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
concrete/
latex/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
logo/
dpi120/
dpi131/
dpi144/
dpi173/
dpi207/
dpi249/
dpi300/
misc/
pandora/
punk/
scyrillic/
urw/
What have we done?!
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 15:21:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 22:21:00 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505052021.AA21875@regulus.dbis.uh>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
I usually only read here, but since the public version comes closer,
I want to comment on the pk structure.
Maybe, we can discuss
texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
vs.
texmf/fonts/pk/mode/dpiNNN/supplier/typeface/file.pk
One argument to move the mode up, was to reduce the logical
search space for less optimised implementaions. For the same
reason, the dpiNNN could moved up as well.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 16:04:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 17:04:36 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505052104.RAA10179@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
Reply-To: TWG-TDS@SHSU.edu
>
> > So, I propose we move the mode up:
> > texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
>
> OK. Here goes. The following
...
> What have we done?!
OH GAWD! Thanks for finding this, Pierre.
What're we gonna do?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 05 May 1995 16:47:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 5 May 1995 17:47:39 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505052147.AA23387@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: where does the mode go
We discussed moving the dpiNNN up before.
It was nixed because it makes the dpiNNN/file.pk
vs. fileNNN.pk correspondence a lot more painful.
Really.
(look at kpathsea/tex-glyph.c, Thomas, and you'll see what I mean :-)
================================================================================
From owner-twg-tds@shsu.edu Sat, 06 May 1995 08:14:42 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505061314.PAA16990@spelunke.iti.informatik.th-darmstadt.de>
Subject: Re: where does the mode go?
To: TWG-TDS@SHSU.edu
Date: Sat, 6 May 1995 15:14:56 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >
> > > So, I propose we move the mode up:
> > > texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
> >
> > OK. Here goes. The following
>
> ...
>
> > What have we done?!
>
> OH GAWD! Thanks for finding this, Pierre.
What did he find? He presented two figures, one without dpi*
directories and one with dpi* directories. Discard the latter in the
second figure and compare again. Not much differences there any more
in terms of complexity.
While I'm known to be a proponent of the original scheme (font source
at the top, with dpi directories), I don't think this was a
convincing argument. Sorry, Pierre, no insult intended.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 06 May 1995 08:29:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 6 May 1995 09:30:16 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505061330.JAA22554@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
Reply-To: TWG-TDS@SHSU.edu
> Maybe, we can discuss
> texmf/fonts/pk/mode/supplier/typeface/dpiNNN/file.pk
> vs.
> texmf/fonts/pk/mode/dpiNNN/supplier/typeface/file.pk
>
> One argument to move the mode up, was to reduce the logical
> search space for less optimised implementaions. For the same
> reason, the dpiNNN could moved up as well.
I don't think we can do that. And I'm not sure we can even move
mode up. My understanding is that most DVI drivers give you
some ability to search for "<mode>/<dpi>/file" (this is how emTeX
work(s/ed), at least). The driver fills in <mode> and <dpi> before
it begins searching. If we move these things up, we force implementors
to search below the filled in parts, and I don't think that's currently
supported.
We talked about ../pk/mode/dpi/supplier... before and it didn't
work (though I don't quite recall why).
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 Sun, 07 May 1995 14:25:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 7 May 1995 15:25:33 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505071925.AA12820@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: where the mode goes
I never saw Pierre's message, and shsu.edu is disallowing ftp at the
moment so I can't look at it up.
But anyway, Norm tells me the gist is that moving the mode up means
replicating the supplier/typeface directories umpteen times. That's
true, and it really sucks. But I'm not sure it makes that much (if any)
difference to the total number of directories, and certainly not to the
total number of directories *searched*. (Since you're typically given
the mode name, and thus can restrict the search to that tree.)
We're already replicating the supplier/typeface stuff under each file
type. Most sites will only have a couple mode anyway, so it's not that
much more overhead.
Leaving the tree as pk/supplier/typeface/mode/dpiNNNN definitely makes
it necessary to do subdirectory searching ``in the middle'', as it were,
and we can't force that.
So why not go farther as Thomas and others have suggested, and move
dpiNNN up as well, i.e., mode/dpiNNN/supplier/typeface? My reply on this
was misleading before. I think the real answer is that leaving the
dpiNNN at the bottom makes it possible to omit that entire directory
level in the nonstandard-but-still-important case that fonts are stored
as cmr10.300pk, thus simplifying everything.
The final alternative is dpiNNN/supplier/typeface/mode, which is
*really* strange. It also requires subdir searching in the middle, anyway.
P.S. Don't get me wrong -- my personal preference is for the whole tree to
be inverted and the file types down at the bottom, so supplier/typeface
isn't replicated at all. I see the whole argument of putting file types
at the bottom as a misguided attempt to make subdirectory searching
efficient, when it simply isn't, and never will be. But we already had
that argument and I already capitulated, so never mind :-).
================================================================================
From owner-twg-tds@shsu.edu Sun, 07 May 1995 14:57:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 7 May 1995 15:57:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505071957.AA12950@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 0.73 comments
- the version number is missing from the headline.
- can we at least get rid of the `!' in `DRAFT!'? Especially since we're
presumably going to circulate the version for public review as `draft
0.99' or something, right?
- was the page layout changed? I feel like the margins got a lot bigger,
to no benefit. (I liked the sans serif headings, too, but if you decided
against that, fine.)
- the spacing around itemized and other lists seems enormous.
[correct me if I'm wrong on any of these, anyone; i'll put this up top
so more people are likely to see it. We should ask the other
implementors -- still have that list, Alan? -- what their syntax is.]
A LIST OF SUBDIRECTORY SEARCHING NOTATIONS GOES HERE
dvips: via a separate TEXFONTS_SUBDIR variable
emtex: t:subdir\\
kpathsea: texmf/subdir//
vms: texmf:[subdir...]
xdvi: texmf/subdir/*
On the title page:
Copyright © 1994, 95 by the &TeX; Users Group.
Let's have a space after the copyright sign.
This document is available in several formats:
I find the repeated URL very confusing. How about something simpler,
like this:
This document is available in LaTeX, DVI, PostScript, Texinfo, HTML, and
other formats from ftp://jasper.... and from /tex-archive/tds on any
CTAN host.
<acronym>OS/2</>, MacOS, and <acronym>VMS</>.
I find this new font is too small. Can we make it bigger, please?
help &TeX; users find their way around their local system if their
local system uses the &tds; recommended here.
[gosh those ;'s are distracting]
help &TeX; users find their way around systems organized in this way.
of runtime configuration, it could possibly even require recompiling
could possibly even => would
wherever possible. See <xref linkend="subsearchsyntax"> for a list.
This xref came out wrong -- to section 11.4, instead of A.4.
A special note about filenames: many, but not all, operating systems
Delete `A special note about filenames'.
filenames. In the &ISO9660; format, mixed-case names are not allowed.
The &ISO9660; format (described below) does not allow mixed-case names.
<para>
One place where mixed-case names are known to occur is in &LaTeX; font
...
the space required for all the files.
</para>
wdyt about moving this whole paragraph to a new section B.something,
`Case in filenames' (or something)? Somehow it seems out of place.
file system format for &CDROM;s. &ISO9660; is portable and efficient,
Can we delete `and efficient'? I don't see anything efficient about it.
A period is used to separate the filename from the
is used to separate => separates
Here is a typical &tds; example, using only seven levels:
Here is the deepest &tds; example, which needs only seven levels:
texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
Put cx/ in the right place.
``local'' files, since that would require duplciating the entire tree.
duplicating
This exception models standard practice.
models => follows
<filename>amslatex</> and <filename>babel</>,
No comma after babel.
The &tds; specifies that fonts sources shall be stored
fonts => font
is the type of file stored:
is the type of font file:
contains <emphasis>only</> the fonts distributed by the <acronym>AMS</>.
... in the ``amsfonts'' collection.
(The AMS probably distributes, or could distribute Computer Modern in
some way.)
Most &MF; input files are fonts (see the previous sectino); however a
sectino => section
Other categories include utility names, e.g.,
utility names:
[no need for e.g. and etc.]
A skeleton of the &tds; example tree under <filename>texmf/doc</>
Append a colon or period. Also, changing `example' to `directory' would
help, I think.
It seems trailing slashes aren't removed when there is no description,
as in
latex/
Joachim?
kpathsea/
May as well delete this. It's not adding anything.
A skeleton of the &tds; <filename>texmf</> tree
Again, need a colon or period, and again, insert `directory' before `tree'.
doc/ see <xref linkend=docexample>
No `8.1' came out in the doc figure caption. Joachim?
. <type>/ file type (e.g., <filename>pk</>)
. . <supplier>/ name of a font supplier (e.g., <filename>public</>)
. . . <typeface>/ name of a typeface (e.g., <filename>cm</>)
. . . . <mode>/ type of output device (for pk and gf only)
Put mode in the right place.
. . base/ base distribution for format
(e.g., plain.tex)
. . config/ configuration files for format
(e.g., <something>).
. . misc/ single-file packages
(e.g., <something>).
. . misc/ single-file format-independent packages
(e.g., texnames.sty)
. hyphen/ hyphenation patterns
Can I ask again why we're not putting hyphen under generic/?
should peruse CTAN:??? or send email to <literal>tdsr@cfcl.com</>.
??? indeed ...
could reasonably be expected from developers) and regularity (like
Delete `like'. You meant `such as', anyway.
In fact, many sites already use this alternative arrangement. It is the
arrangement suggested by the <application>Web2C</> distribution.
Parenthesize the web2c sentence.
<sect1><title>A Better Font Structure</>
Can we put in the relevant parts of my recent msg about moving the mode
into here?
Dept.<?tex \> of Classics and Dept. of Near Eastern Languages, University of
Need the fancy space after the second `Dept.', too.
liaison for the working group).
Can we move the period inside the parens?
`Multilingual Coordination'), founding member of <acronym>DANTE</>
... a founding ...
[I assume you weren't the *sole* founding member, Joachim!]
genius behind much of the best part of UnixTeX. Some of the original
early work to rationalize UnixTeX. Continues to contribute advice
Get `TeX' right (twice).
a few months, adapted &MP; to work with <application>Web2C</> when it
was released in early 1995.
Delete `when it was released', or something. Right now, it sounds like
web2c was released in early 95. (I wish.)
Work</>. (&tds; Committee Chair)
Can we please have a final period (inside the parens)?
Alternatively, maybe the parentheticals for you and Sebastian should go
inside the first parens, right after the real name, before the email addr.
That's it. Modulo the formatting glitches and pending final resolution
of the font directory tree, I think we can let this go out for review.
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 May 1995 09:43:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 May 1995 06:43:58 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505081043.GAA25673@jasper.ora.com>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: kb@cs.umb.edu, twg-tds@shsu.edu
Subject: TDS 0.72
Reply-To: TWG-TDS@SHSU.edu
> Something is wrong with tds.tex, it's a SGML (HTML?) file.
Oops. Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 May 1995 10:33:06 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 8 May 1995 08:28:45 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505081528.IAA28139@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: where does the mode go?
I'm afraid Joachim is right.
The proliferation is primarily caused by the introduction of the
dpi directories, and the need to accommodate DOS makes that inevitable.
Once that is accepted there is very little difference in whether
you say pk/mode/ or pk/supplier/
The tree I illustrated is an actual tree, already set up, and I
am perfectly willing to go with it. I just want it to be stable, and I
though it might be worth pointing out the price paid for it.
I have to get the new UnixTeX tape ready as soon as possible,
and I do not want it to be divorced from the TDS. I have scripts
ready to divide the basic distribution into the illustrated
baobab tree (isn't that the one that kills off all life beneath it?)
but I cannot leave Unix sites faced with this and no alternative
so I have to provide a script to get back to some sort of Unix
environment. For that it is helpful at least to start from
a stable base.
As for moving dpiNNN off the penultimate position---No, No, a thousand times
NO! Not only does that create a truly intolerable lot of multi-level
branches in the tree, it also goes against the early agreements about
how the systems that can do more than one-level searching mediate between
../dpiNNN/<font>.pk and ../<font>.NNNpk We settled that one a long
time ago, and confirmed the decision in several returns to the subject.
Surely we can leave it alone now.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 May 1995 12:13:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 8 May 1995 09:08:14 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505081608.JAA01596@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: where the mode goes
Karl has it right, and as he points out, although putting <format> at the root
doesn't proliferate directories as much as the unavoidable requirement
of dpiNNN directories does, it does add several multi-level branches
as compared with the simplest version which would still be
supplier/typeface/<formats>
If you have six formats [afm tfm vf source type1 pk/<modes>]
then you inevitably have
afm/supplier/typeface
tfm/supplier/typeface
vf/supplier/typeface
source/supplier/typeface
type1/supplier/typeface
pk/<mode-a>/supplier/typeface
pk/<mode-b>/supplier/typeface
pk/<mode-c>/supplier/typeface
as compared wit
supplier/typeface/afm
/tfm
/vf
/source
/type1
/pk/<mode-a>
/<mode-b>
/<mode-c>
Format-first is 27 directories. Supplier first is 11 directories.
This comparison is quite independent of the problem of dpiNNN/ directories.
which is the most intractable and unavoidable problem of all.
Incidentally, the number of dpiNNN directories that will come to be
needed is usually severely understated. As presses discover the
flexibility that allows half-point steps in type (Bodoni Lives!) they
demand them. In our everyday Baskerville, as supplied to half a dozen
University presses, the number of distinct dpi requirements for xdvi
has grown naturally, produced on the run by MakeTeXPK. For the
regular Roman it is now 18, for the Expert Roman and the Italic 11
each, for the Italic Expert 6 and for Boldface 3.
That is 49 dpiNNN directories needed for a single face from a single
supplier. Put dpiNNN down near the root of the tree and you have
49 multi-level branches to create. Once again. No, No, a thousand times
No!
(No apologies for "down near the root". My trees all have roots down
where the soil and water is.)
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 09:12:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 9 May 95 14:50:38 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505091350.AA17390@r8d.cs.man.ac.uk>
To: twg-tds@shsu.edu
Subject: 0.73 comments
<para>
Carlisle, David (<literal>carlisle@cs.man.ac.uk</>). Research
Associate, Computer Science Department,
Manchester University, UK. Member of the &LaTeX; project team.
</para>
Should now be
<para>
Carlisle, David (<literal>carlisle@ma.man.ac.uk</>). Research
Associate, Mathematics Department,
Manchester University, UK. Member of the &LaTeX; project team.
</para>
New email and real address from 1st May.
(Whatever the mail headers on this message might say:-)
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 13:09:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505091807.UAA22293@spice.iti.informatik.th-darmstadt.de>
Subject: Re: where the mode goes
To: TWG-TDS@SHSU.edu
Date: Tue, 9 May 1995 20:07:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Karl has it right, and as he points out, although putting <format> at the root
> doesn't proliferate directories as much as the unavoidable requirement
> of dpiNNN directories does, it does add several multi-level branches
> as compared with the simplest version which would still be
>
> supplier/typeface/<formats>
>
> If you have six formats [afm tfm vf source type1 pk/<modes>]
>
> then you inevitably have
>
1 > afm/supplier/typeface
2 > tfm/supplier/typeface
3 > vf/supplier/typeface
4 > source/supplier/typeface
5 > type1/supplier/typeface
6 > pk/<mode-a>/supplier/typeface
7 > pk/<mode-b>/supplier/typeface
8 > pk/<mode-c>/supplier/typeface
>
> as compared wit
>
1 > supplier/typeface/afm
2 > /tfm
3 > /vf
4 > /source
5 > /type1
6 > /pk/<mode-a>
7 > /<mode-b>
8 > /<mode-c>
>
>
> Format-first is 27 directories. Supplier first is 11 directories.
I have to say I don't understand that sentence. I count eight
directories, both for the supplier-first and for the type-first
solution, as shown above. (It should be so, as we don't increase the
nodes in this graph, we just change vertices.)
May you please explain how you come to a different directory count?
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 13:45:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505091844.UAA19797@spice.iti.informatik.th-darmstadt.de>
Subject: New revision of TDS layout
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Tue, 9 May 1995 20:44:38 +0200 (MESZ)
Content-Type: text
There is a new revision of the TDS document class `tdsguide' available
in ftp.th-darmstadt.de:/pub/tex/TDS/macros/. This directory holds
three files:
tds.dvi.gz - 0.72 in new layout
tds-dist.tex.gz - self-contained [sic!] LaTeX2e TDS document
tdsguide-1.0.tar.gz - all macros, test files, etc.
Contains also the two other files.
The rest of this mail will (a) tell what's changed and (b) tell about
unresolved problems.
The new class & this mail addresses all comments and requests I
received (positively or negatively ;-); please sent them again if you
don't find yourself mentioned. About two weeks ago, in the last week
of April, we had severe mailer problems (multiple overflows of mail
queues), I might have lost it.
** What's changed in the layout? **
I'm going to make this easy for me, here are excerpts from the
revision log:
% $StyleLog: tdsguide.cls,v $
% Revision 1.5 1995/05/09 01:46:24 schrod
% Typeset abbreviation one point smaller than surrounding font [uv,
% kb, bb], use always uppercase letters for them. Rename the tag from
% \acronym to \abbr [kb, nw].
%
% Revision 1.4 1995/05/09 00:39:57 schrod
% Repair vertical spacing around tdsSummary environment.
%
%[...]
%
% Revision 1.2 1995/05/07 18:22:53 schrod
% In environment tdsSummary: Next directory level indented by one
% quad, without dots for indentation [kb, !uv, js].
% Headline now features a centered short title [kb, uv, nw]. It's
% still ruled.
% Subsubsections are also numbered and not indented [uv]. But they
% are still not added to the table of contents. Actually, we have only
% _one_ subsubsection...
% Set erroneously counter `secnumdepth' when I wanted fewer section
% headings in the table of contents. That's controlled by counter
% `tocdepth' [uv].
The parentheses show who has influenced the respective change.
Sans-serif headlines are back; Karl and I like them, Ulrik is sceptic
-- we won. :-) :-)
** Self-contained TDS document **
The distribution features also the script `texar' (and a Makefile)
that creates a self-contained distributable TeX version of the TDS
document.
Note: No pre-release macros are used in the self-contained
document that's mentioned at the mail's start. I took _only_ current
versions from CTAN. (IMO that's the way to go.)
And there's a script `tex-it' that runs LaTeX as often as needed to
get a DVI document that is a fixpoint. (No checks for the
pathological case of oscillating cross references, though.)
Both scripts are for Unix platforms, Perl is required for texar. They
are not meant for distribution with the TDS itself, they are for
creating such distributions. (You're free to use and distribute them,
though. No copyright restrictions.)
** Unresolved points **
(Also mentioned in the TODO file.)
-- The summaries are now without captions. Is that intented?
(There is still one crossreference to Figure 8.1.)
-- The headline has been changed according to Karl's and Norm's
comments. It's still ruled, though. (I like it better that way.)
Raise any objections _now_ -- it'll be too late otherwise. :-)
-- Karl asked why the directory names are not terminated with
slashes. Norm mentioned that trailing slashes are in the source.
Karl -- do you want them everywhere or only in the summary tables?
I strip them explicitely off there, as they are not used elsewhere
in the document.
Anybody else with an opinion about trailing slashes?
-- Ulrik wanted more parskip. (Currently it's 1ex.) Anybody else with
an opinion about that matter?
Hope to hear from you soon.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 13:51:47 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505091807.UAA22293@spice.iti.informatik.th-darmstadt.de>
Subject: Re: where the mode goes
To: TWG-TDS@SHSU.edu
Date: Tue, 9 May 1995 20:07:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Karl has it right, and as he points out, although putting <format> at the root
> doesn't proliferate directories as much as the unavoidable requirement
> of dpiNNN directories does, it does add several multi-level branches
> as compared with the simplest version which would still be
>
> supplier/typeface/<formats>
>
> If you have six formats [afm tfm vf source type1 pk/<modes>]
>
> then you inevitably have
>
1 > afm/supplier/typeface
2 > tfm/supplier/typeface
3 > vf/supplier/typeface
4 > source/supplier/typeface
5 > type1/supplier/typeface
6 > pk/<mode-a>/supplier/typeface
7 > pk/<mode-b>/supplier/typeface
8 > pk/<mode-c>/supplier/typeface
>
> as compared wit
>
1 > supplier/typeface/afm
2 > /tfm
3 > /vf
4 > /source
5 > /type1
6 > /pk/<mode-a>
7 > /<mode-b>
8 > /<mode-c>
>
>
> Format-first is 27 directories. Supplier first is 11 directories.
I have to say I don't understand that sentence. I count eight
directories, both for the supplier-first and for the type-first
solution, as shown above. (It should be so, as we don't increase the
nodes in this graph, we just change vertices.)
May you please explain how you come to a different directory count?
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 14:14:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505091910.VAA22459@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Date: Tue, 9 May 1995 21:10:35 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> <acronym>OS/2</>, MacOS, and <acronym>VMS</>.
>
> I find this new font is too small. Can we make it bigger, please?
done. :-)
> It seems trailing slashes aren't removed when there is no description,
> as in
> latex/
> Joachim?
That's definitely an error I did not noticed when I wrote the mail a
few minutes ago. (One should read one's mailbox first. ;-) The next
revision will trailing slashes have everywhere or nowhere, pending
opinions from the other folks.
> doc/ see <xref linkend=docexample>
>
> No `8.1' came out in the doc figure caption. Joachim?
one of the unresolved problems.
> . hyphen/ hyphenation patterns
>
> Can I ask again why we're not putting hyphen under generic/?
If I remember correctly, because you and others stole my initex/. :-)
But I surrender, we may move it there as well.
> should peruse CTAN:??? or send email to <literal>tdsr@cfcl.com</>.
>
> ??? indeed ...
That brings me to another point: ftp.th-darmstadt.de:pub/tex/TDS/ has
(a) the current draft, (b) _all_ distributed previous drafts, and (c)
a collection of archives and files that may serve as building blocks
for TDS compliant distributions.
Should that stuff be on CTAN, too? Or should one add a reference to
this ftp server?
> `Multilingual Coordination'), founding member of <acronym>DANTE</>
>
> ... a founding ...
> [I assume you weren't the *sole* founding member, Joachim!]
Heaven forbid. (Obviously you don't know the other Joachim...) If
there is an other proper (American) English term (`charter member'?),
it should be used here -- on this level my English leaves me.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 14:22:57 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505091807.UAA22293@spice.iti.informatik.th-darmstadt.de>
Subject: Re: where the mode goes
To: TWG-TDS@SHSU.edu
Date: Tue, 9 May 1995 20:07:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Karl has it right, and as he points out, although putting <format> at the root
> doesn't proliferate directories as much as the unavoidable requirement
> of dpiNNN directories does, it does add several multi-level branches
> as compared with the simplest version which would still be
>
> supplier/typeface/<formats>
>
> If you have six formats [afm tfm vf source type1 pk/<modes>]
>
> then you inevitably have
>
1 > afm/supplier/typeface
2 > tfm/supplier/typeface
3 > vf/supplier/typeface
4 > source/supplier/typeface
5 > type1/supplier/typeface
6 > pk/<mode-a>/supplier/typeface
7 > pk/<mode-b>/supplier/typeface
8 > pk/<mode-c>/supplier/typeface
>
> as compared wit
>
1 > supplier/typeface/afm
2 > /tfm
3 > /vf
4 > /source
5 > /type1
6 > /pk/<mode-a>
7 > /<mode-b>
8 > /<mode-c>
>
>
> Format-first is 27 directories. Supplier first is 11 directories.
I have to say I don't understand that sentence. I count eight
directories, both for the supplier-first and for the type-first
solution, as shown above. (It should be so, as we don't increase the
nodes in this graph, we just change vertices.)
May you please explain how you come to a different directory count?
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 09 May 1995 15:30:44 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 9 May 1995 13:31:06 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505092031.NAA01832@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: where the mode goes
Now I am baffled.
Unless you use some form of forced linking
tfm/<supplier>/
and
vf/<supplier>/
are distinct entities, aren't they? They're certainly different inodes.
and so are all the directories underneath them. It may be the same
is a/
2[a]/
1[a]/
b/
2[b]/
1[b]/
c/
2[c]/
1[c]/
d/
2[d]/
1[d]/
really topologically identical with
1/
2/
a/
b/
c/
d/ ?
They end up with the same number of final leaves, (or put another way,
the same number of completed paths) which is four, but
it seems to me that the first example takes more effort to get there.
Or am I missing something?
Anyway, it doesn't really matter. Just as long as things stabilize.
I can live with almost anything so long as it isn't dpiNNN near the
root of the tree.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 May 1995 03:21:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 10 May 95 10:20:33 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505100820.AA02549@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: some corrections on 0.72
I might be a bit late to reply on the latest draft, but anyway I think
I spotted a few mistakes that need to be corrected before the release,
sohere it goes:
A skeleton of the \abbr{TDS} example tree under \path|texmf/doc|
\begin{tdsSummary}
help/ meta-information
. ctan/ info about CTAN sites, \path|TeX-index|, etc.
. faq/ FAQs of \path|comp.text.tex|, etc.
Might this document go here as well, i.e. help/tds once it is finished?
general/ across programs, generalities
. componen/ \citetitle{Components of {\TeX}}
. errata/ \path|errata.*|, \path|errata[1-8].tex|
Maybe it would be better to give a verbal description instead of raw
filenames? What about:
errrata to \citettile{Computers \& Typesetting}, error logs
(I believe the official title is ``Bugs (sigh!) in Computers & Typesetting'',
but that might be equally irritating to the reader.
<format>/ name of a format (\path|latex| example follows)
. base/ for the base format
. misc/ for single-file packages
. <package>/ for \emphasis{package} (\path|amslatex|, etc.)
latex/
. base/ \path|ltnews*|, \path|*guide|, etc.
What about: \citettitle{LaTeX News}, \path|{usr,fnt,cls}guide|, etc.
. . graphics/ \path|grfguide|
The indentation is wrong: graphics is a separate package, not a
sudirectory of base. Therefore it shoould be at the same level.
generic/ for non-format specific {\TeX} packages
. . german/ \path|germdoc|
. . babel/
Wrong indentation again! One level only, not two levels.
ams/
. amsfonts/ \path|amsfonts.faq|, \path|amfndoc|
. amstex/ \path|amsguide|, \path|joyerr.tex|
. amslatex/ \path|amslatex.faq|, \path|amsldoc|
This was my idea, but it doesn't fully comply to the standard arrangement.
However, I'm sure Barbara would like having all the AMS docs in one place,
rather than having them spread into fonts, plain and latex subdirectories.
Is this acceptable or should be rearranged?
fontname/ \citetitle{Filenames for {\TeX} fonts}
kpathsea/
What about some description for this? Personally, I find `kpathsea'
a horrible and almost unpronouncable abbreviation. (Sorry, Karl!)
Maybe replace this example by dvips instead?
fonts/
. oldgerm/ \path|corkpapr|
. malvern/
man/ Unix-style manual pages
html/ html files
\abbr{HTML} files?
info/ GNU info files, made from {\TeXinfo} sources
\end{tdsSummary}
A skeleton of the \abbr{TDS} \path|texmf| tree
\begin{tdsSummary}
bibtex/ {\protect\BibTeX} input files
. bib/ {\protect\BibTeX} databases of common interest
. bst/ {\protect\BibTeX} style files
bin/*/ binaries, by system type (optional)
doc/ see \xref{Figure 8.1}
The number 8.1 doesn't show up in the previous figure.
What about saying \xref{Section 8}?
fonts/ font-related files
. <type>/ file type (e.g., \path|pk|)
. . <supplier>/ name of a font supplier (e.g., \path|public|)
. . . <typeface>/ name of a typeface (e.g., \path|cm|)
. . . . <mode>/ type of output device (for pk and gf only)
. . . . . <dpi>/ font resolution (for pk and gf only)
\path|pk| and \path|gf| (twice!)
tex/ {\TeX} input files
. <\replaceable{format}>/ name of a format (e.g., \path|plain|)
. . base/ base distribution for format
. . config/ configuration files for format
. . misc/ single-file packages
. . <package>/ name of a package (e.g., \path|graphics|)
. generic/ format-independent packages
. . misc/ single-file format-independent packages
. . <package>/ name of a package (e.g., \path|babel|)
. hyphen/ hyphenation patterns
Add the line:
. mft/ style files for MFT
(Personally, I'd even prefer tex/plain/mft because it's tex/plain/base
where mftmac.tex lives, and it's highly unlikely that someone will
ever write a mftmac.cls for LaTeX, even though it would be possible
in analalogy to (c)webmac.tex for plain and cweb.sty for LaTeX.)
Vieth, Ulrik (\literal{vieth@thphy.uni-duesseldorf.de}). Graduate student
in theoretical physics, maintainer of a local {\TeX} installation for
a few months, adapted {\MP} to work with \application{Web2C} when it
was released in early 1995.
Karl complained that the `it' in the last phrase could be misinterpreted
as referring to Web2C instead of MP. Well, I admit that I didn't realize
this when I wrote this entry in a hurry, so it should be clarified somehow.
In addition to that, the sentence is somewhat misleading in another way
as the original MP distribution is already based on Web2C, but uses it's
own copy of the routines (based on an old version) in order to be largely
independent. Perhaps, it might be better to say something like
..., worked on integrating {\MP} into the most recent version of
the \application{Web2C} distribution.
(Besides: I've uploaded my MP patches and the modified sources on CTAN
this week. This includes a reorganized distribution of the MetaPost
input and doc file in a TDS-compliant directory tree. In order to
ease the transition I have set up symlinks `mp' pointing to `metapost'.
I have also added a null.mp file (based on null.mf) and finally I've
also uploaded a few contributed MP macros, so there is something to put
into metapost/misc now.)
So much for the most important corrections. I haven't got time for
more detailed proof-reading at the moment.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 May 1995 04:22:17 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Date: Wed, 10 May 1995 10:20:55 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:129250:950510092139"@cl.cam.ac.uk>
>
> That brings me to another point: ftp.th-darmstadt.de:pub/tex/TDS/ has
> (a) the current draft, (b) _all_ distributed previous drafts, and (c)
> a collection of archives and files that may serve as building blocks
> for TDS compliant distributions.
>
> Should that stuff be on CTAN, too? Or should one add a reference to
> this ftp server?
i suggest that CTAN mirror your site to tex-archive/tds from now
onwards, for as long as you maintain the stuff. then everyone will see
it, and you can control it, and the TDS docs can point to it.
i'll set this up
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 May 1995 05:05:27 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Date: Wed, 10 May 1995 11:05:05 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:157330:950510100525"@cl.cam.ac.uk>
> A LIST OF SUBDIRECTORY SEARCHING NOTATIONS GOES HERE
>
> dvips: via a separate TEXFONTS_SUBDIR variable
> emtex: t:subdir\\
no!
t:subdir**
> kpathsea: texmf/subdir//
> vms: texmf:[subdir...]
> xdvi: texmf/subdir/*
Y&Y: t:subdir// or t:subdir\\
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 10 May 1995 06:52:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505101151.NAA14552@spice.iti.informatik.th-darmstadt.de>
Subject: 0.72 [sic!] comments
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 10 May 1995 13:51:38 +0200 (MESZ)
Content-Type: text
Some comments on the current draft, 0.72. (Are the flow of comments on
0.73 wishful thinking? :-)
----------------------------------------
** bookinfo.sgm **
<corpauthor>The TUG Working Group on a &TeX; Directory Structure (TWG-TDS)</>
results in an overfull hbox
<para>
This document is available in several formats:
I fully agree with Karl that this list should be improved. First list
the general source (ftp://jasper.ora.com/pub/twg-tds/), then list all
available formats in a table or varlist where each entry has one line.
----------------------------------------
** intro.sgm **
<para>
In this document, ``<filename>/</>'' is used to separate filename
components; for example, <filename>texmf/fonts/</>…).
Discard `)' or add `('.
----------------------------------------
** basics.sgm **
See <xref linkend="subsearchsyntax"> for a list.
Your SGML backend should add ties between `Section' & the number. Here
is an example where a line-break occurred.
<para>
The root of the &tds; should be a directory containing only
&TeX;-related materials. In this document, we shall designate this
directory ``<replaceable>texmf</>,'' but the actual name of the directory is
up to the installer. On <acronym>PC</> networks, for example, this
could map to a logical drive specification such as <filename>T:</>.
</para>
Don't use <replaceable>texmf</> here, you use <filename>texmf</>
elsewhere. And please use single quotes here and put the comma
outside the quotes -- we mark a term and have to be precise. (I have
nothing against double quotes and classic quote punctuation for
quotations, btw.)
And how about adding
We recommend naming the directory of the system-wide &TeX;
installation <filename>texmf</>, if it is not placed at some
top-level directory.
----------------------------------------
** macros.sgm **
<filename>amslatex</> and <filename>babel</>,
are examples of <replaceable>package</>.
Superfluous comma?! (I hope...)
----------------------------------------
** mf.sgm **
<para>
Most &MF; input files are fonts (see the previous sectino);
section
----------------------------------------
** doc.sgm **
<programlisting role=tdssummary>
Add a \label{summary:doc} by your SGML backend.
help/ meta-information
. ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
file name with more than 8-chars
general/ across programs, generalities
. componen/ <citetitle>Components of &TeX;</>
Please name that texcomp/.
<format>/ name of a format (<filename>latex</> example follows)
. misc/ for single-file packages
for single-file package documentation
[it's not relevant if the package was in a single file]
latex/
Here I would prefer a styles/ directory for the misc/ directory, btw.
generic/ for non-format specific &TeX; packages
. . german/ <filename>germdoc</>
Skip of two indentation units at once?!
tex/ <filename>texbook.tex</>, <filename>gentle.tex</>, etc.
The actual text says texbook.tex goes to doc/general/.
metafont/ <filename>mfbook.tex</>, <filename>metafont-for-beginners</>, etc.
Same here. And the other filename breaks the 8 chars limit.
info/ GNU info files, made from &TeXinfo; sources
`Info' [uppercase i], as per request of FSF in the Texinfo manual.
General: Some documents are listed with, some are listed without
extensions. I would prefer a unique treatment.
----------------------------------------
** distrib.sgm **
<programlisting>
martian-1.0/read.me
martian-1.0/doc/martdoc.tex
martian-1.0/doc/example.tex
martian-1.0/hyphen/marthyph.tex
martian-1.0/plain/martian.tex
martian-1.0/latex/martian.sty
martian-1.0/latex/OT1mart.fd
martian-1.0/fonts/martian.mf
martian-1.0/fonts/mart10.mf
martian-1.0/fonts/tfm/mart10.tfm
</programlisting>
As a developer who creates a source-distribution, I wouldn't put the
tfm file in a separate directory.
----------------------------------------
** example.sgm **
[Not a good name for that file, should be named summary.sgm]
<programlisting role=tdssummary>
doc/ see <xref linkend=docexample>
see table on <pageref>.
[You have to use a \pageref here, to the \label inserted above.]
. . . . <mode>/ type of output device (for pk and gf only)
. . . . . <dpi>/ font resolution (for pk and gf only)
uppercase monospaced PK & GF, as elsewhere in the document.
----------------------------------------
** impissue.sgm **
<para>
Once installable forms of key &tds;-compliant packages are ready,
are more widespread
[There exist installable forms, e.g., in teTeX and in my TDS example
installation.]
----------------------------------------
** whereis.sgm **
<para>
From About...: All discussions were held by email. (The discussions
are archived on <filename>shsu.edu:[twg.tds]</filename>).
</para>
Full is part of the parenthesis.
<para>
<citetitle>A User's Manual for MetaPost</> and
<citetitle>Drawing Graphs with MetaPost</>
are available as <acronym>CSTR</> 162 and 164
from <filename>ftp.netlib.att.com</>. They are also included
as <filename>mpman.ps</> and <filename>mpgraph.ps</> in the &MP;
distribution.
</para>
I would prefer to have here a more `standard' citation. With author,
publisher, etc.
[in the rest]
Unify CTAN references, you might want to use pseudo-URLs anywhere.
Should Michael's Gentle Introduction and my TeX Components listed here
as well?
----------------------------------------
That's it for today. (Still waiting for your comments on the layout. :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 11 May 1995 23:33:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 11 May 1995 18:06:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505112206.AA24730@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
> No `8.1' came out in the doc figure caption. Joachim?
one of the unresolved problems.
Can you resolve it?
> . hyphen/ hyphenation patterns
>
> Can I ask again why we're not putting hyphen under generic/?
If I remember correctly, because you and others stole my initex/. :-)
But I surrender, we may move it there as well.
Does anyone else object? Since hyphenation patterns are generic (aren't
they?), I see little purpose to putting them a level up.
there is an other proper (American) English term (`charter member'?),
it should be used here -- on this level my English leaves me.
`founding member' is fine. But there should be an `a' before the
`founding'. Norm, I assume you already did/will do that.
(Where's the next draft? May 15 is quickly approaching! :-)
Karl -- do you want them everywhere or only in the summary tables?
I don't feel strongly. I think the trailing slashes help a little in the
summary tables. Not sure why. Can't explain it. Make the final decision
on this, I will be happy :-).
-- Ulrik wanted more parskip. (Currently it's 1ex.) Anybody else with
an opinion about that matter?
I think it's fine the way it is now, but wouldn't object to a slight
increase. As long as it doesn't start looking like Texinfo :-(.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 02:35:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 95 09:36:39 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505120736.AA04645@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Joachim:
> -- Ulrik wanted more parskip. (Currently it's 1ex.) Anybody else with
> an opinion about that matter?
Karl:
> I think it's fine the way it is now, but wouldn't object to a slight
> increase. As long as it doesn't start looking like Texinfo :-(.
If anyone cares: my suggestion would be 0.5\baselineskip (\medskipamount),
which would mean 6 pt compared to 4.3... pt (= 1 ex). Not really that
much of a difference, but noticeable nevertheless. But do what you like
and don't let this issue delay the sheduled release of the draft.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 08:46:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 09:45:13 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121345.JAA29438@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> - the version number is missing from the headline.
Joachim?
> - can we at least get rid of the `!' in `DRAFT!'? Especially since we're
> presumably going to circulate the version for public review as `draft
> 0.99' or something, right?
Joachim?
> - was the page layout changed? I feel like the margins got a lot bigger,
> to no benefit. (I liked the sans serif headings, too, but if you decided
> against that, fine.)
>
> - the spacing around itemized and other lists seems enormous.
Joachim?
> [correct me if I'm wrong on any of these, anyone; i'll put this up top
> so more people are likely to see it. We should ask the other
> implementors -- still have that list, Alan? -- what their syntax is.]
>
> A LIST OF SUBDIRECTORY SEARCHING NOTATIONS GOES HERE
>
> dvips: via a separate TEXFONTS_SUBDIR variable
> emtex: t:subdir\\
> kpathsea: texmf/subdir//
> vms: texmf:[subdir...]
> xdvi: texmf/subdir/*
Check. And, no, you're not going to like the format I used....
> On the title page:
>
> Copyright © 1994, 95 by the &TeX; Users Group.
>
> Let's have a space after the copyright sign.
Check.
> This document is available in several formats:
>
> I find the repeated URL very confusing. How about something simpler,
> like this:
>
> This document is available in LaTeX, DVI, PostScript, Texinfo, HTML, and
> other formats from ftp://jasper.... and from /tex-archive/tds on any
> CTAN host.
Ok.
> <acronym>OS/2</>, MacOS, and <acronym>VMS</>.
>
> I find this new font is too small. Can we make it bigger, please?
Um, Joachim, I'm using lowercase now so these are really small caps.
How did you want to handle these?
> help &TeX; users find their way around their local system if their
> local system uses the &tds; recommended here.
>
> [gosh those ;'s are distracting]
> help &TeX; users find their way around systems organized in this way.
Check.
> of runtime configuration, it could possibly even require recompiling
>
> could possibly even => would
Check.
>
> A special note about filenames: many, but not all, operating systems
>
> Delete `A special note about filenames'.
Check.
> filenames. In the &ISO9660; format, mixed-case names are not allowed.
>
> The &ISO9660; format (described below) does not allow mixed-case names.
Check.
> <para>
> One place where mixed-case names are known to occur is in &LaTeX; font
> ...
> the space required for all the files.
> </para>
>
> wdyt about moving this whole paragraph to a new section B.something,
> `Case in filenames' (or something)? Somehow it seems out of place.
Um, anyone else have an opinion?
> file system format for &CDROM;s. &ISO9660; is portable and efficient,
>
> Can we delete `and efficient'? I don't see anything efficient about it.
Check.
> A period is used to separate the filename from the
>
> is used to separate => separates
Check.
> Here is a typical &tds; example, using only seven levels:
>
> Here is the deepest &tds; example, which needs only seven levels:
>
> texmf/fonts/pk/public/cm/cx/dpi300/cmr10.pk
>
> Put cx/ in the right place.
Check and check.
> ``local'' files, since that would require duplciating the entire tree.
>
> duplicating
Check.
> This exception models standard practice.
>
> models => follows
Check.
> <filename>amslatex</> and <filename>babel</>,
>
> No comma after babel.
Check.
> The &tds; specifies that fonts sources shall be stored
>
> fonts => font
Check.
> is the type of file stored:
>
> is the type of font file:
Check.
> contains <emphasis>only</> the fonts distributed by the <acronym>AMS</>.
>
> ... in the ``amsfonts'' collection.
> (The AMS probably distributes, or could distribute Computer Modern in
> some way.)
Check.
> Most &MF; input files are fonts (see the previous sectino); however a
>
> sectino => section
Check.
> Other categories include utility names, e.g.,
>
> utility names:
> [no need for e.g. and etc.]
Ok.
> A skeleton of the &tds; example tree under <filename>texmf/doc</>
>
> Append a colon or period. Also, changing `example' to `directory' would
> help, I think.
Check.
> It seems trailing slashes aren't removed when there is no description,
> as in
> latex/
Joachim?
> kpathsea/
>
> May as well delete this. It's not adding anything.
Check.
> A skeleton of the &tds; <filename>texmf</> tree
>
> Again, need a colon or period, and again, insert `directory' before `tree'.
Check.
> doc/ see <xref linkend=docexample>
>
> No `8.1' came out in the doc figure caption. Joachim?
Or me? ... ;-)
> . <type>/ file type (e.g., <filename>pk</>)
> . . <supplier>/ name of a font supplier (e.g., <filename>public</>)
> . . . <typeface>/ name of a typeface (e.g., <filename>cm</>)
> . . . . <mode>/ type of output device (for pk and gf only)
>
> Put mode in the right place.
Check.
> . hyphen/ hyphenation patterns
>
> Can I ask again why we're not putting hyphen under generic/?
Ok, we are now...
> should peruse CTAN:??? or send email to <literal>tdsr@cfcl.com</>.
>
> ??? indeed ...
Yes...
> could reasonably be expected from developers) and regularity (like
>
> Delete `like'. You meant `such as', anyway.
Check.
> In fact, many sites already use this alternative arrangement. It is the
> arrangement suggested by the <application>Web2C</> distribution.
>
> Parenthesize the web2c sentence.
Check.
>
> Dept.<?tex \> of Classics and Dept. of Near Eastern Languages, University of
>
> Need the fancy space after the second `Dept.', too.
Check.
> liaison for the working group).
>
> Can we move the period inside the parens?
Check.
> `Multilingual Coordination'), founding member of <acronym>DANTE</>
>
> ... a founding ...
> [I assume you weren't the *sole* founding member, Joachim!]
Checnk.
> genius behind much of the best part of UnixTeX. Some of the original
> early work to rationalize UnixTeX. Continues to contribute advice
>
> Get `TeX' right (twice).
Check.
> a few months, adapted &MP; to work with <application>Web2C</> when it
> was released in early 1995.
>
> Delete `when it was released', or something. Right now, it sounds like
> web2c was released in early 95. (I wish.)
Check.
> Work</>. (&tds; Committee Chair)
>
> Can we please have a final period (inside the parens)?
Check.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 11:54: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: <199505121652.SAA14394@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 12 May 1995 18:52:25 +0200 (MESZ)
Content-Type: text
Norm, I send you mail concerning all points. I think you'll read them
later in your mailbox. :-)
Some comments on the stuff you mentioned, though:
> > - the version number is missing from the headline.
>
> Joachim?
(You have to change your SGML backend again. That's mentioned in the
private mail I sent a few days ago.
> > <acronym>OS/2</>, MacOS, and <acronym>VMS</>.
> >
> > I find this new font is too small. Can we make it bigger, please?
>
> Um, Joachim, I'm using lowercase now so these are really small caps.
> How did you want to handle these?
I handle them; you can generate what you want -- I convert it to the
format I like. :-) (Actually, one point smaller; and a warning if that
happens for big sizes as the fonts might not be there then.)
> > <para>
> > One place where mixed-case names are known to occur is in &LaTeX; font
> > ...
> > the space required for all the files.
> > </para>
> >
> > wdyt about moving this whole paragraph to a new section B.something,
> > `Case in filenames' (or something)? Somehow it seems out of place.
>
> Um, anyone else have an opinion?
I agree with Karl. (Hmm, I seem to write that sentence quite often
nowadays. ;-) It's important but belongs more to the rational. And
appendix B seems to get the rational section more and more.
> > It seems trailing slashes aren't removed when there is no description,
> > as in
> > latex/
>
> Joachim?
Yeah, I'll put the slashes in for each item.
> > doc/ see <xref linkend=docexample>
> >
> > No `8.1' came out in the doc figure caption. Joachim?
>
> Or me? ... ;-)
One of the points Karl mentioned in his mail from yesterday, too. I
can't resolve it -- there is figure markup at all here! I would prefer
a page reference, as I wrote in my 0.72 comments.
I could also generate a caption and a cross reference for each
tdsSummary environment, but I have to say I don't like that approach.
Would get problems on the SGML level anyhow.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 11:56:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121655.SAA29762@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 12 May 1995 18:55:22 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> Joachim:
> > -- Ulrik wanted more parskip. (Currently it's 1ex.) Anybody else with
> > an opinion about that matter?
>
> Karl:
> > I think it's fine the way it is now, but wouldn't object to a slight
> > increase. As long as it doesn't start looking like Texinfo :-(.
>
> If anyone cares: my suggestion would be 0.5\baselineskip (\medskipamount),
> which would mean 6 pt compared to 4.3... pt (= 1 ex). Not really that
> much of a difference, but noticeable nevertheless.
Perhaps I should mention why I did not change \parskip -- I don't
feel so strong about the current value.
But I would have to experiment to get new section skip values,
too. Currently they are coordinated with the 1ex value. And I'm
reluctant to spend that work. :-) More input needed, from other folks.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 11:59:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 12:58:12 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121658.MAA07339@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> Norm, I send you mail concerning all points. I think you'll read them
> later in your mailbox. :-)
>
> Some comments on the stuff you mentioned, though:
>
> > > - the version number is missing from the headline.
> >
> > Joachim?
>
> (You have to change your SGML backend again. That's mentioned in the
> private mail I sent a few days ago.
Fixed.
> > > <acronym>OS/2</>, MacOS, and <acronym>VMS</>.
> > >
> > > I find this new font is too small. Can we make it bigger, please?
> >
> > Um, Joachim, I'm using lowercase now so these are really small caps.
> > How did you want to handle these?
>
> I handle them; you can generate what you want -- I convert it to the
> format I like. :-) (Actually, one point smaller; and a warning if that
> happens for big sizes as the fonts might not be there then.)
Cool.
> > > <para>
> > > One place where mixed-case names are known to occur is in &LaTeX; font
> > > ...
> > > the space required for all the files.
> > > </para>
> > >
> > > wdyt about moving this whole paragraph to a new section B.something,
> > > `Case in filenames' (or something)? Somehow it seems out of place.
> >
> > Um, anyone else have an opinion?
>
> I agree with Karl. (Hmm, I seem to write that sentence quite often
> nowadays. ;-)
It shows good sense ;-)
> It's important but belongs more to the rational. And
> appendix B seems to get the rational section more and more.
I'll move it...
> > > doc/ see <xref linkend=docexample>
> > >
> > > No `8.1' came out in the doc figure caption. Joachim?
> >
> > Or me? ... ;-)
>
> One of the points Karl mentioned in his mail from yesterday, too. I
> can't resolve it -- there is figure markup at all here! I would prefer
> a page reference, as I wrote in my 0.72 comments.
>
> I could also generate a caption and a cross reference for each
> tdsSummary environment, but I have to say I don't like that approach.
> Would get problems on the SGML level anyhow.
I'm confused. After I've printed out 0.74, I'll take a look and see
if I can unconfuse myself.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 12:05:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 18:03:31 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950512180331.2023f0c6@vms.rhbnc.ac.uk>
Subject: RE: 0.73 comments
> A LIST OF SUBDIRECTORY SEARCHING NOTATIONS GOES HERE
>
> dvips: via a separate TEXFONTS_SUBDIR variable
> emtex: t:subdir\\
I think a leading slash would be appropriate here, otherwise it will
be taken relative to the _current_ directory on "t:", not the root
directory. Thus
emtex: t:\subdir\\
> kpathsea: texmf/subdir//
> vms: texmf:[subdir...]
> xdvi: texmf/subdir/*
Also the term `subdir' seems inappropriate for those cases (emTeX, VMS)
where it the first, not last, element in the chain; I would change
`subdir' to `directory' in those cases.
> Most &MF; input files are fonts (see the previous sectino); however a
>
> sectino => section
I know I shouldn't read things out of context, but
``Most &MF; input files are fonts'' seems a very strange
statement to me; ``Most &MF; input files are font programs
or parts of font programs'' makes a lot more sense, IMHO.
[terminal punctuation inside parentheses] I am informed that even Chicago
now accepts that it need be placed _within_ the parenthesis if and only
that is the logical placement for it...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 12:41:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121739.TAA17321@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 12 May 1995 19:39:43 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> [terminal punctuation inside parentheses] I am informed that even Chicago
> now accepts that it need be placed _within_ the parenthesis if and only
> that is the logical placement for it...
Heresis. Our civilisation goes down the drain. Next they'll agree to
punctuation outside quotes. Or steeling sheep. Or even letterspacing
lower case...
Hmpf, shall I letterspace the acronyms?
Joachim
[waiting for a C++ compiler to terminate ...
hating C++ ...
waiting for the weekend ...]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 12:44:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 12:58:12 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121658.MAA07339@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> Norm, I send you mail concerning all points. I think you'll read them
> later in your mailbox. :-)
>
> Some comments on the stuff you mentioned, though:
>
> > > - the version number is missing from the headline.
> >
> > Joachim?
>
> (You have to change your SGML backend again. That's mentioned in the
> private mail I sent a few days ago.
Fixed.
> > > <acronym>OS/2</>, MacOS, and <acronym>VMS</>.
> > >
> > > I find this new font is too small. Can we make it bigger, please?
> >
> > Um, Joachim, I'm using lowercase now so these are really small caps.
> > How did you want to handle these?
>
> I handle them; you can generate what you want -- I convert it to the
> format I like. :-) (Actually, one point smaller; and a warning if that
> happens for big sizes as the fonts might not be there then.)
Cool.
> > > <para>
> > > One place where mixed-case names are known to occur is in &LaTeX; font
> > > ...
> > > the space required for all the files.
> > > </para>
> > >
> > > wdyt about moving this whole paragraph to a new section B.something,
> > > `Case in filenames' (or something)? Somehow it seems out of place.
> >
> > Um, anyone else have an opinion?
>
> I agree with Karl. (Hmm, I seem to write that sentence quite often
> nowadays. ;-)
It shows good sense ;-)
> It's important but belongs more to the rational. And
> appendix B seems to get the rational section more and more.
I'll move it...
> > > doc/ see <xref linkend=docexample>
> > >
> > > No `8.1' came out in the doc figure caption. Joachim?
> >
> > Or me? ... ;-)
>
> One of the points Karl mentioned in his mail from yesterday, too. I
> can't resolve it -- there is figure markup at all here! I would prefer
> a page reference, as I wrote in my 0.72 comments.
>
> I could also generate a caption and a cross reference for each
> tdsSummary environment, but I have to say I don't like that approach.
> Would get problems on the SGML level anyhow.
I'm confused. After I've printed out 0.74, I'll take a look and see
if I can unconfuse myself.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Imagine if every Thursday your shoes exploded
Production Tools Specialist | if you tied them the usual way. This happens to
O'Reilly & Associates, Inc. | us all the time with computers, and nobody
90 Sherman Street | thinks of complaining." -- Jeff Raskin
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 12:59:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 13:57:57 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121757.AA15995@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.73 comments
I think a leading slash would be appropriate here, otherwise it will
be taken relative to the _current_ directory on "t:", not the root
Right.
Also the term `subdir' seems inappropriate for those cases (emTeX, VMS)
where it the first, not last, element in the chain; I would change
`subdir' to `directory' in those cases.
Fine.
statement to me; ``Most &MF; input files are font programs
or parts of font programs'' makes a lot more sense, IMHO.
Good.
[terminal punctuation inside parentheses] I am informed that even Chicago
now accepts that it need be placed _within_ the parenthesis if and only
that is the logical placement for it...
There is no other place for the period in these cases. It will look
funny. It looks funny without the period, too.
The only alternative I can see is putting those pseudo-titles at the
beginning of the paras, instead of the end, as I said in my original mail.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 13:00:44 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121759.TAA29892@spice.iti.informatik.th-darmstadt.de>
Subject: Re: where the mode goes
To: TWG-TDS@SHSU.edu
Date: Fri, 12 May 1995 19:59:09 +0200 (MESZ)
Content-Type: text
Pierre wrote:
>
> Now I am baffled.
>
> Unless you use some form of forced linking
>
> tfm/<supplier>/
>
> and
>
> vf/<supplier>/
>
> are distinct entities, aren't they? They're certainly different inodes.
> and so are all the directories underneath them. It may be the same
>
> is a/
> 2[a]/
> 1[a]/
> b/
> 2[b]/
> 1[b]/
> c/
> 2[c]/
> 1[c]/
> d/
> 2[d]/
> 1[d]/
>
>
> really topologically identical with
>
> 1/
> 2/
> a/
> b/
> c/
> d/ ?
>
> They end up with the same number of final leaves, (or put another way,
> the same number of completed paths) which is four, but
> it seems to me that the first example takes more effort to get there.
Ah, now I understand you.
Yes, I had a hidden assumption that I didn't explicate: I don't see
the case of directories with just one subdirectory as typical for the
TDS. (Or let's say it this way: Those with only public/cm/ won't have
any problem with the one or the other installation strategy.) I.e., I
assume a set of font suppliers, a set of fonts per supplier, a set of
modes, and a (maybe large) set of resolutions.
And if we have a similar amount of subdirectories on the first levels
the difference you showed looses its weight. (IMHO.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 13:01:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 14:00:08 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121800.AA16040@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
can't resolve it -- there is figure markup at all here! I would prefer
a page reference, as I wrote in my 0.72 comments.
All I care about is that there is no stupid reference to a Figure 8.1
when there is no such figure.
A page reference would be fine by me. A reference by title (``the doc
summary table'') would be fine. The current reference would be fine if
8.1 ends up in the caption. Whatever.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 13:43:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 14:42:05 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121842.OAA11730@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> > dvips: via a separate TEXFONTS_SUBDIR variable
> > emtex: t:subdir\\
>
> I think a leading slash would be appropriate here, otherwise it will
> be taken relative to the _current_ directory on "t:", not the root
> directory. Thus
>
> emtex: t:\subdir\\
Actually, I changed it to
t:\texmf\subdir\\
for consistency...
> > kpathsea: texmf/subdir//
> > vms: texmf:[subdir...]
> > xdvi: texmf/subdir/*
>
> Also the term `subdir' seems inappropriate for those cases (emTeX, VMS)
> where it the first, not last, element in the chain; I would change
> `subdir' to `directory' in those cases.
Huh? Isn't "texmf" first in both VMS and emTeX (using my example for emTeX)?
> > Most &MF; input files are fonts (see the previous sectino); however a
> >
> > sectino => section
Check.
> I know I shouldn't read things out of context, but
> ``Most &MF; input files are fonts'' seems a very strange
> statement to me; ``Most &MF; input files are font programs
> or parts of font programs'' makes a lot more sense, IMHO.
For the intended audience, I think font vs. font programs is probably
too minor a point to quibble over---I fear it might even be confusing
to some (who don't think of fonts as programs).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 13:51:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505121850.UAA18925@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 12 May 1995 20:50:02 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> > emtex: t:\subdir\\
>
> Actually, I changed it to
>
> t:\texmf\subdir\\
>
> for consistency...
But this was an example that texmf/ can disappear if we use something
like `t:\'...
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 13:54:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 14:53:54 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121853.OAA12555@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> > No `8.1' came out in the doc figure caption. Joachim?
>
> one of the unresolved problems.
>
> Can you resolve it?
Yes. I changed the reference to the section instead of the figure!
> -- Ulrik wanted more parskip. (Currently it's 1ex.) Anybody else with
> an opinion about that matter?
>
> I think it's fine the way it is now, but wouldn't object to a slight
> increase. As long as it doesn't start looking like Texinfo :-(.
I think it's fine.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 14:12:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 15:11:19 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121911.PAA13356@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> >
> > Actually, I changed it to
> >
> > t:\texmf\subdir\\
> >
> > for consistency...
>
> But this was an example that texmf/ can disappear if we use something
> like `t:\'...
Oh, fooey, that's right...
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
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 14:19:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 20:18:29 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950512201829.20239cc2@vms.rhbnc.ac.uk>
Subject: RE: 0.73 comments
>> Actually, I changed it to
>>
>> t:\texmf\subdir\\
>>
>> for consistency...
But isn't that overkill? is it not likely that `t' has been substituted
for (say) c:\texmf ?
>> > > kpathsea: texmf/subdir//
>> > > vms: texmf:[subdir...]
>> > > xdvi: texmf/subdir/*
>> >
>> > Also the term `subdir' seems inappropriate for those cases (emTeX, VMS)
>> > where it the first, not last, element in the chain; I would change
>> > `subdir' to `directory' in those cases.
>>
>> Huh? Isn't "texmf" first in both VMS and emTeX (using my example for emTeX)?
Well, it wasn't when I wrote it! It is in your newer version for emTeX,
but see above for reasons why that might lead to a lost level; and for
VMS, `texmf' is a `rooted logical name'. These are analogous to drives,
so the first-level directory is a directory, not a sub-directory...
>> For the intended audience, I think font vs. font programs is probably
>> too minor a point to quibble over---I fear it might even be confusing
>> to some (who don't think of fonts as programs).
But that's exactly the point: what goes in is a _program_; what comes out
is a _font_.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 14:28:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 15:27:43 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505121927.PAA14317@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> Date: Fri, 12 May 1995 20:18:29 +0100 (BST)
> From: Philip Taylor (RHBNC) <CHAA006@alpha1.rhbnc.ac.uk>
> >> Actually, I changed it to
> >>
> >> t:\texmf\subdir\\
> >>
> >> for consistency...
>
> But isn't that overkill? is it not likely that `t' has been substituted
> for (say) c:\texmf ?
Yep.
> >> > > kpathsea: texmf/subdir//
> >> > > vms: texmf:[subdir...]
> >> > > xdvi: texmf/subdir/*
> >> >
> >> > Also the term `subdir' seems inappropriate for those cases (emTeX, VMS)
> >> > where it the first, not last, element in the chain; I would change
> >> > `subdir' to `directory' in those cases.
> >>
> >> Huh? Isn't "texmf" first in both VMS and emTeX (using my example for emTeX)?
>
> Well, it wasn't when I wrote it! It is in your newer version for emTeX,
> but see above for reasons why that might lead to a lost level; and for
> VMS, `texmf' is a `rooted logical name'. These are analogous to drives,
> so the first-level directory is a directory, not a sub-directory...
Check.
> >> For the intended audience, I think font vs. font programs is probably
> >> too minor a point to quibble over---I fear it might even be confusing
> >> to some (who don't think of fonts as programs).
>
> But that's exactly the point: what goes in is a _program_; what comes out
> is a _font_.
You're right. Thanks, again, Phil!
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
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 14:45:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 20:43:11 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950512204311.20239cc2@vms.rhbnc.ac.uk>
Subject: RE: 0.73 comments
>> You're right. Thanks, again, Phil!
Well, I try :-)
================================================================================
From owner-twg-tds@shsu.edu Fri, 12 May 1995 15:22:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 12 May 1995 16:20:12 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505122020.QAA17389@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.74 available
Reply-To: TWG-TDS@SHSU.edu
In
ftp://jasper.ora.com/private/twg-tds/tds.*
Only the TeX, DVI, and PS versions are up to date.
I haven't even proofed 'em so ... YMMV
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Sat, 13 May 1995 23:32:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 13 May 1995 15:01:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505131901.AA26225@terminus.cs.umb.edu>
To: twg-tds@shsu.edu, vojta@math.berkeley.edu
Subject: 0.74 comments
\replaceable{texmf/subdir/*}
Paul, did I get this right for subdir searching for xdvi?
Or is it /** that means recursive search, and /* that means one-level?
[Paul, you don't have to read the rest of this :-)]
\author{The TUG Working Group on a {\TeX} Directory Structure (TWG-TDS)}
This line is too long.
Either the margins should be increased,
the line should broken,
or the `The' could be removed.
I prefer increasing the margins. I bet the whole document could be
several pages shorter with something other than latex's default formatting.
components; for example, \path|texmf/fonts/|$\ldots$). This is the
Drop the |$\ldots$|.
\emphasis{not} {\LaTeXe} packages, even though there exist {\LaTeX}
there sometimes exists
The \abbr{TDS} \emphasis{does not} suggest that only monocase names are allowed,
The TDS does \emphasis{not} require monocase names,
[documents can't suggest anything, only humans can]
respect to case, are particularly likely to be troublesome.
Remove the comma.
Here is the deepest \abbr{TDS} example, which needs only sevel levels:
sevel => seven
TWG recognizes that some installers may wish to place other files in
\abbr{TWG [this may be needed elsewhere]
files, compiled {\TeX} format files, {\protect\MF} bases, {\MP} mems, pool
Might as well delete `{\protect\MF} bases, {\MP} mems,' here. It's just
a list of examples, not anything canonical.
\item[\path|bin|/\replaceable{system}]
Transpose this paragraph with the source paragraph. The bin stuff is
more system-dependent than anything else.
Also, the footnote has always kind of bothered me. Could it be a
parenthetical instead?
.../|\replaceable{package}\path|/|\replaceable{file}
I really think we should remove the `file'. It doesn't go with the text
above, it doesn't add to the explanation, and it might be wrong (in the
case of more directory levels). Leaving the trailing `/' will help
people realize we're not giving the complete path here, so I suggest we
do that. It also matches the examples.
Thus, for almost every format, it is correct to
1) Are there any exceptions, or can the `almost' be deleted?
2) `format' should be \replaceable{format}.
search the \replaceable{format} directory, and then the
search at least ...
[our example just below puts the lie to it as stated; in fact, there
should be no paragraph break between this and the `Other directories...']
directories should be searched when using {\AMSTeX}.
... {\AMSTeX}, because {\AMSTeX} is compatible with Plain. [we don't
want people to think this is somehow a general consequence.]
For example, in the new standard {\LaTeX} distribution, the
standard L-2e dist... [it's not new any more]
The \abbr{TDS} specifies that font sources shall be stored
in separate directories:
The \abbr{TDS} specifies the following. [we're talking about more than
sources here. Also, combine this sentence with the previous paragraph.]
\path|texmf/fonts/|\replaceable{type}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{files}
Remove trailing `files', as before. (Notice we're being inconsistent
about /file vs. /files, and whether it's mentioned in the following
text.)
\item[\replaceable{files}]
are the individual files, e.g., \path|cmr10.tfm|,
\path|putr.pfa|, etc. But \path|PK| files need
additional structure; see \xref{Section 4.1, ``Font Bitmaps''}.
Delete this item, and replace it with a paragraph after the list:
For example:
texmf/fonts/tfm/public/cm/cmr10.tfm
texmf/fonts/type1/adobe/utopia/putr.pfa
PK files need addition structure; see ...
For more information about font filenames, consult \citetitle{Filenames
for {\TeX} fonts}.
Append text: (See \xref{appendix-c} for the complete reference.)
\path|texmf/fonts/pk/|\replaceable{mode}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
\path|texmf/fonts/gf/|\replaceable{mode}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
Delete `files' here (in both), as above.
and the \path|PK| files rebuilt.
Append text: (See \xref{appendix-c} for the complete reference.)
\path|texmf/metafont/|\replaceable{package}\path|/|\replaceable{files}
\path|texmf/metapost/|\replaceable{package}\path|/|\replaceable{files}
Delete trailing `files'.
\path|support| is reserved for some special files required by the
Delete `some'.
\replaceable{files} are the names of individual {\MP} files like
\path|plain.mp|.
Delete.
Therefore, we decided
we decided => the \abbr{TWG} felt
[there's a lot of room for disagreement]
. . config/ configuration files for format (e.g., ????).
???? => texsys.cfg
[some latex guru correct me if i'm wrong]
. . misc/ single-file packages (e.g., ????).
Delete the (e.g.), since obviously we can't think of any. Doesn't seem
necessary, anyway.
Indeed, some of this has taken place during the course of our deliberations.
Append text: (See \xref{appendix-c} for a sample tree available
electronically.)
should peruse CTAN:??? or send email to \literal{tdsr@cfcl.com}.
Since we're obviously not getting a reference here, let's just delete
the `CTAN:???'. Also, I wonder if the registry comments should be sent
to twg-tds@shsu.edu like everything else. I, for one, wouldn't mind
seeing it.
\subsubsection{dvips}
Dear, dear, dear. Norm, would you mind making this a table or a list
instead of separate subsection for each program? It sure wastes a lot of
space and makes it harder to read. We just need a single line for each thing:
<program> <syntax>
If a real table is too painful, just make a bulleted list or
whatever. Anything that keeps it on the same line. (It's especially bad
with the sans serif headings, since then you get into sans `TeX' and all
that.)
\path|texmf/fonts/pk/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
\path|texmf/fonts/pk/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{files}
Delete trailing `files'.
From About...: All discussions were held by email. (The discussions
are archived on \path|shsu.edu:[twg.tds]|).
Delete `From About...: '. Delete parentheses around the second sentence.
CTAN: means...
In this document, `CTAN:' means the root of a anonymous ftp CTAN
tree. This is both a host name and a directory name. For example:
sunsite.unc.edu:/pub/packages/TeX
ftp.tex.ac.uk:/tex-archive
ftp.uni-bielefeld.de:pub/tex
finger ctan@ftp.shsu.edu for a complete list of CTAN sites.
Karl says:
Let's point to ftp.math.utah.edu:pub/tex/bib for a huge bibtex
collection (both db's and styles).
ftp.math.utah.edu:pub/tex/bib has a huge BibTeX collection, both
databases and styles.
Unix Site-Coordinator for the distribution of {\TeX} from Robert
No - here.
tools and author systems. Active {\TeX}ie since 1981; Secretary of DVI
\abbr{DVI}
TUG TWGs, a founding member of \abbr{dante}
\abbr{TUG TWG}
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 May 1995 09:15:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 14 May 1995 10:14:29 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
To: TWG-TDS@SHSU.edu
Message-ID: <800460869.245200.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
ulrik notes, regarding the ams documentation, that
ams/
. amsfonts/ \path|amsfonts.faq|, \path|amfndoc|
. amstex/ \path|amsguide|, \path|joyerr.tex|
. amslatex/ \path|amslatex.faq|, \path|amsldoc|
doesn't fully comply to the standard arrangement,
However, I'm sure Barbara would like having all the AMS docs in one place,
rather than having them spread into fonts, plain and latex subdirectories.
yes, it will make it a lot easier for us to direct people to these
files if they're not scattered about and mixed in with other,
unrelated, material, so it would be difficult for us if amsfonts
stuff were placed under just "fonts". the division into three
"applications" (although none of the three is a program, nor is
"ams") is roughly equivalent to how we set up our archive (which
isn't, however, what the tds is trying to describe), so either
placing the three under "ams/" or removing "ams/" and having each
"application" move up a level is equally acceptable to me and
equally defies the spirit of the tds.
i haven't been able to get an opinion from anyone else here,
unfortunately, so i guess it's up to me. if no one else has a
problem with the way it is now, i don't. lumping them all under
"ams" at least does make a clear statement that we accept
responsibility for everything in this branch.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 May 1995 09:17:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 14 May 1995 10:16:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505141416.AA08728@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: 0.72 [sic!] comments
(I'm suddenly getting all this old mail!)
. ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
file name with more than 8-chars
True, but we can't change the world here. Either drop the `TeX-index' or
leave it, but don't change it.
latex/
Here I would prefer a styles/ directory for the misc/ directory, btw.
Why should latex be different? Doesn't the uniformity of `misc' meaning
``single-file things'' appeal to you :-)?
tex/ <filename>texbook.tex</>, <filename>gentle.tex</>, etc.
The actual text says texbook.tex goes to doc/general/.
Change the text. texbook.tex should go in doc/tex. If it doesn't go
there, what would?!
Should Michael's Gentle Introduction and my TeX Components listed here
texkomp, sure, since it talks about how things fit together.
Send Norm the text you want, and I'm sure he'll add it.
gentle, no, it talks about how to use plain more than anything else.
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 May 1995 09:26:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 14 May 1995 10:25:31 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505141425.AA08752@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: some corrections on 0.72
Might this document go here as well, i.e. help/tds once it is finished?
tds.tex is not meta-information.
(In retrospect, the distinction between help and doc was probably dubious.)
Come to think, I think the tds stuff should go in /tex-archive/doc/tds,
not /tex-archive/tds. Why should we get our own top-level directory?
Maybe it would be better to give a verbal description instead of raw
filenames? What about:
I think most people know these things by the filenames.
At least the ones who are likely to care.
And the idea is to tell texadmins what files we're proposing go in what
directories, so it's best to be specific, I think.
kpathsea/
What about some description for this? Personally, I find `kpathsea'
I already said to drop it.
a horrible and almost unpronouncable abbreviation. (Sorry, Karl!)
kay-path-sea. It's easy :-).
. mft/ style files for MFT
(Personally, I'd even prefer tex/plain/mft because it's tex/plain/base
The ``right'' place is texmf/mft. I guess there's not much difference
between two different wrong places (tex/mft and tex/plain/mft), so I
don't object to moving it. It's not current practice, though.
lumping them all under
"ams" at least does make a clear statement that we accept
I think we should keep doc/ams as it is. It is not completely
consistent, but the doc tree cannot be rationalized completely, nor does
it need to be. Putting all ams stuff under doc/ams follows current
practice, makes things reasonably straightforward to find, and keeps bb
happy :-).
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 May 1995 09:31:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 14 May 1995 10:30:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505141430.AA08761@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: 0.74 comments
Paul V. tells me:
As I recall, /* means single level, and /** means recursive search.
But take it with a grain of salt, though; I'm likely to change over to
a // format sometime soon.
so the xdvi subdir syntax should say `xdvi patchlevel 20', so it's clear
we're not talking about it for all time.
================================================================================
From owner-twg-tds@shsu.edu Sun, 14 May 1995 15:42:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 14 May 1995 22:41:46 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Message-ID: <01HQICT7TSPE90MTSA@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Phil,
unfortunately I have to disagree with you on the point
>[...]; and for
>VMS, `texmf' is a `rooted logical name'. These are analogous to drives,
>so the first-level directory is a directory, not a sub-directory...
Though in principle one could define a rooted logical for the texmf_root,
it doesn't work in practice, since one can define a rooted logical only
once, an this one time is needed by the printer drivers for their
respective tex_pkdir. Thus, the directory tree under VMS has to look like
disk_software:[texmf.subdirs],
with texmf using up one of the precious 8 directory levels, except you
want to reserve a whole physical disk for TeX and its friends.
--J"org Knappen.
P.S. Was I the only one getting week-old messages a second time?
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 May 1995 04:05:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 May 95 10:03:59 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505150903.AA21420@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: search paths for TeX formats
> TEXINPUTS.latex209 = .:!!$TEXMF/tex/latex209//:!!$TEXMF/tex/generic//
> TEXINPUTS.latex2e = .:!!$TEXMF/tex/latex2e//:!!$TEXMF/tex/generic//
> TEXINPUTS.latex = $TEXINPUTS.latex2e
I think you should interchange `latex' and `latex2e' in the above.
The TDS path for latex files is
$TEXMF/tex/latex not $TEXMF/tex/latex2e
(if you want the latter in addition you could have it as a non
standard extension, being a link to the former)
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 May 1995 06:02:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 May 1995 12:00:56 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950515120056.21401cb0@vms.rhbnc.ac.uk>
Subject: Re: 0.73 comments
[Ah: the VMS faction fight amongst themselves!]
>> unfortunately I have to disagree with you on the point
>> >[...]; and for
>> >VMS, `texmf' is a `rooted logical name'. These are analogous to drives,
>> >so the first-level directory is a directory, not a sub-directory...
>> Though in principle one could define a rooted logical for the texmf_root,
>> it doesn't work in practice, since one can define a rooted logical only
>> once, an this one time is needed by the printer drivers for their
>> respective tex_pkdir. Thus, the directory tree under VMS has to look like
>> disk_software:[texmf.subdirs],
>> with texmf using up one of the precious 8 directory levels, except you
>> want to reserve a whole physical disk for TeX and its friends.
May I, with the greatest respect, continue to differ? :-) Although one
cannot define a rooted logical name with an element which is itself a
rooted logical name, one can (and regularly does) define two or more
rooted logical names with a single ultimate point of reference; for example,
in the above, one could have both:
$ define /tran /conc texmf some_arbitrary_real_disk:[texmf.]
and
$ define /tran /conc texmf_pk_root: same_arbitrary_disk:[texmf.fonts.pk.]
(I have deliberately omitted the intervening elements between `fonts' and `pk'
both in the interest of clarity and to avoid becoming entangled in the `what
goes where' debate).
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 May 1995 08:17:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 May 1995 15:16:29 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
To: TWG-TDS@SHSU.edu
Message-ID: <01HQJBM10WMQ8Y57B2@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Phil: May I, with the greatest respect, continue to differ? :-)
Of course, the point I wanted to make is that one cannot save one directory
level by defining a rooted logical for texmf_root. And the fonts hierarchy
is critical in the number of levels needed.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 May 1995 08:46:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 May 1995 14:45:54 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950515144554.21402111@vms.rhbnc.ac.uk>
Subject: Re: 0.73 comments
>> Of course, the point I wanted to make is that one cannot save one directory
>> level by defining a rooted logical for texmf_root. And the fonts hierarchy
>> is critical in the number of levels needed.
OK, now I understand (I had misunderstood J"org's point); but I am still
not fully convinced that there is a problem: VMS supports eight levels of
directory taken with respect to the root, which may either be a real device
or a rooted logical name; suppose that we agree that the root of a VMS
TeX/MF hierarchy is
some_arbitrary_device:[texmf.]
and let us thereby define a suitable rooted lnm:
$ define /tran /conc texmf some_arbitrary_device:[texmf.]
Now from the draft, the longest path is
texmf:[fonts.pk.public.cm.cx.dpi300]cmr10.pk
which is only _six_ levels deep: what is the problem?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 May 1995 09:56:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505151455.QAA24608@spice.iti.informatik.th-darmstadt.de>
Subject: Re: some corrections on 0.72
To: TWG-TDS@SHSU.edu
Date: Mon, 15 May 1995 16:55:25 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> ams/
> . amsfonts/ \path|amsfonts.faq|, \path|amfndoc|
> . amstex/ \path|amsguide|, \path|joyerr.tex|
> . amslatex/ \path|amslatex.faq|, \path|amsldoc|
>
> This was my idea, but it doesn't fully comply to the standard arrangement.
I think, it does fully comply. IMO, the ``standard arrangement'' for
the doc tree should be `make it easy to find & comprehend for the
user'. I don't follow the opinion that the doc tree must mirror the
file tree all the time. Humans have different categorization needs as
programs. (At least, I believe so... :-)
> Add the line:
>
> . mft/ style files for MFT
>
> (Personally, I'd even prefer tex/plain/mft because it's tex/plain/base
> where mftmac.tex lives
Just for the record: In the TDS example distribution, I've put
mftmac.tex in tex/mft/, now that mft is below tex/ anyhow. IMO it's
better to collect all MFT-related files there.
Joachim
PS: Haven't had time to read 0.74 yet. (We had a nice wine-testing
yesterday. :-) I just saw the titlepage; I will change the macros and
try to convince fancyheadings.sty that it drops the headline from
there.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 03:35:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 95 10:36:12 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505160836.AA07598@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: more 0.74 comments
> \sourcefile{bibtex.sgm}
> \formatterfile{bibtex.tex}
> \section{{\protect\BibTeX}}
> {\protect\BibTeX} database files shall be stored in \path|texmf/bibtex/bib|.
> {\protect\BibTeX} style files shall be stored in \path|texmf/bibtex/bst|.
Can we make this two paragraphs or maybe two items in a list environment?
It would be more consistent to have separte items or paragraph for every
directory throughout all sections.
> \sourcefile{doc.sgm}
> \formatterfile{doc.tex}
> \section{Documentation}
latex/
. base/ \path|ltnews*|, \path|*guide|, etc.
. . graphics/ \path|grfguide|
generic/ for non-format specific {\TeX} packages
. . german/ \path|germdoc|
. . babel/
<program>/ {\TeX} applications, by name (examples follow)
You still haven't fixed the indentation levels here! (Or did my last mail
got through too late?) In case you missed it: graphics/ is not a subdir
of base/, it should be at the same level. Likewise for german/ and babel/
there should be only one level of indentation.
Another comment on the doc tree: Did anybody else notice that general/
and generic/ end up next to each other on systems that automatically
sort directories alphabetically? I'm somewhat worried that this might
turn out as a constant source of confusion for many users and admins.
At my site, I tried to avoid this by uppercasing General/ and Help/,
so that they show up first when sorted, but this isn't an universal
solution. Any better ideas? Or any suggestions for renaming something?
> \sourcefile{whereis.sgm}
> \formatterfile{whereis.tex}
> \section{Related References}
> This appendix is for pointers to related files and other documents.
> \citetitle{A User's Manual for MetaPost} and
> \citetitle{Drawing Graphs with MetaPost}
> are available as \abbr{cstr} 162 and 164
> from \path|ftp.netlib.att.com|. They are also included
> as \path|mpman.ps| and \path|mpgraph.ps| in the {\MP}
> distribution.
The reference to these documents seems somewhat unmotivated now that
they are no longer cited by title in the MetaPost section (just by
filename in the doc tree). Should they remain or should they go?
Should texbook.tex and mfbook.tex be mentioned here as well?
So long,
Ulrik.
P.S. Re: David's comment on my week-old message about search paths:
In my installation the directories are called latex209/ and latex2e/,
where latex/ is a symbolic link to latex2e/. Hopefully this will
allow me to switch the link to latex3/ some day in the future ;-).
P.P.S. And no-one spotted the real bug in my search path example:
Setting TEXINPUTS.latex = $TEXINPUTS.latex2e causes hash_lookup
to loop until it fails after having used up all available memory.
You start LaTeX, nothing happens at first, the system starts paging
heavily until LaTeX eventually dies with a cryptic error message.
Is this a bug or didn't I read the docs carefully enough, Karl?
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 04:40:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 95 10:38:58 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505160938.AA22274@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: more 0.74 comments
Ulrick,
> P.S. Re: David's comment on my week-old message about search paths:
> In my installation the directories are called latex209/ and latex2e/,
> where latex/ is a symbolic link to latex2e/. Hopefully this will
> allow me to switch the link to latex3/ some day in the future ;-).
This was discussed early on when this list was set up, and the
decision was that texmf/tex/latex should be the path, not texmf/tex/latex2e.
No doubt you will not be alone on unix setups in having a latex2e
branch, and while in practice it does not make much difference whether
latex2e is a link to latex or the other way round, if you are
*distributing* a tds rather than just setting up a local installation
it should be set up so that tex/latex is clearly the primary branch
and the latex2e branch can be dropped (for instance on a system that
does not support links).
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 08:37:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 09:36:22 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161336.JAA19276@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.73 comments
Reply-To: TWG-TDS@SHSU.edu
> > should peruse CTAN:??? or send email to <literal>tdsr@cfcl.com</>.
> >
> > ??? indeed ...
I'm going to remove the reference:
Interested parties
should peruse CTAN:??? or send email to <literal>tdsr@cfcl.com</>.
And let people direct their queries about the registry to the TDS list.
If traffic gets too voluminous, we'll construct another list.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 09:07:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 10:06:25 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161406.KAA20650@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.74 comments
Reply-To: TWG-TDS@SHSU.edu
> \author{The TUG Working Group on a {\TeX} Directory Structure (TWG-TDS)}
>
> This line is too long.
> Either the margins should be increased,
> the line should broken,
> or the `The' could be removed.
I removed The. (If I find in later mail that Joachim has made the margins
larger, I'll put it back ;-)
> components; for example, \path|texmf/fonts/|$\ldots$). This is the
>
> Drop the |$\ldots$|.
Check.
> \emphasis{not} {\LaTeXe} packages, even though there exist {\LaTeX}
>
> there sometimes exists
Check.
> The \abbr{TDS} \emphasis{does not} suggest that only monocase names are allowed,
>
> The TDS does \emphasis{not} require monocase names,
> [documents can't suggest anything, only humans can]
Check.
> respect to case, are particularly likely to be troublesome.
>
> Remove the comma.
Check.
> Here is the deepest \abbr{TDS} example, which needs only sevel levels:
>
> sevel => seven
Check.
> TWG recognizes that some installers may wish to place other files in
>
> \abbr{TWG [this may be needed elsewhere]
Check.
> files, compiled {\TeX} format files, {\protect\MF} bases, {\MP} mems, pool
>
> Might as well delete `{\protect\MF} bases, {\MP} mems,' here. It's just
> a list of examples, not anything canonical.
Ok.
> \item[\path|bin|/\replaceable{system}]
>
> Transpose this paragraph with the source paragraph. The bin stuff is
> more system-dependent than anything else.
Check.
> Also, the footnote has always kind of bothered me. Could it be a
> parenthetical instead?
Sure.
> .../|\replaceable{package}\path|/|\replaceable{file}
>
> I really think we should remove the `file'. It doesn't go with the text
> above, it doesn't add to the explanation, and it might be wrong (in the
> case of more directory levels). Leaving the trailing `/' will help
> people realize we're not giving the complete path here, so I suggest we
> do that. It also matches the examples.
Check.
> Thus, for almost every format, it is correct to
>
> 1) Are there any exceptions, or can the `almost' be deleted?
Are there formats with non-Plain catcodes?
> 2) `format' should be \replaceable{format}.
> search the \replaceable{format} directory, and then the
Ok.
> search at least ...
> [our example just below puts the lie to it as stated; in fact, there
> should be no paragraph break between this and the `Other directories...']
Ok.
> directories should be searched when using {\AMSTeX}.
>
> ... {\AMSTeX}, because {\AMSTeX} is compatible with Plain. [we don't
> want people to think this is somehow a general consequence.]
Check.
> For example, in the new standard {\LaTeX} distribution, the
>
> standard L-2e dist... [it's not new any more]
Check.
> The \abbr{TDS} specifies that font sources shall be stored
> in separate directories:
>
> The \abbr{TDS} specifies the following. [we're talking about more than
> sources here. Also, combine this sentence with the previous paragraph.]
Check.
> \path|texmf/fonts/|\replaceable{type}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{files}
>
> Remove trailing `files', as before. (Notice we're being inconsistent
> about /file vs. /files, and whether it's mentioned in the following
> text.)
Ok.
> \item[\replaceable{files}]
> are the individual files, e.g., \path|cmr10.tfm|,
> \path|putr.pfa|, etc. But \path|PK| files need
> additional structure; see \xref{Section 4.1, ``Font Bitmaps''}.
>
> Delete this item, and replace it with a paragraph after the list:
>
> For example:
> texmf/fonts/tfm/public/cm/cmr10.tfm
> texmf/fonts/type1/adobe/utopia/putr.pfa
> PK files need addition structure; see ...
Check.
> For more information about font filenames, consult \citetitle{Filenames
> for {\TeX} fonts}.
>
> Append text: (See \xref{appendix-c} for the complete reference.)
Check.
> \path|texmf/fonts/pk/|\replaceable{mode}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
> \path|texmf/fonts/gf/|\replaceable{mode}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
>
> Delete `files' here (in both), as above.
Check.
> and the \path|PK| files rebuilt.
>
> Append text: (See \xref{appendix-c} for the complete reference.)
Check.
> \path|texmf/metafont/|\replaceable{package}\path|/|\replaceable{files}
> \path|texmf/metapost/|\replaceable{package}\path|/|\replaceable{files}
>
> Delete trailing `files'.
Check.
> \path|support| is reserved for some special files required by the
>
> Delete `some'.
Check.
> \replaceable{files} are the names of individual {\MP} files like
> \path|plain.mp|.
>
> Delete.
Check.
> Therefore, we decided
>
> we decided => the \abbr{TWG} felt
> [there's a lot of room for disagreement]
Check.
> . . config/ configuration files for format (e.g., ????).
>
> ???? => texsys.cfg
> [some latex guru correct me if i'm wrong]
Ok.
> . . misc/ single-file packages (e.g., ????).
>
> Delete the (e.g.), since obviously we can't think of any. Doesn't seem
> necessary, anyway.
Check.
> Indeed, some of this has taken place during the course of our deliberations.
>
> Append text: (See \xref{appendix-c} for a sample tree available
> electronically.)
Check.
> should peruse CTAN:??? or send email to \literal{tdsr@cfcl.com}.
>
> Since we're obviously not getting a reference here, let's just delete
> the `CTAN:???'. Also, I wonder if the registry comments should be sent
> to twg-tds@shsu.edu like everything else. I, for one, wouldn't mind
> seeing it.
Yep.
> \subsubsection{dvips}
>
> Dear, dear, dear. Norm,
Karl, Karl, Karl. I told you you weren't going to like it! ;-)
> would you mind making this a table or a list
> instead of separate subsection for each program? It sure wastes a lot of
> space and makes it harder to read. We just need a single line for each thing:
I'm trying a list now; I'll go to a table if the list doesn't work out.
> \path|texmf/fonts/pk/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{files}
> \path|texmf/fonts/pk/|\replaceable{mode}\path|/|\replaceable{dpi}\path|/|\replaceable{supplier}\path|/|\replaceable{typeface}\path|/|\replaceable{files}
>
> Delete trailing `files'.
Check.
> From About...: All discussions were held by email. (The discussions
> are archived on \path|shsu.edu:[twg.tds]|).
>
> Delete `From About...: '. Delete parentheses around the second sentence.
Check.
> CTAN: means...
>
> In this document, `CTAN:' means the root of a anonymous ftp CTAN
> tree. This is both a host name and a directory name. For example:
> sunsite.unc.edu:/pub/packages/TeX
> ftp.tex.ac.uk:/tex-archive
> ftp.uni-bielefeld.de:pub/tex
> finger ctan@ftp.shsu.edu for a complete list of CTAN sites.
Check.
> Karl says:
> Let's point to ftp.math.utah.edu:pub/tex/bib for a huge bibtex
> collection (both db's and styles).
>
> ftp.math.utah.edu:pub/tex/bib has a huge BibTeX collection, both
> databases and styles.
Check.
> Unix Site-Coordinator for the distribution of {\TeX} from Robert
>
> No - here.
Check.
> tools and author systems. Active {\TeX}ie since 1981; Secretary of DVI
>
> \abbr{DVI}
Check.
> TUG TWGs, a founding member of \abbr{dante}
>
> \abbr{TUG TWG}
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 09:19:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 10:18:14 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161418.KAA20913@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: 0.72 [sic!] comments
Reply-To: TWG-TDS@SHSU.edu
> ** bookinfo.sgm **
>
> <corpauthor>The TUG Working Group on a &TeX; Directory Structure (TWG-TDS)</>
>
> results in an overfull hbox
Fixed. Removed The.
> <para>
> This document is available in several formats:
>
> I fully agree with Karl that this list should be improved. First list
> the general source (ftp://jasper.ora.com/pub/twg-tds/), then list all
> available formats in a table or varlist where each entry has one line.
Done.
> ** intro.sgm **
>
> <para>
> In this document, ``<filename>/</>'' is used to separate filename
> components; for example, <filename>texmf/fonts/</>…).
>
> Discard `)' or add `('.
Fixed.
> ----------------------------------------
>
> ** basics.sgm **
>
> See <xref linkend="subsearchsyntax"> for a list.
>
> Your SGML backend should add ties between `Section' & the number. Here
> is an example where a line-break occurred.
Check.
> <para>
> The root of the &tds; should be a directory containing only
> &TeX;-related materials. In this document, we shall designate this
> directory ``<replaceable>texmf</>,'' but the actual name of the directory is
> up to the installer. On <acronym>PC</> networks, for example, this
> could map to a logical drive specification such as <filename>T:</>.
> </para>
>
> Don't use <replaceable>texmf</> here, you use <filename>texmf</>
> elsewhere. And please use single quotes here and put the comma
> outside the quotes -- we mark a term and have to be precise. (I have
> nothing against double quotes and classic quote punctuation for
> quotations, btw.)
Ok.
> And how about adding
>
> We recommend naming the directory of the system-wide &TeX;
> installation <filename>texmf</>, if it is not placed at some
> top-level directory.
Check.
> help/ meta-information
> . ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
>
> file name with more than 8-chars
TeX-index -> TeXindex
>
> general/ across programs, generalities
> . componen/ <citetitle>Components of &TeX;</>
>
> Please name that texcomp/.
Check.
> <format>/ name of a format (<filename>latex</> example follows)
> . misc/ for single-file packages
>
> for single-file package documentation
> [it's not relevant if the package was in a single file]
Check.
> latex/
>
> Here I would prefer a styles/ directory for the misc/ directory, btw.
Huh?
> generic/ for non-format specific &TeX; packages
> . . german/ <filename>germdoc</>
>
> Skip of two indentation units at once?!
Oops.
> tex/ <filename>texbook.tex</>, <filename>gentle.tex</>, etc.
>
> The actual text says texbook.tex goes to doc/general/.
Check.
> metafont/ <filename>mfbook.tex</>, <filename>metafont-for-beginners</>, etc.
>
> Same here. And the other filename breaks the 8 chars limit.
metafont-for-beginners -> mf4begin
> info/ GNU info files, made from &TeXinfo; sources
>
> `Info' [uppercase i], as per request of FSF in the Texinfo manual.
Check.
> General: Some documents are listed with, some are listed without
> extensions. I would prefer a unique treatment.
Me too. I'm going to kill the extensions.
> ** distrib.sgm **
>
> <programlisting>
> martian-1.0/read.me
>
> As a developer who creates a source-distribution, I wouldn't put the
> tfm file in a separate directory.
Ok.
> ** example.sgm **
>
> [Not a good name for that file, should be named summary.sgm]
Yeah, it's not the only badly named SGML file. I'll fix that for the
final release.
> <programlisting role=tdssummary>
> doc/ see <xref linkend=docexample>
>
> see table on <pageref>.
> [You have to use a \pageref here, to the \label inserted above.]
I just ref the section...
> . . . . <mode>/ type of output device (for pk and gf only)
> . . . . . <dpi>/ font resolution (for pk and gf only)
>
> uppercase monospaced PK & GF, as elsewhere in the document.
Yep.
> ----------------------------------------
>
> ** impissue.sgm **
>
> <para>
> Once installable forms of key &tds;-compliant packages are ready,
>
> are more widespread
> [There exist installable forms, e.g., in teTeX and in my TDS example
> installation.]
Check.
> I would prefer to have here a more `standard' citation. With author,
> publisher, etc.
Me too.
> Should Michael's Gentle Introduction and my TeX Components listed here
> as well?
Yes.
> That's it for today. (Still waiting for your comments on the layout. :-)
I'm very happy with it.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 09:19:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 10:18:14 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161418.KAA20913@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: 0.72 [sic!] comments
Reply-To: TWG-TDS@SHSU.edu
> ** bookinfo.sgm **
>
> <corpauthor>The TUG Working Group on a &TeX; Directory Structure (TWG-TDS)</>
>
> results in an overfull hbox
Fixed. Removed The.
> <para>
> This document is available in several formats:
>
> I fully agree with Karl that this list should be improved. First list
> the general source (ftp://jasper.ora.com/pub/twg-tds/), then list all
> available formats in a table or varlist where each entry has one line.
Done.
> ** intro.sgm **
>
> <para>
> In this document, ``<filename>/</>'' is used to separate filename
> components; for example, <filename>texmf/fonts/</>…).
>
> Discard `)' or add `('.
Fixed.
> ----------------------------------------
>
> ** basics.sgm **
>
> See <xref linkend="subsearchsyntax"> for a list.
>
> Your SGML backend should add ties between `Section' & the number. Here
> is an example where a line-break occurred.
Check.
> <para>
> The root of the &tds; should be a directory containing only
> &TeX;-related materials. In this document, we shall designate this
> directory ``<replaceable>texmf</>,'' but the actual name of the directory is
> up to the installer. On <acronym>PC</> networks, for example, this
> could map to a logical drive specification such as <filename>T:</>.
> </para>
>
> Don't use <replaceable>texmf</> here, you use <filename>texmf</>
> elsewhere. And please use single quotes here and put the comma
> outside the quotes -- we mark a term and have to be precise. (I have
> nothing against double quotes and classic quote punctuation for
> quotations, btw.)
Ok.
> And how about adding
>
> We recommend naming the directory of the system-wide &TeX;
> installation <filename>texmf</>, if it is not placed at some
> top-level directory.
Check.
> help/ meta-information
> . ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
>
> file name with more than 8-chars
TeX-index -> TeXindex
>
> general/ across programs, generalities
> . componen/ <citetitle>Components of &TeX;</>
>
> Please name that texcomp/.
Check.
> <format>/ name of a format (<filename>latex</> example follows)
> . misc/ for single-file packages
>
> for single-file package documentation
> [it's not relevant if the package was in a single file]
Check.
> latex/
>
> Here I would prefer a styles/ directory for the misc/ directory, btw.
Huh?
> generic/ for non-format specific &TeX; packages
> . . german/ <filename>germdoc</>
>
> Skip of two indentation units at once?!
Oops.
> tex/ <filename>texbook.tex</>, <filename>gentle.tex</>, etc.
>
> The actual text says texbook.tex goes to doc/general/.
Check.
> metafont/ <filename>mfbook.tex</>, <filename>metafont-for-beginners</>, etc.
>
> Same here. And the other filename breaks the 8 chars limit.
metafont-for-beginners -> mf4begin
> info/ GNU info files, made from &TeXinfo; sources
>
> `Info' [uppercase i], as per request of FSF in the Texinfo manual.
Check.
> General: Some documents are listed with, some are listed without
> extensions. I would prefer a unique treatment.
Me too. I'm going to kill the extensions.
> ** distrib.sgm **
>
> <programlisting>
> martian-1.0/read.me
>
> As a developer who creates a source-distribution, I wouldn't put the
> tfm file in a separate directory.
Ok.
> ** example.sgm **
>
> [Not a good name for that file, should be named summary.sgm]
Yeah, it's not the only badly named SGML file. I'll fix that for the
final release.
> <programlisting role=tdssummary>
> doc/ see <xref linkend=docexample>
>
> see table on <pageref>.
> [You have to use a \pageref here, to the \label inserted above.]
I just ref the section...
> . . . . <mode>/ type of output device (for pk and gf only)
> . . . . . <dpi>/ font resolution (for pk and gf only)
>
> uppercase monospaced PK & GF, as elsewhere in the document.
Yep.
> ----------------------------------------
>
> ** impissue.sgm **
>
> <para>
> Once installable forms of key &tds;-compliant packages are ready,
>
> are more widespread
> [There exist installable forms, e.g., in teTeX and in my TDS example
> installation.]
Check.
> I would prefer to have here a more `standard' citation. With author,
> publisher, etc.
Me too.
> Should Michael's Gentle Introduction and my TeX Components listed here
> as well?
Yes.
> That's it for today. (Still waiting for your comments on the layout. :-)
I'm very happy with it.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 12:24:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 16:12:49 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950516161249.214092d0@vms.rhbnc.ac.uk>
Subject: RE: 0.74 comments
>> Are there formats with non-Plain catcodes?
Undoubtedly. Lollipop almost certainly; ATML for sure; there must be
many others of which few are aware...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 12:48: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: <199505161747.TAA07509@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.74 comments
To: TWG-TDS@SHSU.edu
Date: Tue, 16 May 1995 19:47:20 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> (If I find in later mail that Joachim has made the margins
> larger, I'll put it back ;-)
I haven't made it larger (yet), as I don't know what to use for
American paper sizes. I'm printing on A4 paper which is more
narrow. ;-) Karl or Norm -- what is a good text width to use?
> > Thus, for almost every format, it is correct to
> >
> > 1) Are there any exceptions, or can the `almost' be deleted?
>
> Are there formats with non-Plain catcodes?
Lots. The most widespread one is Texinfo, I guess. (The least
widespread one might be a troff ms emulation package I wrote some
years ago. It worked, albeight slowly. :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 12:53:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 13:51:22 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161751.NAA29045@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.72 [sic!] comments
Reply-To: TWG-TDS@SHSU.edu
> . ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
>
> file name with more than 8-chars
>
> True, but we can't change the world here. Either drop the `TeX-index' or
> leave it, but don't change it.
Yeah, you're right.
> tex/ <filename>texbook.tex</>, <filename>gentle.tex</>, etc.
>
> The actual text says texbook.tex goes to doc/general/.
>
> Change the text. texbook.tex should go in doc/tex. If it doesn't go
> there, what would?!
Ok.
> Should Michael's Gentle Introduction and my TeX Components listed here
>
> texkomp, sure, since it talks about how things fit together.
> Send Norm the text you want, and I'm sure he'll add it.
> gentle, no, it talks about how to use plain more than anything else.
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 12:58:04 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505161757.TAA07523@spice.iti.informatik.th-darmstadt.de>
Subject: 8 chars filenames (was: 0.72 [sic!] comments)
To: TWG-TDS@SHSU.edu
Date: Tue, 16 May 1995 19:57:10 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> > . ctan/ info about CTAN sites, <filename>TeX-index</>, etc.
> >
> > file name with more than 8-chars
>
> TeX-index -> TeXindex
>
> > metafont/ <filename>mfbook.tex</>, <filename>metafont-for-beginners</>, etc.
> >
> > filename breaks the 8 chars limit.
>
> metafont-for-beginners -> mf4begin
Karl argued in the mean time that the long names are those on CTAN.
I see a conflict here: Do we want to mention file names as they will
(might) be on CDs? Then we have to shorten them. Or do we want to
mention filenames as `representatives' [sp?] of documents? Then we may
use the long names or may even use <citetitle> (or however this tag
was named).
Btw, my comment triggered questions:
> > latex/
> >
> > Here I would prefer a styles/ directory for the misc/ directory, btw.
>
> Huh?
Well, it's triggered from the reaction of my users.
They didn't look in latex/misc/ for styles documentation at first.
They thought this is a place for miscellaneous (`other') stuff. When
I asked them ``what other stuff'', they came up with `internal coding
guidelines', `internal documentation', etc. I.e., they equated `misc'
with `not so interesting for us'.
I thought latex/styles/ is clearer for them. Single-file documents
would just be put there, multi-file documents will get a
subdirectory. This way a directory listing has one entry per
document. (In the doc/ area we don't search by programs and can
therefore break the `either dirs or files' rule we obey in the rest
of the TDS.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:07:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:05:09 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161805.OAA29391@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
> Might this document go here as well, i.e. help/tds once it is finished?
>
> tds.tex is not meta-information.
> (In retrospect, the distinction between help and doc was probably dubious.)
>
> Come to think, I think the tds stuff should go in /tex-archive/doc/tds,
> not /tex-archive/tds. Why should we get our own top-level directory?
Sounds fair to me.
>
> Maybe it would be better to give a verbal description instead of raw
> filenames? What about:
>
> I think most people know these things by the filenames.
> At least the ones who are likely to care.
> And the idea is to tell texadmins what files we're proposing go in what
> directories, so it's best to be specific, I think.
Ok.
> kpathsea/
> What about some description for this? Personally, I find `kpathsea'
>
> I already said to drop it.
Gone.
> . mft/ style files for MFT
>
> (Personally, I'd even prefer tex/plain/mft because it's tex/plain/base
>
> The ``right'' place is texmf/mft. I guess there's not much difference
> between two different wrong places (tex/mft and tex/plain/mft), so I
> don't object to moving it. It's not current practice, though.
Let's leave it /tex/mft since it's wrong but current practice.
> lumping them all under
> "ams" at least does make a clear statement that we accept
>
> I think we should keep doc/ams as it is. It is not completely
> consistent, but the doc tree cannot be rationalized completely, nor does
> it need to be. Putting all ams stuff under doc/ams follows current
> practice, makes things reasonably straightforward to find, and keeps bb
> happy :-).
Yep.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:11:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:10:31 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161810.OAA29603@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: more 0.74 comments
Reply-To: TWG-TDS@SHSU.edu
> > \sourcefile{bibtex.sgm}
> > \formatterfile{bibtex.tex}
> > \section{{\protect\BibTeX}}
>
> > {\protect\BibTeX} database files shall be stored in \path|texmf/bibtex/bib|.
> > {\protect\BibTeX} style files shall be stored in \path|texmf/bibtex/bst|.
>
> Can we make this two paragraphs or maybe two items in a list environment?
> It would be more consistent to have separte items or paragraph for every
> directory throughout all sections.
Done.
> > \sourcefile{doc.sgm}
> > \formatterfile{doc.tex}
> > \section{Documentation}
>
> latex/
> . base/ \path|ltnews*|, \path|*guide|, etc.
> . . graphics/ \path|grfguide|
> generic/ for non-format specific {\TeX} packages
> . . german/ \path|germdoc|
> . . babel/
> <program>/ {\TeX} applications, by name (examples follow)
>
> You still haven't fixed the indentation levels here! (Or did my last mail
> got through too late?) In case you missed it: graphics/ is not a subdir
> of base/, it should be at the same level. Likewise for german/ and babel/
> there should be only one level of indentation.
Fixed now. Thanks!
> Another comment on the doc tree: Did anybody else notice that general/
> and generic/ end up next to each other on systems that automatically
> sort directories alphabetically? I'm somewhat worried that this might
> turn out as a constant source of confusion for many users and admins.
> At my site, I tried to avoid this by uppercasing General/ and Help/,
> so that they show up first when sorted, but this isn't an universal
> solution. Any better ideas? Or any suggestions for renaming something?
It's a good point, but I don't have any suggestions...
> The reference to these documents seems somewhat unmotivated now that
> they are no longer cited by title in the MetaPost section (just by
> filename in the doc tree). Should they remain or should they go?
> Should texbook.tex and mfbook.tex be mentioned here as well?
They should probably go.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:11:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:10:31 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161810.OAA29603@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu
Subject: more 0.74 comments
Reply-To: TWG-TDS@SHSU.edu
> > \sourcefile{bibtex.sgm}
> > \formatterfile{bibtex.tex}
> > \section{{\protect\BibTeX}}
>
> > {\protect\BibTeX} database files shall be stored in \path|texmf/bibtex/bib|.
> > {\protect\BibTeX} style files shall be stored in \path|texmf/bibtex/bst|.
>
> Can we make this two paragraphs or maybe two items in a list environment?
> It would be more consistent to have separte items or paragraph for every
> directory throughout all sections.
Done.
> > \sourcefile{doc.sgm}
> > \formatterfile{doc.tex}
> > \section{Documentation}
>
> latex/
> . base/ \path|ltnews*|, \path|*guide|, etc.
> . . graphics/ \path|grfguide|
> generic/ for non-format specific {\TeX} packages
> . . german/ \path|germdoc|
> . . babel/
> <program>/ {\TeX} applications, by name (examples follow)
>
> You still haven't fixed the indentation levels here! (Or did my last mail
> got through too late?) In case you missed it: graphics/ is not a subdir
> of base/, it should be at the same level. Likewise for german/ and babel/
> there should be only one level of indentation.
Fixed now. Thanks!
> Another comment on the doc tree: Did anybody else notice that general/
> and generic/ end up next to each other on systems that automatically
> sort directories alphabetically? I'm somewhat worried that this might
> turn out as a constant source of confusion for many users and admins.
> At my site, I tried to avoid this by uppercasing General/ and Help/,
> so that they show up first when sorted, but this isn't an universal
> solution. Any better ideas? Or any suggestions for renaming something?
It's a good point, but I don't have any suggestions...
> The reference to these documents seems somewhat unmotivated now that
> they are no longer cited by title in the MetaPost section (just by
> filename in the doc tree). Should they remain or should they go?
> Should texbook.tex and mfbook.tex be mentioned here as well?
They should probably go.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:14:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:13:13 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161813.OAA29911@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.74 comments
Reply-To: TWG-TDS@SHSU.edu
> I haven't made it larger (yet), as I don't know what to use for
> American paper sizes. I'm printing on A4 paper which is more
> narrow. ;-) Karl or Norm -- what is a good text width to use?
Um, 6.5 inches leaves an inch on each side, but it's pretty wide.
I took out the "The" so maybe it'll fit now.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "A little sunlight is the best disinfectant." --
Production Tools Specialist | Justice Louis Brandeis
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:45:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:05:09 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161805.OAA29391@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
> Might this document go here as well, i.e. help/tds once it is finished?
>
> tds.tex is not meta-information.
> (In retrospect, the distinction between help and doc was probably dubious.)
>
> Come to think, I think the tds stuff should go in /tex-archive/doc/tds,
> not /tex-archive/tds. Why should we get our own top-level directory?
Sounds fair to me.
>
> Maybe it would be better to give a verbal description instead of raw
> filenames? What about:
>
> I think most people know these things by the filenames.
> At least the ones who are likely to care.
> And the idea is to tell texadmins what files we're proposing go in what
> directories, so it's best to be specific, I think.
Ok.
> kpathsea/
> What about some description for this? Personally, I find `kpathsea'
>
> I already said to drop it.
Gone.
> . mft/ style files for MFT
>
> (Personally, I'd even prefer tex/plain/mft because it's tex/plain/base
>
> The ``right'' place is texmf/mft. I guess there's not much difference
> between two different wrong places (tex/mft and tex/plain/mft), so I
> don't object to moving it. It's not current practice, though.
Let's leave it /tex/mft since it's wrong but current practice.
> lumping them all under
> "ams" at least does make a clear statement that we accept
>
> I think we should keep doc/ams as it is. It is not completely
> consistent, but the doc tree cannot be rationalized completely, nor does
> it need to be. Putting all ams stuff under doc/ams follows current
> practice, makes things reasonably straightforward to find, and keeps bb
> happy :-).
Yep.
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
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:53:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:52:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505161852.AA07297@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: line length
> I haven't made it larger (yet), as I don't know what to use for
> American paper sizes. I'm printing on A4 paper which is more
> narrow. ;-) Karl or Norm -- what is a good text width to use?
Um, 6.5 inches leaves an inch on each side, but it's pretty wide.
I took out the "The" so maybe it'll fit now.
The `The' will fit, but that's not the only point.
The current line width is a shade over 4.5in -- make that 29pc in
non-U.S.-centric units -- and that's *really* narrow. For regular
U.S. 8.5x11 paper, a line width of anywhere from 5.5in up to 6.5in will
be comfortable. As Norm says, 6.5 is a bit wide. 4.5 is too narrow.
A4 isn't *that* much narrower than 8.5x11, so maybe some width in
between (5.5in = 33pc) would work reasonably for both?
Looking forward to the next draft ...
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:54:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:52:08 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505161852.AA07288@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: more 0.74 comments
> Another comment on the doc tree: Did anybody else notice that general/
> and generic/ end up next to each other on systems that automatically
> sort directories alphabetically? I'm somewhat worried that this might
Let me argue the opposite direction -- the fact that they are close
together in a listing means it is obvious we are making a distinction,
and interested people will care enough to find out what. I don't think
we need to change this.
There should be a README in each directory of the sample tree saying
what that directory is for. I confess I haven't checked if this is
already the case.
> The reference to these documents seems somewhat unmotivated now that
> they are no longer cited by title in the MetaPost section (just by
They should probably go.
I agree.
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 13:54:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 14:52:13 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505161852.AA07308@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 8 chars filenames (was: 0.72 [sic!] comments)
I see a conflict here: Do we want to mention file names as they will
(might) be on CDs? Then we have to shorten them. Or do we want to
mention filenames as `representatives' [sp?] of documents? Then we may
What we do *not* want to do, IMHO, is make up 8.3 versions of names that
do not actually exist. Let the authors do that.
As I pointed out earlier, however, I think it's important and useful to
mention real files, not just document titles, in our examples. (Although
I don't say that we have to be 100% consistent about it.)
So that leaves us with only referring to documents which already have
unambiguous names. I think that's already pretty much the case. Perhaps
the ones which are not 8.3 now could either be dropped (if there's
already other examples in that category) or replaced by the cited
document title.
They didn't look in latex/misc/ for styles documentation at first.
They thought this is a place for miscellaneous (`other') stuff. When
I didn't realize you were talking about the doc/ tree, not the tex/
tree. Sorry. I don't object to renaming `misc' to `styles' in the `doc'
tree. Seems reasonable. (I do object to doing so in the tex tree, but I
think (hope!) no one is proposing that.)
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 14:36:36 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 16 May 1995 12:35:43 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505161935.MAA20940@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 8 chars filenames (was: 0.72 [sic!] comments)
Given that we are dealing with an archive with a long history,
I think we can assume that the archivers will have heard about
cases of genuine incompatibility from anguished users who found
themselves unable to retrieve TeX-index and metafont-for-beginners.
I assume that these will come through and land on the importing
8-character system as TEX-INDE and METAFONT respectively.
We might note that this will happen, but I think that we had
better stay out of the attempt to reform existing archives.
I brought this sort of thing up in an old query about doc files,
and somone---I had remembered it was Joachim---made approximately
this point.
Let's simply admit that overlength names exist on well-known archives,
have existed for some time, and may continue to exist for some time.
If the TDS exerts any real moral effect, the number of overlength
names on well-known archives will diminish. Meanwhile, caveat FTP-er.
We are not making the situation worse in any way than it is right now,
and we hope that we are pointing the way to making it better.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 14:47:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 16 May 1995 15:46:11 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505161946.PAA04576@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.75 available: PLEASE READ!
Reply-To: TWG-TDS@SHSU.edu
from the usual place: ftp://jasper.ora.com/private/twg-tds/tds.*,*.sgm
(I've removed the styles from that directory; you need Joachim's tdsguide
to format it yourself).
- I plan to update the Related References section.
- I hope Joachim will provide another tdsguide style with wider margins
When those two things are done, I would like to make public release 0.99.
Hopefully that will occur *THIS WEEK*.
If you find errors or omissions that you feel should prevent a public
release, please tell me. (Tell me about minor problems, too, but I
think we'll end up going to a public release before every single little
nit is picked.)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 16:27:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505162127.XAA07641@spice.iti.informatik.th-darmstadt.de>
Subject: Re: more 0.74 comments
To: TWG-TDS@SHSU.edu
Date: Tue, 16 May 1995 23:27:05 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> There should be a README in each directory of the sample tree saying
> what that directory is for. I confess I haven't checked if this is
> already the case.
No, it isn't. I'm going to add it -- at least for the upper two
levels. To be honest, I don't know if I want to do it for each and
every macro package subdirectory.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 16:30:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505162130.XAA24806@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 8 chars filenames (was: 0.72 [sic!] comments)
To: TWG-TDS@SHSU.edu
Date: Tue, 16 May 1995 23:30:00 +0200 (MESZ)
Content-Type: text
Pierre wrote:
>
> [8-character system]
>
> I brought this sort of thing up in an old query about doc files,
> and somone---I had remembered it was Joachim---made approximately
> this point.
You're right, I'm arguing incosistently here. Let the long names in
-- those who can't grasp the possible transformation to 8.3 should
get a real operating system where they don't need to grasp it. ;-)
Joachim
PS: A new style file will be available tomorrow. It's 23:30 now, and I
want to finish for today...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 16 May 1995 16:44:20 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505162127.XAA07641@spice.iti.informatik.th-darmstadt.de>
Subject: Re: more 0.74 comments
To: TWG-TDS@SHSU.edu
Date: Tue, 16 May 1995 23:27:05 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> There should be a README in each directory of the sample tree saying
> what that directory is for. I confess I haven't checked if this is
> already the case.
No, it isn't. I'm going to add it -- at least for the upper two
levels. To be honest, I don't know if I want to do it for each and
every macro package subdirectory.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 06:00:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 06:57:57 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171057.AA19368@ra.cs.umb.edu>
To: twg-tds@shsu.edu, texhax-request@tex.ac.uk
Subject: major oops!
Oops, my just-sent msg with comments went to texhax! (Don't ask.)
Be sure your replies don't include that address.
David, aren't you the texhax keeper? Anyway, whoever is, please please
*please* don't post it in the digest. Thanks.
Sorry.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 06:01:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 06:54:46 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171054.AA19360@ra.cs.umb.edu>
To: twg-tds@shsu.edu, texhax@tex.ac.uk
Subject: 0.75 comments
My only comment on the content is about the tex/hyphen/ directory.
Weren't we going to move that under tex/generic/?
Otherwise, I'm worried that search paths will end up including it
explicitly, which will be a pain. Does anyone object?
Actually, maybe we already agreed on this, since it changed in the
sample tree. My comments below indicate other places that need to
change, in that case. This should be done before release.
About the announcement:
1) I'd like to see it before it's posted.
2) Here's the first list of places I can think of for posting:
texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu.
I will repost it to tex-k with some comments about my expected
implementation date, so don't bother sending it there.
I assume Sebastian will communicate our result to the board :-).
3) For the next draft/final release (depending on volume of
comments/concerns), how about ``shortly after TUG 95''? I don't see
any reason to impose artificial deadline pressure on ourselves by
setting an exact date.
Hopefully Joachim's new stuff will fix the formatting concerns.
Just a few other comments, hopefully all non-controversial:
We encourage
implementors to provide subdirectory searching (at the option of the
installer and user) for all paths.
I think this should be deleted. We already said we require it for searching
for ``an input file'', which is ``all paths'' already. (We could not
require it for some particular file types, but I don't think we should.)
The \abbr{TDS} does \emphasis{not} require monocase names,
Append `however,'.
, if it is not placed at some
top-level directory.
As stated, this is wrong. (`t:' is not a top-level directory, which is
presumably what we're trying to get at.) Suggest deletion, or
replacement with `where possible'.
this directory within the filesystem is site-dependent. On
many systems, this may be at the root of the filesystem; on
I know I was the one who said to use `filesystem', but now I'm back to
`file system', because usage here is not as a single partition-on-a-disk.
Please change back. Sorry.
the \abbr{TDS}. For example, Unix {\TeX} administrators may wish to place all
Delete `Unix'. (``manual pages'' then becomes somewhat dubious, but I'm
willing to live it; people do use man under DOS ...)
abbreviation for SPARC SunOS 4.1.3).
\abbr{SPARC}
\item
\path|hyphen| is reserved for
hyphenation patterns. These are used only by {\iniTeX} when a
format file is being built.
If the proposal to move is adopted, I think this should become a
paragraph under package/:
\item
\path|hyphen| is reserved for
hyphenation patterns. These are used only by {\iniTeX} when a
format file is being built. This directory need exist only under the
`generic' format directory.
\path|PK| files need additional structure, described in the next
\path|PK| and \path|GF| files ...
The \path|PK| bitmaps for each font require special
Delete \path|PK|.
distribution from CTAN, the required information is already in your
\abbr{CTAN}
understand. In order to reduce the confusion, the \abbr{TDS} specifies directories
Delete `In order to reduce the confusion,'.
(What confusion? I'm not confused :-)
Contains {\protect\BibTeX} database files.
Contains {\protect\BibTeX} style files.
No capital C.
texmf/tex/hyphen/marthyph.tex
This would change line that would change to generic/hyphen.
. . hyphen/ hyphenation patterns
Wait a minute, it's already moved in this tree! I guess we already agreed
on this.
number of subdirectories present on the system. (Assuming that the
database is kept up to date, if the filename is not present in the
database, performance is irrelevant: the file won't be found at all.)
Delete the parenthetical. It's not true, and we don't need to say
anything about it.
via a separate \systemitem{ENVIRONVAR}{TEXFONTS\_SUBDIR} environment
Came out as a roman underscore instead of the tt char.
\replaceable{t:$\backslash$directory**}
Suggest removing the \replaceable in all of these examples. It makes
things look funny, and in some cases wrong. Too much trouble/confusing
to typeset the []'s and /'s and :'s and such in tt and the names in
sltt, so instead suggest a sentence at the beginning: `The examples here
do not use the \replaceable{replaceable} font in the interest of clarity.'
Or some such b.s.
finger \path|ctan@ftp.shsu.edu| for a complete list of CTAN sites.
There's something funny about `finger' in roman at the beginning of a
sentence. Change to typewriter or capitalize.
\path|ftp.math.utah.edu:pub/tex/bib| has a huge {\protect\BibTeX} collection,
both databases and styles.
This should probably be the last thing. Also, modes.mf should probably
come before Components of TeX. (Sorry, Joachim :-)
\citetitle{Filenames for {\TeX} fonts} can be found in the CTAN archives
in the \path|doc/fontname| directory.
... is available from CTAN:doc/fontname.
\citetitle{Components of {\TeX}} by Joachim Schrod.
... is available from CTAN:doc/components-of-TeX.
This distribution includes recommended mode names.
includes eight-character-or-fewer recommended
That's it!
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 07:47:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 13:46:28 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950517134628.21a010e3@vms.rhbnc.ac.uk>
Subject: RE: 0.75 comments
>> Just a few other comments, hopefully all non-controversial:
>> We encourage
>> implementors to provide subdirectory searching (at the option of the
>> installer and user) for all paths.
>> I think this should be deleted. We already said we require it for searching
>> for ``an input file'', which is ``all paths'' already. (We could not
>> require it for some particular file types, but I don't think we should.)
With respect, I disagree: few would think of TFM files as being `input' files,
even though strictly speaking they are just that; I recommend stet.
>> \item
>> \path|hyphen| is reserved for
>> hyphenation patterns. These are used only by {\iniTeX} when a
>> format file is being built.
The last seven words are wrong (IniTeX can use patterns whether or not
a format is being built); I recommend ``These are normally used only by
IniTeX.''
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 07:55:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 08:55:08 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171255.IAA28397@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.75 comments
Reply-To: TWG-TDS@SHSU.edu
> My only comment on the content is about the tex/hyphen/ directory.
> Weren't we going to move that under tex/generic/?
>
> Otherwise, I'm worried that search paths will end up including it
> explicitly, which will be a pain. Does anyone object?
>
> Actually, maybe we already agreed on this, since it changed in the
> sample tree. My comments below indicate other places that need to
> change, in that case. This should be done before release.
I thought we had. I'll make the changes you suggest...
> About the announcement:
> 1) I'd like to see it before it's posted.
Absolutely.
> 2) Here's the first list of places I can think of for posting:
> texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu.
> I will repost it to tex-k with some comments about my expected
> implementation date, so don't bother sending it there.
> I assume Sebastian will communicate our result to the board :-).
Cool.
> 3) For the next draft/final release (depending on volume of
> comments/concerns), how about ``shortly after TUG 95''? I don't see
> any reason to impose artificial deadline pressure on ourselves by
> setting an exact date.
Seems fair to me. I expect to get a few tomatoes heaved my way in St. Pete.
> We encourage
> implementors to provide subdirectory searching (at the option of the
> installer and user) for all paths.
>
> I think this should be deleted. We already said we require it for searching
> for ``an input file'', which is ``all paths'' already. (We could not
> require it for some particular file types, but I don't think we should.)
Gone.
> The \abbr{TDS} does \emphasis{not} require monocase names,
>
> Append `however,'.
Where?
The &ISO9660; format (described below) does not allow mixed-case
names. The &tds; does <emphasis>not</> require monocase names,
although it is clear that mixed-case filenames may cause problems in
some environments.
Are you really suggesting "... monocase names, however, although it ..."
> , if it is not placed at some
> top-level directory.
>
> As stated, this is wrong. (`t:' is not a top-level directory, which is
> presumably what we're trying to get at.) Suggest deletion, or
> replacement with `where possible'.
I went with "where possible".
> this directory within the filesystem is site-dependent. On
> many systems, this may be at the root of the filesystem; on
>
> I know I was the one who said to use `filesystem', but now I'm back to
> `file system', because usage here is not as a single partition-on-a-disk.
> Please change back. Sorry.
Okey dokey.
> the \abbr{TDS}. For example, Unix {\TeX} administrators may wish to place all
>
> Delete `Unix'. (``manual pages'' then becomes somewhat dubious, but I'm
> willing to live it; people do use man under DOS ...)
Ok.
> abbreviation for SPARC SunOS 4.1.3).
>
> \abbr{SPARC}
Check.
> \item
> \path|hyphen| is reserved for
> hyphenation patterns. These are used only by {\iniTeX} when a
> format file is being built.
>
> If the proposal to move is adopted, I think this should become a
> paragraph under package/:
>
> \item
> \path|hyphen| is reserved for
> hyphenation patterns. These are used only by {\iniTeX} when a
> format file is being built. This directory need exist only under the
> `generic' format directory.
Sounds good to me.
> \path|PK| files need additional structure, described in the next
>
> \path|PK| and \path|GF| files ...
Ok.
> The \path|PK| bitmaps for each font require special
>
> Delete \path|PK|.
Check.
> distribution from CTAN, the required information is already in your
>
> \abbr{CTAN}
Check.
> understand. In order to reduce the confusion, the \abbr{TDS} specifies directories
>
> Delete `In order to reduce the confusion,'.
> (What confusion? I'm not confused :-)
Gone.
> Contains {\protect\BibTeX} database files.
> Contains {\protect\BibTeX} style files.
>
> No capital C.
Check.
> texmf/tex/hyphen/marthyph.tex
>
> This would change line that would change to generic/hyphen.
>
> . . hyphen/ hyphenation patterns
>
> Wait a minute, it's already moved in this tree! I guess we already agreed
> on this.
Yep, and changed.
> number of subdirectories present on the system. (Assuming that the
> database is kept up to date, if the filename is not present in the
> database, performance is irrelevant: the file won't be found at all.)
>
> Delete the parenthetical. It's not true, and we don't need to say
> anything about it.
Ok.
> via a separate \systemitem{ENVIRONVAR}{TEXFONTS\_SUBDIR} environment
>
> Came out as a roman underscore instead of the tt char.
Oops.
> \replaceable{t:$\backslash$directory**}
>
> Suggest removing the \replaceable in all of these examples. It makes
> things look funny, and in some cases wrong. Too much trouble/confusing
> to typeset the []'s and /'s and :'s and such in tt and the names in
> sltt, so instead suggest a sentence at the beginning: `The examples here
> do not use the \replaceable{replaceable} font in the interest of clarity.'
> Or some such b.s.
Ok, I'll give that a try.
>
> finger \path|ctan@ftp.shsu.edu| for a complete list of CTAN sites.
>
> There's something funny about `finger' in roman at the beginning of a
> sentence. Change to typewriter or capitalize.
Check.
> \path|ftp.math.utah.edu:pub/tex/bib| has a huge {\protect\BibTeX} collection,
> both databases and styles.
>
> This should probably be the last thing. Also, modes.mf should probably
> come before Components of TeX. (Sorry, Joachim :-)
check.
> \citetitle{Filenames for {\TeX} fonts} can be found in the CTAN archives
> in the \path|doc/fontname| directory.
>
> ... is available from CTAN:doc/fontname.
Check.
> \citetitle{Components of {\TeX}} by Joachim Schrod.
>
> ... is available from CTAN:doc/components-of-TeX.
check.
> This distribution includes recommended mode names.
>
> includes eight-character-or-fewer recommended
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 09:09:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 17 May 1995 10:06:13 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
To: TWG-TDS@SHSU.edu
Message-ID: <800719573.882200.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re hyphenation patterns, phil's phrasing
These are normally used only by IniTeX.
implies to me that they may be used somewhere else. not in any
other mode of tex, as far as i know. how about omitting "normally",
leaving only
These are used only by IniTeX.
?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 09:36:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 15:34:58 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950517153458.21a01c95@vms.rhbnc.ac.uk>
Subject: RE: 0.75 comments
>> re hyphenation patterns, phil's phrasing
>> These are normally used only by IniTeX.
>> implies to me that they may be used somewhere else. not in any
>> other mode of tex, as far as i know. how about omitting "normally",
>> leaving only
>> These are used only by IniTeX.
My point was that whilst we normally think of patterns being used only
by IniTeX, it is quite possible that some other adjunct of which we
are unaware (for example, a spelling checker) may also have been programmed
to use them. Indeed, I seem to recall that Patgen itself uses them when
in multi-pass mode. So I really do think that rather than stating categorically
``patterns are used only by IniTeX'', we would do better to assume that we
cannot possibly know the uses to which they are actually put, and therefore to
include the word `normally' as suggested.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 09:54:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 17 May 1995 10:06:13 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
To: TWG-TDS@SHSU.edu
Message-ID: <800719573.882200.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re hyphenation patterns, phil's phrasing
These are normally used only by IniTeX.
implies to me that they may be used somewhere else. not in any
other mode of tex, as far as i know. how about omitting "normally",
leaving only
These are used only by IniTeX.
?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 10:13:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 17 May 1995 11:12:09 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
To: TWG-TDS@SHSU.edu
Message-ID: <800723530.167200.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
re hyphenation patterns, initex and what is "normal", i concede.
stick with phil's
These are normally used only by IniTeX.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 11:01:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 11:59:00 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171559.AA21107@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
These are normally used only by IniTeX.
How about simply `These are used by initex.'
That leaves out the value judgment implied by `normally' :-).
(Or change it to `commonly' or `typically'.)
Again, I don't feel strongly, and promise not to complain no matter how
Norm has exercised his privilege (duty) as chair on this sentence :-).
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 11:01:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 11:57:06 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171557.AA21102@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: 0.75 comments
The &ISO9660; format (described below) does not allow mixed-case
names. The &tds; does <emphasis>not</> require monocase names,
although it is clear that mixed-case filenames may cause problems in
some environments.
Are you really suggesting "... monocase names, however, although it ..."
That is what I was suggesting, but I guess it's not right. Skip it.
This section still needs work, but it's time to ship.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 11:01:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 11:56:06 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171556.AA21049@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
>> I think this should be deleted. We already said we require it for searching
>> for ``an input file'', which is ``all paths'' already. (We could not
>> require it for some particular file types, but I don't think we should.)
With respect, I disagree: few would think of TFM files as being `input' files,
even though strictly speaking they are just that; I recommend stet.
I still think it will cause confusion to leave it in. Does deleting
`input' in the previous sentence make it better?
Anyway, I don't feel strongly. I'm willing to go with however Norm has
it in the next-and-final :-) draft.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 12:45:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171744.TAA14183@spice.iti.informatik.th-darmstadt.de>
Subject: TDS layout
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 17 May 1995 19:44:55 +0200 (MESZ)
Content-Type: text
The pre-release of a new tdsguide.cls revision exists; as usual in
ftp://ftp.th-darmstadt.de/pub/tex/TDS/misc/.
tdsguide.cls.gz -- new class, see below.
tds.dvi.gz -- 0.75 formatted with that class
tds-dist.tex.gz -- self-contained TDS TeX document
The complete macro distribution tdsguide-1.0.tar.gz has not been
updated yet.
Please don't redistribute the class yet. I can't access the system
where my CVS depot is currently, and I'll want to commit the changes
before `official' distribution. Then the macro distribution will get
updated as well, and tdsguide.cls.gz will get removed. I'll send a
respective mail to the list. OTOH, there seems to be some persons
who may think it's urgent and who want to have a look _now_ and not
tomorrow.
Changes:
-- Increase text width to 33pc. (Saves 2 pages & the overfull hbox in
the title.)
-- Use another typewriter font switch command. `\_' does the Right
Thing now (Karl mentioned that it got a roman underscore).
Norm, in \literal, \replaceable, etc., `\\' will yield a
typewriter backslash, not a line break. Please change your SGML
backend to transform backslashs to `\\' instead of `$\backslash$'.
The latter looks horrible in a typewriter environment.
Additional notes:
-- One should be sure to have current version of all used styles from
CTAN. Norm's DVI files have a spurious headline on the titlepage
that won't appear in my DVI files. I suspect that's due an old
version of fancyheadings.sty.
The next revision of the complete macro distribution will
therefore have all used style files in a subdir as well.
-- Can anybody tell me how I can convince the filecontents
environment to just look in the current directory? It should not
search the whole system for the style files that are part of the
self-containing TDS document, just the current dir.
Cheers,
Joachim
PS: Sebastian, your mirror of the TDS example distribution has
expanded the symlink macros->misc and doubled the directory contents.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 13:02:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171801.UAA15492@spice.iti.informatik.th-darmstadt.de>
Subject: more on 0.75
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 17 May 1995 20:01:28 +0200 (MESZ)
Content-Type: text
Obviously, some comments from my last mail got lost. Here we are
again. :-) (This time I'm working from a paper version, I have no
electronic version accessible.)
** 1.2 Conventions **
Superfluous `)' in 2nd line of 1st paragraph.
** 2.1 Subdirectory searching **
Still no tie between `Section' and number in last paragraph. Even if
this bad line-break disappears with the new text width, I would prefer
if it got fixed for future text changes.
** Doc tree summary **
2nd-to-last-line: html --> \abbr{HTML}
** 10. Summary **
texsys.cfg needs filename markup.
** A.1 Adoption of the TDS **
refers to an electronic available sample tree, referenced in App. C.
That reference must be added there.
** A.4 Subdirectory Searching Syntax **
[`_' in TEXFONTS_SUBDIR is fixed by new macros.]
Is emTeX syntax really `t:\directory**'? I would have suspected
`t:\directory\**'.
I agree with Karl that replaceable tags should not be used here.
Logos have to be inserted here
dvips -> <command>
emtex -> <application>
kpathsea -> ???? [Karl?]
vms -> &VMS;
xdvi -> <command>
(I'm guessing what has to be there; the same as in the rest of the
document.)
** C Related References **
Norm, I will send full texcomp reference tomorrow morning, after I
digged out the TeXline number where it was published originally.
--------------------
Do we transform the WD to a CD at the weekend?
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 13:48:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 14:45:06 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171845.OAA14222@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
Reply-To: TWG-TDS@SHSU.edu
> These are normally used only by IniTeX.
>
> How about simply `These are used by initex.'
> That leaves out the value judgment implied by `normally' :-).
> (Or change it to `commonly' or `typically'.)
A compromise! A compromise! Marvelous!
``These are typically used only by &iniTeX;.''
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 13:48:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 14:42:37 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171842.OAA14087@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: 0.75 comments
Reply-To: TWG-TDS@SHSU.edu
> >> Just a few other comments, hopefully all non-controversial:
>
> >> We encourage
> >> implementors to provide subdirectory searching (at the option of the
> >> installer and user) for all paths.
>
> >> I think this should be deleted. We already said we require it for searching
> >> for ``an input file'', which is ``all paths'' already. (We could not
> >> require it for some particular file types, but I don't think we should.)
>
> With respect, I disagree: few would think of TFM files as being `input' files,
> even though strictly speaking they are just that; I recommend stet.
I'm going to go with Phil on this one. The sentence may be redundant for
a small percentage of the audience, but it isn't wrong.
> >> \item
> >> \path|hyphen| is reserved for
> >> hyphenation patterns. These are used only by {\iniTeX} when a
> >> format file is being built.
>
> The last seven words are wrong (IniTeX can use patterns whether or not
> a format is being built); I recommend ``These are normally used only by
> IniTeX.''
I see there's more mail about this in my queue...
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, 17 May 1995 13:59:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 14:54:27 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171854.OAA14608@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: more on 0.75
Reply-To: TWG-TDS@SHSU.edu
> Obviously, some comments from my last mail got lost. Here we are
> again. :-) (This time I'm working from a paper version, I have no
> electronic version accessible.)
>
>
> ** 1.2 Conventions **
>
> Superfluous `)' in 2nd line of 1st paragraph.
Check.
> ** 2.1 Subdirectory searching **
>
> Still no tie between `Section' and number in last paragraph. Even if
> this bad line-break disappears with the new text width, I would prefer
> if it got fixed for future text changes.
Fixed. Actually, I ``fixed'' it for 0.75; I just fixed it in the wrong
place in my filter ;-)
> ** Doc tree summary **
>
> 2nd-to-last-line: html --> \abbr{HTML}
Check.
> ** 10. Summary **
>
> texsys.cfg needs filename markup.
Check.
> ** A.1 Adoption of the TDS **
>
> refers to an electronic available sample tree, referenced in App. C.
> That reference must be added there.
Joachim, I presume that this is your distribution being referenced.
How would you like it to appear in App C.
> ** A.4 Subdirectory Searching Syntax **
>
> [`_' in TEXFONTS_SUBDIR is fixed by new macros.]
Great!
> Is emTeX syntax really `t:\directory**'? I would have suspected
> `t:\directory\**'.
Um, hard to tell. It used to be t:\directory!!...
> I agree with Karl that replaceable tags should not be used here.
Gone.
> Logos have to be inserted here
> dvips -> <command>
Yep.
> emtex -> <application>
emtex -> emTeX
> kpathsea -> ???? [Karl?]
I'll go with <application> ;-)
> vms -> &VMS;
Check.
> xdvi -> <command>
Check.
> ** C Related References **
>
> Norm, I will send full texcomp reference tomorrow morning, after I
> digged out the TeXline number where it was published originally.
Ok.
> Do we transform the WD to a CD at the weekend?
What's a CD?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 13:59:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 14:54:27 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171854.OAA14608@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: twg-tds@SHSU.edu (TUG WG TeX Directory Structures)
Subject: more on 0.75
Reply-To: TWG-TDS@SHSU.edu
> Obviously, some comments from my last mail got lost. Here we are
> again. :-) (This time I'm working from a paper version, I have no
> electronic version accessible.)
>
>
> ** 1.2 Conventions **
>
> Superfluous `)' in 2nd line of 1st paragraph.
Check.
> ** 2.1 Subdirectory searching **
>
> Still no tie between `Section' and number in last paragraph. Even if
> this bad line-break disappears with the new text width, I would prefer
> if it got fixed for future text changes.
Fixed. Actually, I ``fixed'' it for 0.75; I just fixed it in the wrong
place in my filter ;-)
> ** Doc tree summary **
>
> 2nd-to-last-line: html --> \abbr{HTML}
Check.
> ** 10. Summary **
>
> texsys.cfg needs filename markup.
Check.
> ** A.1 Adoption of the TDS **
>
> refers to an electronic available sample tree, referenced in App. C.
> That reference must be added there.
Joachim, I presume that this is your distribution being referenced.
How would you like it to appear in App C.
> ** A.4 Subdirectory Searching Syntax **
>
> [`_' in TEXFONTS_SUBDIR is fixed by new macros.]
Great!
> Is emTeX syntax really `t:\directory**'? I would have suspected
> `t:\directory\**'.
Um, hard to tell. It used to be t:\directory!!...
> I agree with Karl that replaceable tags should not be used here.
Gone.
> Logos have to be inserted here
> dvips -> <command>
Yep.
> emtex -> <application>
emtex -> emTeX
> kpathsea -> ???? [Karl?]
I'll go with <application> ;-)
> vms -> &VMS;
Check.
> xdvi -> <command>
Check.
> ** C Related References **
>
> Norm, I will send full texcomp reference tomorrow morning, after I
> digged out the TeXline number where it was published originally.
Ok.
> Do we transform the WD to a CD at the weekend?
What's a CD?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 14:18:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 15:17:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171917.AA22689@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: more on 0.75
kpathsea -> ???? [Karl?]
I prefer plain roman for names, but Norm likes italics,
so he wins (for this document :-).
Norm, I will send full texcomp reference tomorrow morning, after I
digged out the TeXline number where it was published originally.
Reference? TeXline? Is that necessary? It's its current location on CTAN
that matters, and I already sent that to Norm. Whatever you want,
though, of course!
Do we transform the WD to a CD at the weekend?
CD?
Anyway, given the hyphen changes in the last round, I think we should
see one more before publicizing, so we have a release with no technical
changes.
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 14:26:29 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505171924.VAA28413@spice.iti.informatik.th-darmstadt.de>
Subject: Re: more on 0.75
To: TWG-TDS@SHSU.edu
Date: Wed, 17 May 1995 21:24:31 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Norm, I will send full texcomp reference tomorrow morning, after I
> digged out the TeXline number where it was published originally.
>
> Reference? TeXline? Is that necessary?
:-) no.
> Do we transform the WD to a CD at the weekend?
>
> CD?
Sorry, jargon.
WD == working document;
CD == committee draft (public `request for comment' stage);
DS == draft standard (voting stage);
*S == standard (with `*' == i [international] or n [national] or ...).
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 15:13:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 16:08:51 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505172008.QAA18205@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.76 READ AGAIN
Reply-To: TWG-TDS@SHSU.edu
One mo' time:
ftp://jasper.ora.com/private/twg-tds/tds.{ps,tex,dvi}
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Unable to locate coffee---operator halted.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 May 1995 15:45:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 May 1995 15:51:00 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505171951.PAA17753@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: more on 0.75
Reply-To: TWG-TDS@SHSU.edu
>
> Anyway, given the hyphen changes in the last round, I think we should
> see one more before publicizing, so we have a release with no technical
> changes.
>
Expect one more today.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Elvis is dead. Accept it.
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 02:47:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 95 09:48:16 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505180748.AA10108@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: more comments on 0.75
Two more late comments on draft 0.75 (Sorry, I haven't seen the
very latest yet, I'm always a bit behind, I'm afraid):
1. While I agree with dropping the file extensions for most files
in the doc tree figure, I'd strongly suggest keeping it for
amsfonts.faq und amslatex.faq. These are plain text files
rather than .tex files, so the extension is significant here.
2. In the related documentation appendix I'd suggest listing only
the three primary CTAN hosts instead of a somewhat arbitrary
selection from among the mirror sites. (Who's ever heard
of ftp.uni-bielefeld.de?)
So long,
Ulrik.
P.S. Concerning the target for the final version: What about
sheduling it for the time after TUG'95 but before EuroTeX'95.
This would allow for integrating comments received after the
TUG meeting, but presenting the final conclusions not too
long afterwards. Otherwise another year would go by before
the next large international TeX conference. Sounds sensible?
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 07:22:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 08:21:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181221.AA16519@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: more comments on 0.75
2. In the related documentation appendix I'd suggest listing only
the three primary CTAN hosts instead of a somewhat arbitrary
selection from among the mirror sites. (Who's ever heard
of ftp.uni-bielefeld.de?)
I chose a random selection precisely so people would be aware that there
*were* sites other than the primary ones. (And so people would see that
not everything started with /tex-archive.) However, perhaps this was
silly, and it would be better to list the primary sites only, or list
them plus some selected others from the other continents.
P.S. Concerning the target for the final version: What about
sheduling it for the time after TUG'95 but before EuroTeX'95.
When is it?
long afterwards. Otherwise another year would go by before
the next large international TeX conference. Sounds sensible?
If it can be done, sure. I think it's more important to get the content
right than to meet any particular date. I also think conferences as a
way of disseminating information are overrated, because only a minuscule
proportion of the people affected attend any given conference.
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 09:59:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181457.QAA13176@spice.iti.informatik.th-darmstadt.de>
Subject: it get's less... 0.76
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 18 May 1995 16:57:22 +0200 (MESZ)
Content-Type: text
[The new macros are committed now, a macro source distribution is
available as a tar.gz file.]
--------------------
** 10 Summary **
In the generic/ subsection -- please move hyphen/ in front of misc/.
Everywhere it's ordered alphabetically, except here.
** A.4 Subdirectory Searching Syntax **
You must not transform backslashs in \path arguments to
`$\backslash$'.
** C Related References **
A sample tree is available electronically from CTAN:\path|tds|.
--------------------
Joachim
PS: The latter is not completely true yet, I have to hash out the
procedure for automatic updates with Sebastian. (Hmm, consider: I
will eventually mirror the mail backlogs from shsu.edu:[twg.tds], and
CTAN will mirror it back from my site. Rather long way from shsu.edu
to ftp.shsu.edu... :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:00:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 11:59:29 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181559.AA17446@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: it get's less... 0.76
A sample tree is available electronically from CTAN:\path|tds|.
How about changing this to doc/tds?
As I said before, I don't see why we should get a top-level directory.
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:01:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 16:55:52 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950518165552.21a05302@vms.rhbnc.ac.uk>
Subject: RE: more on 0.75
>> Is emTeX syntax really `t:\directory**'? I would have suspected
>> `t:\directory\**'.
Where did the asterisks come from? I have been religiously tracking
updates to emTeX betas, and can find nothing in the DOC files to
suggest that the syntax has changed from trailing `!' & `!!'...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:06:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 95 12:05:06 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Message-ID: <9505181605.AA27467@owl.hq.ileaf.com>
To: twg-tds@shsu.edu
Subject: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
0.76 is looking good. There are a few typographic problems that preclude
it being the final version, but I don't see any content problems.
Here are the nits.
difficult: it is impossible to determine what files are used by
impossible => hard [nothing's impossible]
Naturally, this does not affect the format of names on the CD-ROM itself.
Delete `Naturally,'. [nothing's natural]
up to the installer. On \abbr{pc} networks, for example, this
Is `PC networks' really the right term here? How about `DOS machines'?
files which can also be used with {\LaTeX} or {\AMSTeX} as well as
Saying AMSTeX here gives the misleading impression that those are the
only two formats that counts (especially since we also point out AMSTeX
is compatible with plain). How about `and other formats' instead?
This directory need only exist
only exist => exist only
under the \literal{generic} format tree.
tree => directory
The \abbr{TDS} specifies the following:
following (except for PK and GF, which need additional structure, as
detailed in the next section):
\path|PK| and \path|GF| files need additional structure,
described in the next section.
Delete this now, if you like the above.
into separate directories.
New text following: Consult \filename{modes.mf} for recommended mode
names. (See Appendix C for complete reference.)
the \abbr{TDS} must use the latter (directory-based) scheme for naming fonts.
the \abbr{TDS} => it
For PS fonts rendered as bitmaps by a program that does not
Delete `PS'. [should have been `PostScript' anyway, but it's equally
applicable to truetype or whatever]
\section{{\protect\BibTeX}}
There's something wrong with the BibTeX logo. The `TeX' is coming out in
a bigger point size than the `B'. This is true in both the regular text
and in this heading.
Other categories include utility names:
... names, for example:
martian-1.0/read.me
Er, do we really have to recommend `read.me'? Why not `README'?
We already have the mixed-case OT1 file ...
(Global replace if you buy it.)
Thus, we don't expect any big surprises as implementation gets under way.
... we hope for few surprises ... [let's be humble]
\application{Y\&Y{\TeX}}, \command{dvips(k)},
How did this suddenly become a \command? Looks wrong.
\item[\command{dvips}]
\item[\command{xdvi} (patchlevel 20)]
Likewise here. Also, how about putting a : after each of these names?
\item[em{\TeX}]
SHould be \application-ified.
\item[\application{kpathsea}]
SHould probably be a capital K.
\path|t:$\backslash$directory**|
Here are the $\backslash$ things you need to fix. (Joachim said make it
\\, I think.) Also, what about \dir\** vs. \dir**? Are we sure this is
correct? Is anyone on the committee actually running emtex?! Surely...
structure won on a couple of grounds:
on a couple of grounds => for a couple of reasons
[don't think grounds can be pluralized like that]
however, unless all the programs that search this tree employ some form of
however, => but
sunsite.unc.edu:/pub/packages/TeX
Now that I see the list, I agree completely with Ulrik. So:
ftp.dante.de:/tex/-archive
ftp.shsu.edu:/tex-archive
ftp.tex.ac.uk:/tex-archive
This distribution includes eight-character-or-fewer recommended mode names.
distribution => file
Also, there are many places where \abbr is missing. I edited this list
from an M-x occur of ` [A-Z][A-Z][A-Z]+':
45:and from \path|/tex-archive/doc/tds| on any CTAN host.
84:At first glance, it may seem that the CTAN archives fulfill (at least)
85:part of this role, but this is not the case. The role of the CTAN archives
89:In fact, the roles of the \abbr{TDS} and CTAN are frequently in conflict,
587:The TWG recognizes that the use of short filenames has many
767: . ctan/ info about CTAN sites, \path|TeX-index|, etc.
768: . faq/ FAQs of \path|comp.text.tex|, etc.
797: info/ GNU Info files, made from {\TeXinfo} sources
957:Computer Modern and AMS fonts, you can store them in the
961:The TWG recognizes that subdirectory searching places an extra burden
1022:The TWG settled on the
1039:The fact that several members of the TWG already have arrangements
1042:at any known site, and the TWG felt it wrong to mandate something
1106:In this document, ``CTAN:'' means the root of a anonymous ftp CTAN
1113:Finger \path|ctan@ftp.shsu.edu| for a complete list of CTAN sites.
1123:available from CTAN:\path|doc/components-of-TeX|.
1132:The TWG had no formal meetings (many, but not all, members attended
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:12:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181611.SAA16337@spice.iti.informatik.th-darmstadt.de>
Subject: Re: it get's less... 0.76
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 18:11:15 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> A sample tree is available electronically from CTAN:\path|tds|.
>
> How about changing this to doc/tds?
I suspect because
(a) there is no CTAN:doc/ directory [:-)]
(b) from 13 MB, 10 MB are archives with software. (Effectively, your
lib/ tree & some Unix executables.) I don't know if
CTAN:documentation/tds/ is the right place for it.
[But then, I don't speak for the CTAN team; actually I don't care
where it is as long as it gets updated automatically...]
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:28:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:26:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181626.MAA16002@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: it get's less... 0.76
Reply-To: TWG-TDS@SHSU.edu
>
> [The new macros are committed now, a macro source distribution is
> available as a tar.gz file.]
Will get it for 0.77
> ** 10 Summary **
>
> In the generic/ subsection -- please move hyphen/ in front of misc/.
> Everywhere it's ordered alphabetically, except here.
check.
> ** A.4 Subdirectory Searching Syntax **
>
> You must not transform backslashs in \path arguments to
> `$\backslash$'.
Ok.
> ** C Related References **
>
> A sample tree is available electronically from CTAN:\path|tds|.
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:29:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:27:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181627.MAA16020@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: more on 0.75
Reply-To: TWG-TDS@SHSU.edu
> >> Is emTeX syntax really `t:\directory**'? I would have suspected
> >> `t:\directory\**'.
>
> Where did the asterisks come from? I have been religiously tracking
> updates to emTeX betas, and can find nothing in the DOC files to
> suggest that the syntax has changed from trailing `!' & `!!'...
I think Phil's right on this one...anyone sure it's **?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:41:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181639.SAA15400@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.76 comments
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 18:39:51 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> \section{{\protect\BibTeX}}
>
> There's something wrong with the BibTeX logo. The `TeX' is coming out in
> a bigger point size than the `B'.
I beg to differ. My eyes have an other opinion. Well, you might not
trust them, so I asked dvitype:
38112: fntnum30 current font is cmss12
38113: setchar55 h:=4063232+462023=4525255, hh:=286
[7]
38114: pop
level 3:(h=0,v=21340577,w=0,x=0,y=786432,z=1030300,hh=0,vv=1352)
38115: right3 5449302 h:=0+5449302=5449302, hh:=345
38119: setchar66 h:=5449302+613300=6062602, hh:=384
38120: right3 -46205 h:=6062602-46205=6016397, hh:=381
[ B]
38124: fntnum38 current font is cmss10
38125: setchar73 h:=6016397+182046=6198443, hh:=393
38126: setchar66 h:=6198443+436908=6635351, hh:=421
38127: right3 -73925 h:=6635351-73925=6561426, hh:=416
[IB]
38131: fntnum30 current font is cmss12
38132: setchar84 h:=6561426+630230=7191656, hh:=456
[T]
I checked DVI & PS file distributed by Norm, btw.
> \path|t:$\backslash$directory**|
>
> Here are the $\backslash$ things you need to fix. (Joachim said make it
> \\, I think.)
Uumpf. Norm, be careful. If you use \path, just use `\', without any
escape. \path works like \verb here. If you use \literal or \filename,
you should use `\\'.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:46:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:22:36 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181622.MAA15944@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: more comments on 0.75
Reply-To: TWG-TDS@SHSU.edu
> 1. While I agree with dropping the file extensions for most files
> in the doc tree figure, I'd strongly suggest keeping it for
> amsfonts.faq und amslatex.faq. These are plain text files
> rather than .tex files, so the extension is significant here.
I don't feel strongly about it, so OK.
> 2. In the related documentation appendix I'd suggest listing only
> the three primary CTAN hosts instead of a somewhat arbitrary
> selection from among the mirror sites. (Who's ever heard
> of ftp.uni-bielefeld.de?)
I don't feel strongly about this, either. Maybe just list the big
three and suggest using "finger"...
> P.S. Concerning the target for the final version: What about
> sheduling it for the time after TUG'95 but before EuroTeX'95.
> This would allow for integrating comments received after the
> TUG meeting, but presenting the final conclusions not too
> long afterwards. Otherwise another year would go by before
> the next large international TeX conference. Sounds sensible?
I think timing of the final version will depend on user feedback
more than anything else.
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
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 11:50:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:49:40 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181649.MAA16650@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
> Here are the nits.
>
> difficult: it is impossible to determine what files are used by
>
> impossible => hard [nothing's impossible]
Check.
> Naturally, this does not affect the format of names on the CD-ROM itself.
>
> Delete `Naturally,'. [nothing's natural]
Check.
> up to the installer. On \abbr{pc} networks, for example, this
>
> Is `PC networks' really the right term here? How about `DOS machines'?
No, it's more a network thing than a DOS thing. Yes, a user on a single
machine could do it, but they might not. A Netware network might only
provide the path as T:
> files which can also be used with {\LaTeX} or {\AMSTeX} as well as
>
> Saying AMSTeX here gives the misleading impression that those are the
> only two formats that counts (especially since we also point out AMSTeX
> is compatible with plain). How about `and other formats' instead?
Is this what you mean?
...files which can also be used with {\LaTeX} or {\AMSTeX} and other
formats as well as...
Check.
> This directory need only exist
>
> only exist => exist only
Check.
> under the \literal{generic} format tree.
>
> tree => directory
Check.
> The \abbr{TDS} specifies the following:
>
> following (except for PK and GF, which need additional structure, as
> detailed in the next section):
Check.
> \path|PK| and \path|GF| files need additional structure,
> described in the next section.
>
> Delete this now, if you like the above.
Sounds good.
> into separate directories.
>
> New text following: Consult \filename{modes.mf} for recommended mode
> names. (See Appendix C for complete reference.)
Check.
> the \abbr{TDS} must use the latter (directory-based) scheme for naming fonts.
>
> the \abbr{TDS} => it
Check.
> For PS fonts rendered as bitmaps by a program that does not
>
> Delete `PS'. [should have been `PostScript' anyway, but it's equally
> applicable to truetype or whatever]
Check.
> \section{{\protect\BibTeX}}
>
> There's something wrong with the BibTeX logo. The `TeX' is coming out in
> a bigger point size than the `B'. This is true in both the regular text
> and in this heading.
Joachim?
> Other categories include utility names:
>
> ... names, for example:
Check.
> martian-1.0/read.me
>
> Er, do we really have to recommend `read.me'? Why not `README'?
> We already have the mixed-case OT1 file ...
> (Global replace if you buy it.)
Ok.
> Thus, we don't expect any big surprises as implementation gets under way.
>
> ... we hope for few surprises ... [let's be humble]
Yep.
> \application{Y\&Y{\TeX}}, \command{dvips(k)},
>
> How did this suddenly become a \command? Looks wrong.
>
> \item[\command{dvips}]
> \item[\command{xdvi} (patchlevel 20)]
>
> Likewise here. Also, how about putting a : after each of these names?
Ok.
> \item[em{\TeX}]
>
> SHould be \application-ified.
>
> \item[\application{kpathsea}]
>
> SHould probably be a capital K.
Check and check.
> \path|t:$\backslash$directory**|
>
> Here are the $\backslash$ things you need to fix. (Joachim said make it
> \\, I think.) Also, what about \dir\** vs. \dir**? Are we sure this is
> correct? Is anyone on the committee actually running emtex?! Surely...
I used to. And I really think it's \dir!!
> structure won on a couple of grounds:
>
> on a couple of grounds => for a couple of reasons
> [don't think grounds can be pluralized like that]
Ok.
> however, unless all the programs that search this tree employ some form of
>
> however, => but
Check.
> sunsite.unc.edu:/pub/packages/TeX
>
> Now that I see the list, I agree completely with Ulrik. So:
>
> ftp.dante.de:/tex/-archive
> ftp.shsu.edu:/tex-archive
> ftp.tex.ac.uk:/tex-archive
Check.
> This distribution includes eight-character-or-fewer recommended mode names.
>
> distribution => file
Check.
> Also, there are many places where \abbr is missing. I edited this list
> from an M-x occur of ` [A-Z][A-Z][A-Z]+':
Check.
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 14:57:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 15:56:41 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181956.PAA22982@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: MORE READING: 0.77
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}; *.sgm
Joachim,
I used tdsguide 1.1; is the header on the title page my fault (old
version of some style)?
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 Thu, 18 May 1995 15:09:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505182008.WAA14013@spice.iti.informatik.th-darmstadt.de>
Subject: Re: MORE READING: 0.77
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 22:08:53 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}; *.sgm
>
> Joachim,
>
> I used tdsguide 1.1; is the header on the title page my fault (old
> version of some style)?
It seems so, I have noticed but can't reproduce this problem here. I
use fancyheadings.sty version 1.7, perhaps you might want to check
this.
I thought about adding current versions of all used style files to
the tdsguide macro distribution, perhaps in a styles/ subdirectory --
would this help?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 16:31:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 17:30:45 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505182130.AA29174@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: it get's less... 0.76
(a) there is no CTAN:doc/ directory [:-)]
Oops. Several CTAN:doc/'s need to be changed to CTAN:documentation/'s.
Sorry, Norm.
(b) from 13 MB, 10 MB are archives with software. (Effectively, your
lib/ tree & some Unix executables.) I don't know if
CTAN:documentation/tds/ is the right place for it.
Well, are users supposed to actually retrieve it and use it?
Then I would say it should be systems/tds.
If it's a sort of supplement to the standard (the view I lean towards), then
I think it should be CTAN:documentation/tds/texmf or some such.
In any case, having the example tree in CTAN:tds/ and the standard in
CTAN:documentation/tds seems utterly confusing to me.
[But then, I don't speak for the CTAN team; actually I don't care
Yes, but Sebastian's on the list. What say you, Sebastian?
I can't find any TDS directories on ftp.shsu.edu, by the way.
================================================================================
From owner-twg-tds@shsu.edu Thu, 18 May 1995 17:38:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 18 May 1995 18:37:38 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: 0.76 comments
To: TWG-TDS@SHSU.edu
Message-ID: <800836658.199839.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
oops!
i knew when i saw this i should have spoken up:
ftp.dante.de:/tex/-archive
ftp.shsu.edu:/tex-archive
ftp.tex.ac.uk:/tex-archive
i think we've got one too many slashes in the first line.
still in v 0.77.
please make it
ftp.dante.de:/tex-archive
(appendix c)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 May 1995 02:35:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505190734.JAA16844@spice.iti.informatik.th-darmstadt.de>
Subject: Re: it get's less... 0.76
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 09:34:10 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (b) from 13 MB, 10 MB are archives with software. (Effectively, your
> lib/ tree & some Unix executables.) I don't know if
> CTAN:documentation/tds/ is the right place for it.
>
> Well, are users supposed to actually retrieve it and use it?
No, heaven forbid. I don't see it as a plug&play distribution.
So I withdraw argument (b), Sebastian shall decide.
> I can't find any TDS directories on ftp.shsu.edu, by the way.
I don't know how the CTAN team currently organizes an automatic mirror
on one site and subsequent uploads to the other CTAN sites.
(Technically, it's simple; a script ctan_install must be called with
the result of a mirror run.)
I might be inclined to mirror it myself to ftp.dante.de (netwise
very near, and I have write access) and manage the CTAN distribution
from there. But first I want to know how it's supposed to be done... :)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 May 1995 11:09:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 19 May 1995 12:08:25 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191608.AA07273@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 0.77 comments
Well, aside from tex/-archive and the few miscellanous typographical
problems, maybe it's time ... my nits are getting nittier. Also,
thankfully, fewer.
this.) It may be convenient to store implementations
(\application{em{\TeX}}, \application{PC{\TeX}}, etc.) as well
as utilities (\command{dvips}, \command{MakeIndex}, etc.) in
their own directories. Implementations can store implementation-specific
This bit is confused, both typographically and semantically. How about
this:
Both implementations (\application{em{\TeX}},
\application{PC{\TeX}}, etc.) and
utilities (\application{dvips}, \application{MakeIndex}, etc.)
are included here. Sites can thus store implementation-specific
``local'' files, since that would require duplicating the entire tree.
``local'' files => locally-maintained files (e.g., letterheads)
files which can also be used with {\LaTeX} or {\AMSTeX} and other
Now that I see it in print, I think it's better to delete the `or
{\AMSTeX}' here. Whether it should ``and other formats'' or ``or other
formats'' is a matter of debate -- I think we previously decided
anything in tex/generic/ has to work with at least tex and latex, didn't
we? I.e., tex and amstex is not enough, since amstex doesn't do anything
drastic to plain, like latex does.
This is one of the weakest points of the standard ... exactly what goes
in generic/. But, clearly now is not the time for further debate!
At the moment there aren't any besides the standard distribution,
besides the => besides those in the
little more we can do.
little => no
American Mathematical Society, Providence, \abbr{ri}, \abbr{u.s.a}.
Editor, TUGboat;
TUGboat => \citetitle{TUGboat}
Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \command{Web2C},
\command => \application
such as \citetitle{SunExpert} and \citetitle{UNIX Review}.
UNIX => \abbr{UNIX}
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 May 1995 11:43:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191642.SAA12486@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 18:42:20 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/.
That's easy (IMO :-):
texmf/tex/generic/ holds macros that can be used with all TeX formats
that use plain TeX's category codes and provide plain TeX's basic
control sequences. The latter are those described in the TeXbook
Appendix B, except ``font information'' (section~4), box, tabbing,
item and section macros (section~5, p.\,353--355), and ``Macros for
output'' (section~7). Note that those control sequences must be only
be provided, they may have a different implementation.
Joachim
PS: page numbers are from hard cover, 9th printing.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 May 1995 12:14:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191642.SAA12486@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 18:42:20 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/.
That's easy (IMO :-):
texmf/tex/generic/ holds macros that can be used with all TeX formats
that use plain TeX's category codes and provide plain TeX's basic
control sequences. The latter are those described in the TeXbook
Appendix B, except ``font information'' (section~4), box, tabbing,
item and section macros (section~5, p.\,353--355), and ``Macros for
output'' (section~7). Note that those control sequences must be only
be provided, they may have a different implementation.
Joachim
PS: page numbers are from hard cover, 9th printing.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 May 1995 16:08:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 19 May 1995 17:07:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505192107.AA12104@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.77 comments
Being compatible with plain TeX's catcodes and basic control
sequences isn't enough, I thought. It has to be compatible
with LaTeX, or what's the point? For example, btxmac.tex
should not be in generic/, I thought we decided,
even though it can be used by plain and amstex.
In reality, I think it comes down to those macro files
that can be used by plain and latex.
================================================================================
From owner-twg-tds@shsu.edu Sat, 20 May 1995 04:51:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505200950.LAA18087@spock.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Sat, 20 May 1995 11:50:36 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> Being compatible with plain TeX's catcodes and basic control
> sequences isn't enough, I thought. It has to be compatible
> with LaTeX, or what's the point?
Please note: The first sentence implies the second. I.e., my
definition was carefully worded to imply compatibility with LaTeX.
> For example, btxmac.tex
> should not be in generic/, I thought we decided,
> even though it can be used by plain and amstex.
Does btxmac.tex use only the pieces of plain.tex I scetched in my
last mail? Do you -- as the author of btxmac.tex -- expect people to
use btxmac.tex with other formats than plain TeX & AMS-TeX?
Two yes: it goes in generic/.
One no: it goes in plain/.
That's because AMS-TeX is a real extension to plain TeX, all plain
macros are (in theory) be usable with AMS-TeX. The search path for
AMS-TeX therefore encompasses the plain subtree.
There are more formats than just the Big Three. There _are_ macro files
that run with the Big Three but do not run with other formats, because
they demand more from the environment than the part I scetched. Those
don't belong in generic/ then. (IMO.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 May 1995 06:30:58 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: it get's less... 0.76
Date: Wed, 24 May 1995 12:26:47 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:196860:950524112656"@cl.cam.ac.uk>
re CTAN and TDS, Rainer has fixed SHSU to pull the top-level tds tree
in from Germany. so as things stand now, all CTAN sites will be
mirroring Joachim's TDS site, directly or indirectly. If Joachim
preferers to amanage it on Dante, just let us know, and the mirror
will switch to there
actually, on refelction, since SHSU alraedy follows Dante, not Joachim
direct, i'll make the UK do likewause, so all Joachim or anyone need
do is make sure Rainer knows whats happening
Sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 May 1995 09:57:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 May 1995 10:57:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241457.AA29890@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: some corrections on 0.72
Sebastian just pointed out to me:
the current draft says doc/tds in one place, and tds in aother :-}
doc/tds should be eradicated. we're going with CTAN:tds.
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 May 1995 14:44:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241921.VAA25321@spice.iti.informatik.th-darmstadt.de>
Subject: Another TDS revision?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 24 May 1995 21:21:58 +0200 (MESZ)
Content-Type: text
Karl suggested to create another version before public review. Norm,
if you do so, do you please check the version of your installed
fancyheadings.sty?
I just processed the current tds.tex file and forced it to use the
style files from this stand-alone document. No head line on the title
page. This points to a general problem, IMHO. I don't know how I can
force LaTeX (portably!) to output the filecontents enviroment if the
file does not exist in the current directory, so we may get more
problem reports of people with outdated style files.
If anybody on the mailing list knows a way to cope with this problem,
please contact me by email.
Thanks in advance,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 May 1995 14:48:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241850.UAA17036@spice.iti.informatik.th-darmstadt.de>
Subject: TDS on CTAN
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 24 May 1995 20:50:21 +0200 (MESZ)
CC: ctan@shsu.edu
Content-Type: text
[Hi, I've been away for a few days [*] and working on my mail backlog now.]
Thanks to sebastian to confirm that my TDS collection is mirrored. In
retrospect I think I may have sounded harsh -- it was not my
intention, my apologies to the CTAN team.
After I saw the mirror result on CTAN, I suddenly realized that I
have quite some information in the READMEs that are written in the
context of my ftp server, I have to change them to cope with the
availability on CTAN as well. In addition, there are symlinks to
files outside the TDS subtree (to the actual sources); they are not
mirrored and I have to think about a method to handle them. I have
started to do tackle the changes and will continue to do so over the
next weekend; I hope to have it settled by then.
If you have more material, where you think it should be available in
the TDS area, please send it to me or tell me an ftp site. If you
think there should be changes in file names/directory structures, I'm
open for improvement proposals.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:20:40 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251620.MAA15815@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: MORE READING: 0.77
Reply-To: TWG-TDS@SHSU.edu
> > I used tdsguide 1.1; is the header on the title page my fault (old
> > version of some style)?
>
> It seems so, I have noticed but can't reproduce this problem here. I
> use fancyheadings.sty version 1.7, perhaps you might want to check
> this.
I had, gulp, 1.1.
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
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:24:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:23:23 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251623.MAA15933@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: it get's less... 0.76
Reply-To: TWG-TDS@SHSU.edu
> (a) there is no CTAN:doc/ directory [:-)]
>
> Oops. Several CTAN:doc/'s need to be changed to CTAN:documentation/'s.
> Sorry, Norm.
Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:24:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:23:49 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251623.MAA15959@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
> oops!
> i knew when i saw this i should have spoken up:
>
> ftp.dante.de:/tex/-archive
> ftp.shsu.edu:/tex-archive
> ftp.tex.ac.uk:/tex-archive
>
> i think we've got one too many slashes in the first line.
> still in v 0.77.
Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:36:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:35:27 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251635.MAA16416@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.77 comments
Reply-To: TWG-TDS@SHSU.edu
> this.) It may be convenient to store implementations
> (\application{em{\TeX}}, \application{PC{\TeX}}, etc.) as well
> as utilities (\command{dvips}, \command{MakeIndex}, etc.) in
> their own directories. Implementations can store implementation-specific
>
> This bit is confused, both typographically and semantically. How about
> this:
>
> Both implementations (\application{em{\TeX}},
> \application{PC{\TeX}}, etc.) and
> utilities (\application{dvips}, \application{MakeIndex}, etc.)
> are included here. Sites can thus store implementation-specific
Ok.
> ``local'' files, since that would require duplicating the entire tree.
>
> ``local'' files => locally-maintained files (e.g., letterheads)
Check.
> files which can also be used with {\LaTeX} or {\AMSTeX} and other
>
> Now that I see it in print, I think it's better to delete the `or
> {\AMSTeX}' here. Whether it should ``and other formats'' or ``or other
> formats'' is a matter of debate -- I think we previously decided
> anything in tex/generic/ has to work with at least tex and latex, didn't
> we? I.e., tex and amstex is not enough, since amstex doesn't do anything
> drastic to plain, like latex does.
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/. But, clearly now is not the time for further debate!
I'm leaving it "LaTeX and other formats", for now.
> At the moment there aren't any besides the standard distribution,
>
> besides the => besides those in the
Check.
> little more we can do.
>
> little => no
Check.
> American Mathematical Society, Providence, \abbr{ri}, \abbr{u.s.a}.
> Editor, TUGboat;
>
> TUGboat => \citetitle{TUGboat}
Check.
> Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \command{Web2C},
>
> \command => \application
Check.
> such as \citetitle{SunExpert} and \citetitle{UNIX Review}.
>
> UNIX => \abbr{UNIX}
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:36:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:36:17 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251636.MAA16453@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
>
> re CTAN home for TDS, its already rooted at the top-level tds/
> directory; does anyone really feel strongly that this was a bad
> decision? i dont want to undo it unless i have to. i says that TDS is
> weird enough to warrant its own tree, cos its* not* CTAN. i want it to
> have prominence
>
Fine by me.
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:40:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:39:16 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251639.MAA16510@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: more ...
Reply-To: TWG-TDS@SHSU.edu
>
> Can we have one more draft, just to make sure the typographic problems
> are sorted out? Then I can think we can go for it.
>
Yes.
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
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:40:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:39:55 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251639.MAA16526@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
> Sebastian just pointed out to me:
>
> the current draft says doc/tds in one place, and tds in aother :-}
>
> doc/tds should be eradicated. we're going with CTAN:tds.
Gone.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:41:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:40:23 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251640.MAA16572@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Another TDS revision?
Reply-To: TWG-TDS@SHSU.edu
> Karl suggested to create another version before public review. Norm,
> if you do so, do you please check the version of your installed
> fancyheadings.sty?
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 11:48:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:36:17 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251636.MAA16453@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
>
> re CTAN home for TDS, its already rooted at the top-level tds/
> directory; does anyone really feel strongly that this was a bad
> decision? i dont want to undo it unless i have to. i says that TDS is
> weird enough to warrant its own tree, cos its* not* CTAN. i want it to
> have prominence
>
Fine by me.
================================================================================
From owner-twg-tds@shsu.edu Thu, 25 May 1995 12:08:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 13:07:57 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251707.NAA18044@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.78 online
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}
No updated SGML files provided...
Will we be ready to go on Monday??? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Fri, 26 May 1995 04:05:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 95 11:06:05 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505260906.AA01663@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: TDS on CTAN
Joachim wrote:
> If you have more material, where you think it should be available in
> the TDS area, please send it to me or tell me an ftp site. If you
> think there should be changes in file names/directory structures, I'm
> open for improvement proposals.
Check out CTAN:graphics/metapost/contrib/systems/web2c-mp-lib.tar.gz,
which includes the repackaged MetaPost macros and docs from the original
distribution and few other things I've thrown in, such as a null.mp file.
You may want to rename and/or repackage the file to ensure that it's
rganization is consistent with the rest of your files, but it should
contain all that's needed for a MetaPost base distribution.
Cheers,
Ulrik.
P.S. I haven't looked at your files, so I don't know if they unpack
into ./texmf/whatever or into ./whatever. How should it be done?
================================================================================
From owner-twg-tds@shsu.edu Fri, 26 May 1995 16:02:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 95 11:30:50 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505261530.AA26520@owl.hq.ileaf.com>
To: twg-tds@shsu.edu
Subject: 0.78 comments
Looking good.
Implementations can store implementation-specific files
Implementations => Sites
latter (directory-based) scheme
Suggest deleting `(directory-based)'.
an effort to determine
an => the
I think we're ready. Could it be?
================================================================================
From owner-twg-tds@shsu.edu Fri, 26 May 1995 17:11:11 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505261723.TAA18705@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
Date: Fri, 26 May 1995 19:23:54 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> Joachim wrote:
>
> > If you have more material, where you think it should be available in
> > the TDS area, please send it to me or tell me an ftp site. If you
> > think there should be changes in file names/directory structures, I'm
> > open for improvement proposals.
>
> Check out CTAN:graphics/metapost/contrib/systems/web2c-mp-lib.tar.gz,
> which includes the repackaged MetaPost macros and docs from the original
> distribution [...]
>
> P.S. I haven't looked at your files, so I don't know if they unpack
> into ./texmf/whatever or into ./whatever. How should it be done?
It might be that a misunderstanding raises its head here. I would
like to emphasis that the archives in the TDS area are *not* a
distribution, they are a packaged example of a final installation of
a (very basic) system. The packaging happens for my handling
convenience, not as an example how a distribution is to be done.
I have recently changed the READMEs to reflect that issue better, I'm
in the process of improving them further. In the meantime, bear with
me. :-)
I.e., I might add a reference to that tar file, but most probably I
won't add its contents. OTOH, there might be lots of such references,
and I don't want to collect them -- that's a task for the TDS registry
effort.
Ulrik, I had more pieces like your WWW document about the doc/
tree in mind. What's the URL for that? I didn't find a link in your
home page.
Btw, people looking for a binary distribution might want to check out
Thomas' new teTeX release, at
sunsite.informatik.rwth-aachen.de:/pub/comp/tex/teTeX/.
In so far, I can't comment on the PS; I think it depends on the media
& the chosen installation procedure, it will differ from distribution
to distribution.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 26 May 1995 17:49:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 1995 15:11:24 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505261911.PAA26003@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Do me a favor...
Reply-To: TWG-TDS@SHSU.edu
Draft an announcement for me ;-) Ha, ha, only serious. ;-)
I'll try over the weekend; in any event, I'll circulate *something* on
Tuesday. (Monday is a holiday, at least here in the U.S.).
No one has commented on 0.78, which I take as a positive sign.
Enjoy, everyone.
Cheers,
norm
P.S. A show of hands, how many of you will be in St. Pete for TUG?
---
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
================================================================================
From owner-twg-tds@shsu.edu Sat, 27 May 1995 10:10:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505271509.RAA24384@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Do me a favor...
To: TWG-TDS@SHSU.edu
Date: Sat, 27 May 1995 17:09:52 +0200 (MESZ)
Content-Type: text
You wrote:
>
> P.S. A show of hands, how many of you will be in St. Pete for TUG?
Sorry, no TUG conference this year. I'll be in the US in autumn, and
I can't afford two US trips in one year.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sat, 27 May 1995 10:19:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 27 May 1995 11:18:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505271518.AA08664@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: draft announcement
OK, Norm, ask and ye shall receive. Here's a draft version 0.0001 :-) of
an announcement. (I wonder if there are any paper publications going
out the door soon; something along these lines should go in TTN or
TUGboat, at least, whichever comes next.)
You should probably generate the final versions in all the formats,
so we can make sure there's no sthupidities there. (If there are, the
offending formats could just be removed from the title pages that says
they're available...)
I'm not sure we should send this to the TUG board directly, but it would
probably be good for Sebastian (as our Official Liaison :-) to forward it.
Someone who knows should add the URL's for WWW retrieval and probably
change what I have into a URL.
To: texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu,
tex-implementors@math.ams.org,
From: twg-tds@shsu.edu
Subject: draft of TeX Directory Structure standard available for review
A draft of the proposed TeX Directory Structure standard is available
for public review. You can get it by FTP from:
<CTAN host>:/tex-archive/tds/draft/tds.{tex,dvi,ps,html,xxxxxx}
(The `/tex-archive' may vary; see the end of this message for a list of
possible hosts.)
Comments and suggestions are welcome. Please communicate them by email to
twg-tds@shsu.edu
or by paper mail to
Norman Walsh
O'Reilly & Associates, Inc.
90 Sherman Street
Cambridge, MA 02140 USA
[xxx -- Norm, add the `USA' to the draft. Shouldn't be a comma after MA,
either.]
The primary purpose of this document is to describe a standard TeX
Directory Structure (TDS) for macros, fonts, and other such
implementation-independent TeX files. As a matter of practicality, it
also suggests ways to incorporate the rest of the TeX files into a
single structure. In the not-so-long run a consistent directory
structure will make it much easier to install and maintain TeX. We hope
that administrators and developers of both free and commercial
implementations of TeX will adopt this standard. It has been designed
to work on all modern systems. In particular, this Technical Working
Group (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and VMS.
We hope to publish another draft, or make the final release (depending
on the volume of comments and concerns) shortly after TUG 95.
-- the TUG TWG on a TeX Directory Structure
prompt$ finger ctan@ftp.shsu.edu
[pip.shsu.edu]
[...]
In order to reduce network load, it is recommended that you use the
Comprehensive TeX Archive Network (CTAN) host which is located in the
closest network proximity to your site. Alternatively, you may wish to
obtain a copy of the CTAN via CD-ROM (see help/CTAN.cdrom for details).
Known partial mirrors of the CTAN reside on (alphabetically):
ftp.adfa.oz.au (Australia) /pub/tex/ctan
ftp.fcu.edu.tw (Taiwan) /pub2/tex
ftp.germany.eu.net (Deutschland) /pub/packages/TeX
ftp.cs.ruu.nl (The Netherlands) /pub/tex-archive
ftp.uu.net (Virginia, USA) /pub/text-processing/TeX
nic.switch.ch (Switzerland) /mirror/tex
Known mirrors of the CTAN reside on (alphabetically):
dongpo.math.ncu.edu.tw (Taiwan) /tex-archive
gw.pacbell.com (California, USA) /mirror/ftp.shsu.edu/tex-archive
ftp.center.osaka-u.ac.jp (Japan) /CTAN
ftp.ccu.edu.tw (Taiwan) /pub/tex
ftp.cs.rmit.edu.au (Australia) /tex-archive
ftp.duke.edu (North Carolina, USA) /tex-archive
ftp.gwdg.de (Deutschland) /pub/dante
ftp.jussieu.fr (France) /pub4/TeX/CTAN
ftp.loria.fr (France) /pub/unix/tex/ctan
ftp.mpi-sb.mpg.de (Deutschland) /pub4/tex/mirror/ftp.dante.de
ftp.muni.cz (The Czech Republic) /pub/tex/CTAN
ftp.riken.go.jp (Japan) /pub/tex-archive
ftp.uni-bielefeld.de (Deutschland) /pub/tex
ftp.uni-stuttgart.de (Deutschland) /tex-archive (/pub/tex)
ftp.usafa.af.mil (Colorado, USA) /mirrors/packages/TeX
ftp.u-aizu.ac.jp (Japan) /pub/CTAN
ftpserver.nus.sg (Singapore) /pub/zi/TeX
kadri.ut.ee (Estonia) /pub/tex
src.doc.ic.ac.uk (England) /packages/tex/uk-tex
sunsite.unc.edu (North Carolina, USA) /pub/packages/TeX
wuarchive.wustl.edu (Missouri, USA) /packages/TeX
Please send updates to this list to <CTAN-Mgr@SHSU.edu>.
The participating hosts in the Comprehensive TeX Archive Network are:
ftp.dante.de (Deutschland)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node sun.dante.de
-- e-mail via ftpmail@dante.de
-- Administrator: <ftpmaint@dante.de>
ftp.shsu.edu (Texas, USA)
-- anonymous ftp and gopher /tex-archive (/pub/tex /pub/archive)
-- NFS mountable from ftp.SHSU.edu:/pub/ftp/tex-archive
-- e-mail via ftpmail@ftp.SHSU.edu
-- World Wide Web access on www.SHSU.edu
-- Administrator: <CTAN-Mgr@SHSU.edu>
ftp.tex.ac.uk (England)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node gopher.tex.ac.uk
-- NFS mountable from nfs.tex.ac.uk:/public/ctan/tex-archive
-- World Wide Web access on www.tex.ac.uk
-- Administrator: <ctan-uk@tex.ac.uk>
================================================================================
From owner-twg-tds@shsu.edu Sat, 27 May 1995 14:30:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 27 May 1995 15:29:41 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: show of hands
To: TWG-TDS@SHSU.edu
Message-ID: <801602981.201338.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
barring disasters, i'll be at the st. petersburg tug meeting.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Sat, 27 May 1995 14:57:09 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: show of hands
Date: Sat, 27 May 1995 20:56:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:157120:950527195621"@cl.cam.ac.uk>
i shall be at TUG95
s
================================================================================
From owner-twg-tds@shsu.edu Sat, 27 May 1995 15:40:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 27 May 95 13:39:10 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505272039.AA23028@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: show of hands
It looks like neither Vicki nor I will be able to get to TUG95 (SIGH).
-r
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 May 1995 02:40:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 May 95 09:41:10 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505290741.AA02668@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Joachim wrote:
> Ulrik, I had more pieces like your WWW document about the doc/
> tree in mind. What's the URL for that? I didn't find a link in your
> home page.
I'm sorry, but I'm afraid it's not current accessible at all. Besides
it is very incomplete and I really can't afford the time to work on it
at the moment, much as I would like it.
The current state of affairs is that I've merged the files with the
actual TeX installation I've been setting up here recently, with the
intention to allow navigating through the most important directories
of the texmf tree to see what files are installed where, read some
description, and even view the individual files where appropriate.
Of course, this crucially relies on the abilitiy to access the texmf
directory via some symbolic link in the public_html directory. In our
current setup, this isn't possible at the moment because the Solaris
server disk where the texmf tree resides isn't mounted on the SunOS
machine running the WWW-Server. Therefore there is no way to access
these files by WWW at the moment, not even for local users here.
I hope we'll get this sorted out sooner or later.
Cheers,
Ulrik.
P.S. Joachim, as you're so eager to get it, I'll send you a shar file
containing the files, but I wouldn't like to put it up for distribution
at this stage. There's still a lot left to be done about it.
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 May 1995 10:58:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 29 May 1995 08:57:41 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505291557.IAA21853@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Show of hands
Not yet certain, but I plan still to try to be at the Tug meeting.
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 May 1995 12:37:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 May 95 19:33:10 SET
From: GOOSSENS@CERNVM.cern.ch
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
As a member of the EuroTeX Programming Committee I am looking for somebody
(Norman?) who would be willing to come to Papendaal (in the Netherlands)
during the week of September 4th-8th to present and discuss TDS to the
European TeX users, who cannot make it to Florida this year (it means the
vast majority of them). We have a slot foreseen in the program but we
have no speaker yet. Any volunteers?
Sincere thanks. Michel Goossens
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 May 1995 14:49:57 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <19718.9505291944@ristol.dcs.ed.ac.uk>
To: twg-tds@shsu.edu
Subject: Comments on TeX directory structure
Date: Mon, 29 May 1995 20:44:20 +0100
From: David Aspinall <da@dcs.ed.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Dear Working Group,
I have been following the standard proposal fairly closely for some
time whilst building our new TeX installation, and I have accumulated
a few suggestions and questions. They follow below.
There is a lot of text, but I hope you will find time to consider what
I say at least briefly, and that it provides you with some useful
feedback.
Many thanks for the good work,
- David.
------------
David Aspinall, email: David.Aspinall@dcs.ed.ac.uk
Department of Computer Science, URL: http://www.dcs.ed.ac.uk/home/da
University of Edinburgh, Tel: +44 131 650 5898
King's Buildings, Fax: +44 131 667 7209
Edinburgh. EH9 3JZ
**********************************************************************
I've divided my comments following the section numbers of the draft
standard. I'm looking at version 0.77 dated 18th May.
2. Basics.
I am unhappy about the policy for "local" files. It seems to me
that keeping a separate tree for local adjustments and extensions,
whilst the ideal solution, is a large overhead. It compromises the
advantages you claim in the first place, of having a single tree
containing all TeX-related files.
Out of interest, the management of a single tree actually requires
*four* similar trees per architecture in our Unix system (for
reasons to do with controlling installation and file propagation
across the network). IMHO, doubling this represents an unreasonably
large effort for such a small number of files (probably < 1%).
I am strongly reluctant to implement it.
Instead I have followed the practise of using "local" as a package
name, or directory division, for example:
tex/latex/local/
csletter/
csthesis/
doc/html/local/
index.html /* master index to documentation */
doc/local /* documentation for local additions to
TeX tree */
Of course, this may lead to filename clashes, and the standard
decrees that search order is unspecified. But this seems no worse
than in any other case of name clash. Either the search order
should be resolved in a site-specific and non-standard way (for
example, searching "local" subtrees first), or the original files
could be removed from the tree. I have been following the first
approach, although we have no name clashes yet anyway.
I kindly ask that "local" could be reserved everywhere for this
kind of usage, so that administrators can choose between having two
TeX trees (strict orthodoxy) or making minor extensions within the
single tree (a more liberal interpretation).
3. Macros.
(i) Should "initex" be a format?
I expected to see "initex" used as a format. I thought it would be
sensible to use things like:
tex/initex/latex/base/latex.ltx (perhaps omitting "base/")
tex/initex/texinfo/texinfo.tex
So categorizing files which *generate* other formats as being
suitable for use by initex. I notice that the TDS compliant example
has an "initex" directory under "latex". It doesn't make much sense
to me to have latex.ltx stored under tex/latex/ because I understand
tex/latex to consist of inputs *used* by the latex format.
Similarly, I don't really want texinfo.tex to be on the path when
I'm already running "texinfo"; I expect to sensibly set TEXINPUTS
according to the format being used, roughly:
TEXINPUTS.<format> = $TEXMF/tex/<format>//
in Kpathsearch speak. (As indeed the standard suggests).
I think that putting all the <format> related files under
tex/<format> is an accidental reversion to archive-oriented rather
than installation-oriented organization. (Unless it is intentional
for some reason I don't understand).
(ii) LaTeX font macros.
I wanted to preserve the "supplier typeface" scheme when installing
the non-psnfss LaTeX files from the psfonts distribution, it seemed
strange to have it for tfm's, vf's, etc but not .sty and .fd's.
So I have directories like this:
tex/latex/fonts/adobe/bookman /* .sty and .fd files */
tex/latex/fonts/monotype/perpetua
In any case, I am not sure where the TDS presently proposes to put
these files? Simply using "bookman" or "perpetua" as the package
name could result in clashes. (Maybe a single directory "psfonts"
would suffice, and be the "correct" answer at the moment, though).
(iii) Huge directories.
Obviously the new situation is much better than having a single
TEXINPUTS directory! But I'm concerned that the "misc" directories
like texmf/tex/latex/misc/ could become rather big, and more
importantly contain no indication of where files came from. This
breaks one of the original advantages touted by the TDS for having a
"package" subdivision.
For example, the mixing up of "contrib/supported", and
"contrib/other" from CTAN. Might further separations be introduced?
I've used this:
tex/latex/misc from CTAN contrib/supported
tex/latex/comisc from CTAN contrib/other
tex/latex/external from other non-local sources
(but I don't like the name "comisc", particularly). We have a few
spare subdirectory levels to play with here, remember...
4. Fonts.
I've already communicated with Karl Berry about mode names, so that
he proposed the change to the "high mode" format. A few other
things I'd like to mention:
(i) "unknown" as a mode name.
Sometimes the mode of a pk or gf file may be unknown, or perhaps
generated by some defunct or seldom-used program (e.g., Knuth's
ransom font on CTAN). Therefore reserving "unknown" as a mode name
would be useful.
(ii) "unknown" and "mystery" as supplier and typeface names.
I think there is a similar need for default names for the
supplier and typeface parts of the directory structure. This is
because we may sometimes be dealing with fonts that have are not
named under Karl Berry's scheme (for example, user's fonts) and
so we shouldn't attempt to guess directories for them.
I have used "mystery" for both the supplier and typeface in these
cases, to distinguish from a font which is really officially
categorised as being from an "unknown" source.
[I notice that using the code "9" for unknown suppliers in Karl's
scheme means filenames that begin with a digit, which is (or was?)
disallowed by the TDS.]
(iii) Canonical mode names.
Something else which I talked with Karl about was the fact that
his modes.mf declares a huge number of mode names, but many are
aliases to particular "canonical" mode names (which are <=8
characters long).
I wonder whether one of the commandments ought to be "thou shalt
use canonical mode names" since this avoids potential problems with
massively duplicating pk files, or using directory names which are
too long. If this is already the intention, it should be
explicitly stated in the document.
(I use symbolic links like "laserwriter -> cx" to resolve
non-canonical names, but of course this isn't available to all
architectures).
(iv) Fontname maps.
I'm using these for generating directory names, but I'm not sure
where to put them? At the moment, I use:
texmf/fonts/fontname
I don't feel that the .map files belong in doc/fontname.
7. BibTeX.
Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
I would expect the usual division by <package>. There are a huge
number of .bib files out there!
[Additional comments]
A. File dates
In making my TeX installation, I've been extremely careful to
preserve the archive file dates on the files that I install.
File dates are an invaluable clue to a file's identity, especially
since many TeX-related files do not carry version numbers.
If you agree with me, I would suggest that the standard echoed this
viewpoint, in particular urging people who distribute TeX trees to
respect original file dates as far as possilbe.
[I have experienced practical problems with this matter: Karl
Berry's get-you-going "library" set, lib.tar.gz, contains several
files with newer dates than those distributed on CTAN, though they
turn out to be identical in fact. When I upgraded our installation
to a full set of files from CTAN, it involved overwriting supposedly
newer files with "older" ones; this caused our network
file-distribution software to barf in a particularly bad way and me
to get very confused! I suspect other archiving or backup tools
could be disrupted by this kind of thing too. If people are going
to mix-and-match TeX trees it is important that file identity is
maintained]
B. A temporary subtree of TEXMF is needed
Generating pk (and other font) files on-the-fly, we need somewhere
in the tree to put these. But it cannot be the standard
distributed TEXMF directory, since (in our network, at least) it is
read-only and would create security problems besides. This is one
place where I *have* duplicated fragments of the TeX tree (seeing
no alternative), in fact, by putting a link
$TEXMF/tmp -> /usr/local/var/texmf
and making directories such as /usr/local/var/texmf/fonts.
(/usr/local/var is a world-writable temporary directory shared
across all hosts). The plan is to have a clever script
automatically install font files from /usr/local/var if they are
used several times and appear to be standardly-available fonts.
I notice that in the example compliant TeX installation, there is a
directory "fonts/tmp", which has pk files stored under mode names
only. If this is to be adopted officially, could it be documented?
[And if it is, why is <supplier>/<typeface> not included under
/tmp/pk?]
C. Library directory texmf/lib
Just as there is an optional provision for binary files, in
texmf/bin/ it would be handy to also have texmf/lib/. Particularly
since texmf/ might already be in /usr/local/lib !
(For us this contains libkpathsea.a)
D. Examples
More examples would help greatly! In the early stages of setting up
our installation, I had many questions which I resolved with the
help of real distributions of trees (including the example map.files).
E. Bugs
In the example TDS compliant installation map.files, there are
several bugs, such as:
. "fonts/src" is used instead of "fonts/source"
. mf/ does not have the designated subdirectories, and should be
called metafont/
. pk files are stored in the long filename format without also the
short filename format
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 04:22:24 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sGNQB-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 May 95 10: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: show of hands
I won't be attending TUG 95.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 06:52:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 07:51:01 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301151.HAA07686@jasper.ora.com>
To: GOOSSENS@crnvma.cern.ch
CC: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Reply-To: TWG-TDS@SHSU.edu
> As a member of the EuroTeX Programming Committee I am looking for somebody
> (Norman?) who would be willing to come to Papendaal (in the Netherlands)
> during the week of September 4th-8th to present and discuss TDS to the
I'd be willing, nay, delighted to come, but I fear it's not in my budget.
Is someone else willing and able to carry the flag to Papendaal?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 07:31:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301029.MAA15488@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Tue, 30 May 1995 12:29:52 +0200 (MESZ)
CC: da@dcs.ed.ac.uk
Content-Type: text
David wrote:
>
> (i) Should "initex" be a format?
Hear, hear. (David, that was an original proposal of mine, later
rejected.) Most committee members felt that it was too much hassle to
separate the files even more just for those few INITEX-only files.
The existing directory tex/latex/initex/ in the TDS example
installation is an oversight, it was introduced at the time when we
discussed it and I forgot to delete it. Thanks for the hint, I'll
dismiss it. (I'll try to do this tonight.)
> For example, the mixing up of "contrib/supported", and
> "contrib/other" from CTAN. Might further separations be introduced?
> I've used this:
>
> tex/latex/misc from CTAN contrib/supported
> tex/latex/comisc from CTAN contrib/other
> tex/latex/external from other non-local sources
>
> (but I don't like the name "comisc", particularly). We have a few
> spare subdirectory levels to play with here, remember...
This was discussed, too. And it was felt that the introduction of a
new subdir level has two disadvantages: (1) LaTeX is handled
differently from other formats, and (2) we don't have so many spare
levels left...
> 7. BibTeX.
>
> Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
>
> I would expect the usual division by <package>. There are a huge
> number of .bib files out there!
Nice idea, I'd support it. Anyone else, too?
> B. A temporary subtree of TEXMF is needed
Yep. At my installation, texmf/ is read-only, too.
> Generating pk (and other font) files on-the-fly, we need somewhere
> in the tree to put these. [...]
> I notice that in the example compliant TeX installation, there is a
> directory "fonts/tmp", which has pk files stored under mode names
> only. If this is to be adopted officially, could it be documented?
> [And if it is, why is <supplier>/<typeface> not included under
> /tmp/pk?]
Oh, that's simple to answer: Because the MakeTeXPK script from the
kpathsea 2.5 distribution does not support it. That's also the reason
why there are long file names.
That's a problem: How much shall the TDS example installation show
real usage? Shall I cut off the file listings from the fonts/tmp/pk/
tree? (Thinking about it, shouldn't it be better named fonts/pk/tmp/,
now that we turned the mode upfront?)
> C. Library directory texmf/lib
>
> Just as there is an optional provision for binary files, in
> texmf/bin/ it would be handy to also have texmf/lib/. Particularly
> since texmf/ might already be in /usr/local/lib !
>
> (For us this contains libkpathsea.a)
There is a place already: Somewhere below texmf/web2c/, most probably
in a platform-specific subdirectory. As you'll mount your texmf/ tree
on several platforms, you'll have several libkpathsea.a and won't be
able to store them in one directory anyhow. texmf/lib/ would be too
Unix-centric, IMHO; the TDS should stay platform-neutral.
> E. Bugs
>
> In the example TDS compliant installation map.files, there are
> several bugs, such as:
Oops, I checked and noticed that I forgot to update the map.* files
after the last Big Renaming (tm) [the one with src/ -> source/, and
mf/ -> metafont/]. I'll did it just now and expect that it will be on
CTAN rather soon.
I hope to be able to provide more example parts in the future. I'll
concentrate on stuff that isn't there right now. (Fonts, in particular
PostScript fonts. But I'm waiting for the new psnfss before I'm going
to approach that.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 08:05:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 09:04:12 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301304.AA17779@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: da@dcs.ed.ac.uk
Subject: Comments on TeX directory structure
Thanks very much for your comments.
More examples would help greatly! In the early stages of setting up
The document itself should stay small. Just putting in the two example
trees we have in the document took significant amounts of time.
We do point to the full example tree, although the document doesn't
ratify it as a ``standard''. I doubt many committee members have had
time to investigate Joachim's tree, much as we all appreciate him making
it :-). (I know I haven't done so yet.)
Just as there is an optional provision for binary files, in
texmf/bin/ it would be handy to also have texmf/lib/.
I'd be more inclined to take bin/ out than to add lib/, frankly.
I think such things vary so widely there is little point in trying to
standardize them, and they just give the wrong impression that the TDS
is trying to mandate your local sysadmin setup. (Especially spsun413 --
does anyone in the world actually have a binary directory by that name?
I doubt it.)
All that said, I suppose adding lib/ doesn't cost much. Perhaps instead
we should say `additional directories for system- and site-dependent
files, such as executables and libraries, can be added at the TeX
administrator's convenience; for example, bin/ and lib/'.
I think a change like this should come, if at all, after the public
review, and we have more of a sense.
(For us this contains libkpathsea.a)
There's little point in installing this, by the way, since it's not
(presently) a shared library ...
I kindly ask that "local" could be reserved everywhere for this
kind of usage, so that administrators can choose between having two
TeX trees (strict orthodoxy) or making minor extensions within the
single tree (a more liberal interpretation).
I like this idea. I think it will be very popular with the audience, too :-).
However, I doubt any of us wants to make a change this sweeping before
the public review draft goes out. (It will take *ages* to add all the text,
believe me.) Instead, perhaps we should have a tds.additions file that
summarizes our plans for the next draft.
(Which reminds me: Norm, the draft doesn't mention jasper anywhere any
more, does it? Because we'll want to keep that for private updates/new
versions without affecting what's on CTAN ...)
(i) Should "initex" be a format?
We've been back and forth on that a zillion times :-).
I'm sure we'll think about it again. Later.
I wanted to preserve the "supplier typeface" scheme when installing
the non-psnfss LaTeX files from the psfonts distribution, it seemed
I can't remember how that got decided.
In any case, I am not sure where the TDS presently proposes to put
these files? Simply using "bookman" or "perpetua" as the package
Just dump them all into the sty/ directory, I thought.
But I'm concerned that the "misc" directories
like texmf/tex/latex/misc/ could become rather big, and more
importantly contain no indication of where files came from.
The files themselves are supposed to contain that information. That's a
much more reliable way to do it than by a directory name.
Having a whole lot of directories containing a single file doesn't seem
like a win to me. Maybe I'm misunderstanding what you're suggesting.
(i) "unknown" as a mode name.
(ii) "unknown" and "mystery" as supplier and typeface names.
Something like this seems fine to me. After the review.
I have used "mystery" for both the supplier and typeface in these
cases, to distinguish from a font which is really officially
categorised as being from an "unknown" source.
I don't understand.
[I notice that using the code "9" for unknown suppliers in Karl's
scheme means filenames that begin with a digit, which is (or was?)
disallowed by the TDS.]
I thought leading digits were allowed now.
I wonder whether one of the commandments ought to be "thou shalt
use canonical mode names" since this avoids potential problems with
massively duplicating pk files, or using directory names which are
too long. If this is already the intention, it should be
explicitly stated in the document.
Hmm ... I suppose you're right. It's left pretty implicit as it stands.
(iv) Fontname maps.
I'm using these for generating directory names, but I'm not sure
where to put them? At the moment, I use:
My thought was texmf/fontname/*.map, considering fontname as an
``application''. Another possibility is texmf/web2c/fontname/*.map (or
`kpathsea' instead of `web2c', perhaps). It's vaguely possible other
implementations than kpathsea/web2c will use the fontname maps, though.
Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
I would expect the usual division by <package>. There are a huge
number of .bib files out there!
Except .bib files (and .bst's) typically don't come in packages.
I don't think we can mandate anything here, but we should probably say
that subdirectories at the option of the installer are ok?
[I have experienced practical problems with this matter: Karl
Berry's get-you-going "library" set, lib.tar.gz, contains several
files with newer dates than those distributed on CTAN, though they
Oops. My fault. Must have lost the dates somewhere along the way.
I hate it that ftp doesn't just preserve the damn dates in the first place.
Ultra-bogosity.
I would suggest that the standard echoed this
viewpoint, in particular urging people who distribute TeX trees to
respect original file dates as far as possilbe.
Yes, this seems a good idea.
Generating pk (and other font) files on-the-fly, we need somewhere
in the tree to put these. But it cannot be the standard
This is a tough problem, and there are so many different needs out there.
We'll have to think seriously about it.
Simply including/allowing a tmp/ directory is no problem (that could
fall under the site-dependent rubric mentioned above). Any structure
below that, well ...
Thanks again for your careful comments!
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 09:25:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301423.QAA18229@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
Date: Tue, 30 May 1995 16:23:38 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> > As a member of the EuroTeX Programming Committee I am looking for somebody
> > (Norman?) who would be willing to come to Papendaal (in the Netherlands)
> > during the week of September 4th-8th to present and discuss TDS to the
>
> I'd be willing, nay, delighted to come, but I fear it's not in my budget.
> Is someone else willing and able to carry the flag to Papendaal?
I hope to be there. Luckily, Papendaal is only a few hours to drive away.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 10:30:21 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Date: Tue, 30 May 1995 16:26:50 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: